This is a perennial problem. At some point, when software needs to access something protected by a password, the software needs that password. And for the software to get that password, and not require a user to enter it manually, it has to be stored in persistent storage of some sort. I see several options:

1. Use a hand-created (or copied) password file, ignored by the version control system, and perhaps with limited readability (just the owner (0400 on Unix), for example). I do this myself sometimes these days.

2. Encrypt the password file somehow. Technically, this doesn’t actually solve the problem, as the decryption key needs to be stored somewhere, too, but it means that the password is no longer stored in cleartext. The decryption key could be baked into the software that reads the encrypted password file, and an encryption key baked into a small utility that generates encrypted password files. This might be pretty good. I did this in earlier days when I was more paranoid.

3. Use a pre-shared key mechanism similar to what people do to ssh to remote machines without needing a password. This might be harder to set up, but can be elegant.

For Windows applications, there is the registry or various config files,e.g. app.config or web.config, that could be used to store this kind of data. AppSettings is the collection used within Windows code to access the config file in .Net for example.

I’d suspect there are similar files and locations on systems using other operating systems for where this information would be stored.

While you may disagree about storing a web.config in version control, I have had more than a few times where a developer got upset that I committed the “web.config” and thus at times it is worth considering what is the code and what is configuration that administrators can handle. If you have a better solution, why aren’t you posting it?