In some of my microcontroller testing code, I find it necessary to save things so that if I make a mistake, I can go back to a previously known-good configuration.

On a microcontroller, it's not as simple as grabbing a password/passphrase from an environment variable or file from disk, so until I get all of my code working, I set up temporary wifi/other-comms channels and embed the creds within the source (and subsequently save to Github (insert other online repo location if necessary)).

I understand completely how this is insecure, but throughout testing, I one-off my communication channel names, and flick out passphrases for them, then when I go to prod for real, I write code that will write to EEPROM, save the prod connection info, then go from there.

For me, if you're in my area (unlikely), you might bite on one of my SB5, SB9, SB66, SBx (etc) wifi (or 433MHz RF) networks, which is routed to a null VLAN, so my case is an easy one; I don't care about creds.

In the real world, if you *must* have creds in your source files (even initially), how do you deal with it?

Do you mask creds each push to your repo (prone to forgetting)? Do you set up temporary and fake comm channels until you go to production? Or do you first create the back-end compilation and storage of your creds somewhere else that isn't in a repo?

The last question in that last paragraph was loaded... even if you store creds to disk or otherwise, you *still* have to store them somehow... how do you maintain the code that does this within your Distributed Version Control System?

This might all seem like a smartass thing, but I've been fighting with committing/pushing code with passphrases and not, and the difference is that my efficiency goes downhill if I decide not to include them. I find myself without the commits to backtrack to after a major mistake because I haven't committed in some time, due to 'fear'.

Sick of banging my head due to lack of committing because of this nonsense. What do you do?

  • Comment on Passwords/passphrases in your Distributed Version Control System

Replies are listed 'Best First'.
Re: Passwords/passphrases in your Distributed Version Control System
by dsheroh (Monsignor) on Apr 01, 2019 at 08:06 UTC
    I don't know how applicable this would be to your use-case, but dealing with this sort of situation (project has local configuration which should not go into the git repo) is precisely the reason that Config::Onion exists. The master config file, let's call it config.yml, goes into git with a full, working configuration, aside from dummy/empty values for anything that's either sensitive information or so site-specific that having a global default doesn't make sense. Then, after you clone the repo, you create a config.local.yml which sits beside config.yml and any settings in the local config will override the settings in the master config. And don't forget to add *.local.* to .gitignore to ensure that these local settings never get accidentally committed to the project history.

    Prior to this we tried to do the same sort of thing manually, by putting config.example.yml (which isn't actually looked at by the code) into git and then copying it to config.yml and customizing it, but this had problems with having to remember to check for changes in the example config and then propagate them into the live config.

[reply]
[d/l]
[select]
Re: Passwords/passphrases in your Distributed Version Control System
by Corion (Patriarch) on Apr 01, 2019 at 08:34 UTC

    I have the credentials either in the environment or a separate config file, and neither of them go into source control.

    Having the credentials in the environment has the drawback of making them "easily" available to other processes of that user and thus, potentially other processes on that machine.

    Having the credentials in a separate config file (think .netrc) has the drawback of having them on file at all. The advantage is that you can explicitly exclude that credentials file from the main repository and potentially keep the credentials file in another, "highly secure" repository.

[reply]
[d/l]

      Having the credentials in the environment has the drawback of making them "easily" available to other processes of that user

      I set all test environment config in a dedicated test-xterm (with screen inside, so it can proliferate). Something like:

      export FOO=foo
export BAR=bar
export PATH=whatever/bin:$HOME/bleadperl/bin:$PATH
export PGPASSFILE=$HOME/.someplace/.pfile
xterm -wf -geometry 200x50 +sb -u8 -fg white -bg black -e "screen -Um 
+-t '${screen_title}'" &

      [download]

      for instance test database passwords (low value) would be in a file pointed at by one of the env vars (Postgres uses PGPASSFILE).

[reply]
[d/l]
Re: Passwords/passphrases in your Distributed Version Control System
by duelafn (Parson) on Apr 01, 2019 at 10:27 UTC

    I personally have only kept passwords in separate files which aren't under version control. However, you should be able to use git filters to automatically mask passwords for you. Something like: 

    # In global or local git/config  (extra backslashes needed for git)
[filter "hide-password"]
clean = /usr/bin/perl -pe 's/^password\\s*=\\s*\\K.*/PASSWORD/'

# In repo/.gitattributes
settings.conf  filter=hide-password

# settings.conf
password=3zhGERnFhzaUVs
foo=bar
...

    [download]

    Now the repo will store "password=PASSWORD" regardless of what you set the password to locally.

    Good Day,
        Dean

[reply]
[d/l]
Re: Passwords/passphrases in your Distributed Version Control System
by shmem (Chancellor) on Apr 01, 2019 at 11:51 UTC
    I understand completely how this is insecure, but throughout testing, I one-off my communication channel names, and flick out passphrases for them, then when I go to prod for real, I write code that will write to EEPROM, save the prod connection info, then go from there.

    So the creds aren't really creds, but only for testing etc? Well, then I'd just use the last commit id as channel name and its commit message as passphrase or vice versa. That way you only have to keep track of real credentials used for production tags.

    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
[reply]
Re: Passwords/passphrases in your Distributed Version Control System
by talexb (Chancellor) on Apr 01, 2019 at 21:03 UTC

    All API keys and DB credentials are stored in modules in another location, and those modules are not under version control. Each script I write does a use lib to include that directory, then I pull in the credential modules that I need.

    Never, ever, not even for a minute, should you put any credentials into a script that's under version control.

    Alex / talexb / Toronto

    Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

[reply]
[d/l]

Back to Meditations