My weekend project sendenv is a CLI tool that lets you share environment variables securely with someone else. It is built on top of magic-wormhole which allows for safe, account-free data transfer. When you send variables using sendenv, it creates a one-time code. You give this code to the person who needs the variables. They use the code in their shell to load the variables. This is handy for quickly setting up new team members or copying local environment variables to another system.<p>Its currently in alpha obviously, but the core functionality works (I have tested sending vaults from a Macbook Air M1 to a ubuntu ec2 instance). I have a lot of follow up ideas to make this better, but wanted the community's feedback before I invest more time on this.<p>Thanks for reading!
Before sendenv, but with magicwormhole (which it's built on top of):<p><pre><code> machine1 $ export var1=hello
machine1 $ export -p var1 | wormhole send --text -
On the other computer, please run wormhole receive 1-word-word
machine2 $ eval "$(wormhole receive 1-word-word)"
machine2 $ echo $var1
hello
</code></pre>
After sendenv:<p><pre><code> machine1 $ export var1=hello
machine1 $ sendenv create-vault v
machine1 $ sendenv add-var v
machine1 $ sendenv send-vault v
machine2 $ sendenv receive-vault
Please logout and login again for the changes to take effect
machine2 $ echo $var1 # doesn't work, needed to re-login
</code></pre>
sendenv also writes to "~/.bash_profile", "~/.zshrc", which is fraught (i.e. on my system they're read-only files).<p>It also, just like the eval in the first example, has the downside of requiring you to completely trust the sender since they can send arbitrary code to execute that'll get written to your shell's rc file.<p>Basically, if you need to share ad-hoc env vars in a single terminal session, the wormhole snippet I posted above is fine.<p>If you want them to persist, probably use direnv to share them, ideally tracked in version control.<p>If you want them to persist system-wide, use ansible or some other configuration management.<p>The middle-ground, of wanting them to persist so much you write them to the shell rc, but not wanting them to be version controlled or configuration managed, seems like the worst of both worlds.
Related tool: a friend and I created `diffenv` for developers to easily compare (diff) development environments including environment variables:<p><a href="https://github.com/error-central/diffenv">https://github.com/error-central/diffenv</a><p>Helps for debugging those times when you say, “well it runs fine on my machine, what’s different about your machine??”