Hacker News Reader

Comment by wanderingmind | Hacker News Reader

There are so many secrets spread across dot files. Is it possible to encrypt and store them in remote and de-encrypt when it’s pulled to local machines?

View on HN

That moves the problem to "how do we securely manage shared keys."

And it adds "how safe are those encrypted secrets [edit: changed from "keys" to more general language] that are committed?" and "what about previous revisions . . . because it's version control?" and "are we sure we're managing offboarding securely?"

There are probably other concerns but those are the ones the immediately shout at me.

Keybase.io was a good option at one point

Curious, what happened to keyvase?

Acquired by Zoom (yes, that Zoom) and left to rot. A huge loss for the internet IMO. :(

The freedesktop secrets service was meant to do provide a central secrets storage location and API for access on Linux, but few command-line tools use it.

https://www.freedesktop.org/wiki/Specifications/secret-stora...

I use pass to manage such things separately. This allows to script around hard-coded secrets:

     export MY_TOKEN="$(pass token | head -n 1)"

I take care to wrap my commands in functions that export only for that scope. If you have exported variables in your bashrc it'll be shared with everything you spawn through your shell, including evil NPM packages.

You might be interested in sops: https://github.com/getsops/sops

I avoid putting secrets into dotfiles and try to avoid putting non-secret, personal references in dotfiles. If I really have to, I would start with making the repository private.

I don't have many, but the few I do are set in environment vars by a file sourced in my bashrc.

Then you can just not track that file in the tool and figure out a safe way to back it up.

Reply on news.ycombinator.com