In my day to day work and evening and weekend side work, I do most almost all of my development working on remote systems. This has a number of advantages that are for another post, but this post is about one of the limitations.
Most developers have a tool belt that they’re continually improving, and as I work on mine I come across commands - like hub - that require1 putting a secret value into an environment variable, usually for authentication.
For instance, to use hub, I need to do something like this:
1 2 3 4
If I were only running git/hub commands on my local desktop, I could put the environment variable export into my shell and be done with it. But on any remote system, I only have these options:
export GITHUB_TOKEN=..in my shell before any command that requires it. This isn’t good because the token is now in my history, and any command that I run has access to the value.
- Run each command that needs the token like this:
GITHUB_TOKEN=... git create .... This solves the access issue, but it still pollutes my history. It’s also cumbersome to deal with when running many commands.
- Add the export to my dotfiles. This solves the history problem (and the “remembering to enter the variable” problem), but then my token is available to anyone that I share my dotfiles with.
I wanted something that I could use to securely manage these kinds of environment variables while making it convenient to expose them to specific commands. So I wrote envbox.
Envbox is written in Go, primarily because the language is quite suitable for these sorts of problems, but also because there’s a NaCl secretbox implementation in the Go “Sub Repositories”, and I thought it was a good fit for this problem.
After installation (instructions in the README), the first step is to set up envbox by generating a key:
This key is used to encrypt each of the environment variables. Next up is to add a new environment variable:
1 2 3 4
Then, when running a command that needs the variable:
Or, more apropos for the above example:
Envbox stores each variable in its own file on disk:
1 2 3 4 5 6 7 8 9 10 11
Currently, the key is stored in a permission-restricted file in your home directory so that envbox can decrypt the files, but the plan is to move to a credential cache system like the one git uses, so that the key is only held in memory for a configurable time. This makes a better tradeoff between security and convenience.
There are a few other things that envbox can do, such as accepting multi-line variables and differentiating the envbox name from the variable name, so that several of the same variable (e.g. two different GITHUB_TOKENs) can be tracked.
I’ve found it to be incredibly useful, allowing me to version and distribute my secret variables while keeping them secure.
hub doesn’t actually require the environment variable, but logging in for every push and pull seems a bit inefficient.↩