4 ms·

Before sendenv, but with magicwormhole (which it's built on top of): machine1 $ export var1=hello machine1 $ export -p var1 | wormhole send --text -

Before sendenv, but with magicwormhole (which it's built on top of): 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 After sendenv: 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 sendenv also writes to "~/.bash_profile", "~/.zshrc", which is fraught (i.e. on my system they're read-only files). 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. Basically, if you need to share ad-hoc env vars in a single terminal session, the wormhole snippet I posted above is fine. If you want them to persist, probably use direnv to share them, ideally tracked in version control. If you want them to persist system-wide, use ansible or some other configuration management. 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.

aster0id 3y ago
Fair criticism. I seek feedback like this, which is why I posted it here. You could call `sendenv` syntactic sugar on top of the first example, allowing you to do things neatly in bulk instead of having to write ad hoc scripts. Additionally once you store a vault, you can send it any number of times Granted, its likely not a very frequent need, but still handy I guess. Tracking secrets in version control is exactly what I wanted to sidestep by creating this. Sharing environment variables is an ad hoc manual process at my current company (and was the same way in previous workplaces as well). Ansible or other centralized secret stores felt too heavy for something that should be simple. The point of trusting the sender is applicable to anything you would send over magic wormhole, but I accept that this solution is more vulnerable given that it writes to rc files directly. I will be adding more validation at the receiver end before writing to rc files, as a response to this criticism.
- flakes 3y ago
  > Sharing environment variables is an ad hoc manual process at my current company (and was the same way in previous workplaces as well). It really shouldn’t be that way. If the data is meant to be selectively accessed, it should have access controls in place with Authentication, Authorization and Auditing. If its any employees discretion to share the data with another adhoc, I certainly hope the secret is not of great value.
  - aster0id 3y ago
    Oh we share secrets using a password manager. But it's a long laundry list of secrets that you have to manually load into your system somehow. There's also an env file there somewhere but it's not up to date. Eliminating the cognitive load of looking up the relevant secret, writing it manually into the RC file, testing whether it works (and starting over if it doesn't, because it's possible the secret is outdated) was one of the goals of creating this.
    - TrickardRixx 3y ago
      Sounds to me like a configuration-driven interface with the password manager is the appropriate solution here, then. I used this pattern to write config files out of secrets stored in SSM, which previously was ad-hoc secret sharing. FWIW I would never use Sendenv.
      - aster0id 3y ago
        That is one solution yes, if you already have a password manager which gives APIs to work with it's secrets. Or a separate product like Doppler which is specialized for this use case. My idea was to avoid a central store, and honestly I don't intend to compete with these massive companies with my weekend long project. If a few people find it useful, I'm happy with it. Thanks for your feedback!
- alsetmusic 3y ago
  Why is logout and login required? Why not just source the profile after writing the changes? I must be missing something about how this works.
chrisfinazzo 3y ago
> sendenv also writes to "~/.bash_profile", "~/.zshrc", which is fraught (i.e. on my system they're read-only files). > If you want them to persist system-wide, use ansible or some other configuration management. I kind of understand not wanting to give other people the ability to mess with your shell, but why are these read-only? Also, curious about the choice of Ansible...symlinks are a thing and the setup is really only as complicated as you make it. Building a mansion when you might only "need" a house with 1 or 2 bedrooms seems like an odd decision.
- TheDong 3y ago
  They're read-only because I use a dotfile manager for them, and that manager owns the contents of those files, so it doesn't want external changes to mess with them. I'm specifically using home-manager [0], but various other profile managers will also make them read-only... Especially since any changes to them will just be over-written next time you apply your dotfiles, right? I think 'direnv' is really the way to go here for most cases you want to share environment variables between developer machines, but if you're managing user's shell rc files, then you might as well use proper configuration management, because ad-hoc appending strings to those rc files is the stuff of nightmares. [0]: https://github.com/nix-community/home-manager https://github.com/nix-community/home-manager
  - chrisfinazzo 3y ago
    Ah, now I see... The thing that really made dotfiles click for me was the switch to zsh in macOS + Armin Briegel's (of Scripting OS X) book, which laid out exactly how the transition was going to work. I'd done some basic things in `.bash_profile`, but this took it to another level entirely. Tl;dr `zsh-newuser-install` is pretty idiot-proof, but it helps to know what the options are if you've never seen them before.
latexr 3y ago
> sendenv also writes to "~/.bash_profile", "~/.zshrc" Is there at least a prompt? I dislike and distrust tools which write to those files on their own. My shell’s startup files are organised how I want, with different sections depending on what’s relevant. It’s the entry point to every terminal session so I know what every line does. I don’t appreciate when a tool decides it’s OK to latch itself to every terminal session in a disorganised manner without permission, especially since those additions are seldom removed when the tool is uninstalled.
- aster0id 3y ago
  Fair point. I'll add a prompt. I was also planning to give users the ability to choose how the variables are set in general. Cleaning up after uninstall is also a good idea. Thanks for the feedback!

aster0id 3y ago

Fair criticism. I seek feedback like this, which is why I posted it here. You could call `sendenv` syntactic sugar on top of the first example, allowing you to do things neatly in bulk instead of having to write ad hoc scripts. Additionally once you store a vault, you can send it any number of times Granted, its likely not a very frequent need, but still handy I guess. Tracking secrets in version control is exactly what I wanted to sidestep by creating this. Sharing environment variables is an ad hoc manual process at my current company (and was the same way in previous workplaces as well). Ansible or other centralized secret stores felt too heavy for something that should be simple. The point of trusting the sender is applicable to anything you would send over magic wormhole, but I accept that this solution is more vulnerable given that it writes to rc files directly. I will be adding more validation at the receiver end before writing to rc files, as a response to this criticism.

flakes 3y ago
> Sharing environment variables is an ad hoc manual process at my current company (and was the same way in previous workplaces as well). It really shouldn’t be that way. If the data is meant to be selectively accessed, it should have access controls in place with Authentication, Authorization and Auditing. If its any employees discretion to share the data with another adhoc, I certainly hope the secret is not of great value.
- aster0id 3y ago
  Oh we share secrets using a password manager. But it's a long laundry list of secrets that you have to manually load into your system somehow. There's also an env file there somewhere but it's not up to date. Eliminating the cognitive load of looking up the relevant secret, writing it manually into the RC file, testing whether it works (and starting over if it doesn't, because it's possible the secret is outdated) was one of the goals of creating this.
  - TrickardRixx 3y ago
    Sounds to me like a configuration-driven interface with the password manager is the appropriate solution here, then. I used this pattern to write config files out of secrets stored in SSM, which previously was ad-hoc secret sharing. FWIW I would never use Sendenv.
    - aster0id 3y ago
      That is one solution yes, if you already have a password manager which gives APIs to work with it's secrets. Or a separate product like Doppler which is specialized for this use case. My idea was to avoid a central store, and honestly I don't intend to compete with these massive companies with my weekend long project. If a few people find it useful, I'm happy with it. Thanks for your feedback!
alsetmusic 3y ago
Why is logout and login required? Why not just source the profile after writing the changes? I must be missing something about how this works.

chrisfinazzo 3y ago

> sendenv also writes to "~/.bash_profile", "~/.zshrc", which is fraught (i.e. on my system they're read-only files). > If you want them to persist system-wide, use ansible or some other configuration management. I kind of understand not wanting to give other people the ability to mess with your shell, but why are these read-only? Also, curious about the choice of Ansible...symlinks are a thing and the setup is really only as complicated as you make it. Building a mansion when you might only "need" a house with 1 or 2 bedrooms seems like an odd decision.

TheDong 3y ago
They're read-only because I use a dotfile manager for them, and that manager owns the contents of those files, so it doesn't want external changes to mess with them. I'm specifically using home-manager [0], but various other profile managers will also make them read-only... Especially since any changes to them will just be over-written next time you apply your dotfiles, right? I think 'direnv' is really the way to go here for most cases you want to share environment variables between developer machines, but if you're managing user's shell rc files, then you might as well use proper configuration management, because ad-hoc appending strings to those rc files is the stuff of nightmares. [0]: https://github.com/nix-community/home-manager https://github.com/nix-community/home-manager
- chrisfinazzo 3y ago
  Ah, now I see... The thing that really made dotfiles click for me was the switch to zsh in macOS + Armin Briegel's (of Scripting OS X) book, which laid out exactly how the transition was going to work. I'd done some basic things in `.bash_profile`, but this took it to another level entirely. Tl;dr `zsh-newuser-install` is pretty idiot-proof, but it helps to know what the options are if you've never seen them before.

latexr 3y ago

> sendenv also writes to "~/.bash_profile", "~/.zshrc" Is there at least a prompt? I dislike and distrust tools which write to those files on their own. My shell’s startup files are organised how I want, with different sections depending on what’s relevant. It’s the entry point to every terminal session so I know what every line does. I don’t appreciate when a tool decides it’s OK to latch itself to every terminal session in a disorganised manner without permission, especially since those additions are seldom removed when the tool is uninstalled.

aster0id 3y ago
Fair point. I'll add a prompt. I was also planning to give users the ability to choose how the variables are set in general. Cleaning up after uninstall is also a good idea. Thanks for the feedback!