1

Back when I was a Java developer, we used to use build.properties or build.xml to store sensitive information outside of the VCS and just add the file with whatever passwords would go in it after check out.

But that's pretty language specific to Java, how would one do this in a Powershell script? Is there a way to store files in git that will be local to your own repo or your own global local machine, so that none of that stuff gets stored or shared in the repo?

Improve this question
2
  • I think the approach you're looking for is to store the credentials in some sort of external credential store. There can be a couple of different approaches to this, all of which depend on the type of systems you are working with. If you just want something simple for a dev environment, I would recommend with just having the script read from a file, and then people can store the files outside of source control. If you need something more advanced which could be used in a production environment, you could use something like Azure Key Vault.
    – Dan Landberg
    Jan 4, 2021 at 21:31
  • Knowing the details of what kind of environment you plan to use this in could help me give you a better answer.
    – Dan Landberg
    Jan 4, 2021 at 21:32

1 Answer 1

Reset to default
2

But that's pretty language specific to Java

NO.

This has nothing to do with Java. This is how developers working on the project decided to do that. Also what you are asking about Powershell has nothing specific to the Powershell. There is no difference in the approach, if you use it for Java, of for Powershell, of for anything else.

There are different approaches. One of them is following. Configuration files in the repository refer some files with predefined locations. For instance:

  • Files with fixed names in the user home directory or some of its subdirectories. Every developer creates such a file in his home directory and puts needed credentials there.
  • Files in a directory that is defined via environment variable. Every developer creates a directory where he wants, defines path to it via environment variable defined in the script, like ABC_HOME=C:\..., then puts files with credentials in that directory.

User home directory is known at any time via environment variable USER_HOME. Thus you can build the path to your file. To Powershell: Depending how complex is your script, credentials can be put to a properties file (then you need to load them as such) or can be put to another script file (then you need just to call it from your script).

With such approach you can have not only credentials common for the whole team, but also credentials specific to every developer.

Such approach is good for cross-platform applications, when some developers use Windows, some use Linux, some use Mac. In case o Powershell you may want to use Windows specific tools like Windows Credential Manager. Here there are some examples how can one use it. This tool is a matter of taste. Some developers consider as advantage that there is a GUI. The other find it as disadvantage because it is implicit and because it cannot be easily searched, copied or edited.

Thus, what approach you prefer is a matter of taste.

Improve this answer
2
  • What about environment variables for the user running the program?
    – leeand00
    Jan 5, 2021 at 17:45
  • 1
    @leeand00: Environment variables are not good if parameters are sensitive, like passwords. The reason is that if you launch some process, it's environment variables are visible to every other process. Thus it is easier to steal passwords.
    – mentallurg
    Jan 5, 2021 at 17:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .