4 ms·

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?

OptionX 1y ago
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.
drewcoo 1y ago
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.
- hk1337 1y ago
  Keybase.io was a good option at one point
  - porridgeraisin 1y ago
    Curious, what happened to keyvase?
    - jakejarvis 1y ago
      Acquired by Zoom (yes, that Zoom) and left to rot. A huge loss for the internet IMO. :(
whilenot-dev 1y ago
You might be interested in sops: https://github.com/getsops/sops https://github.com/getsops/sops
hk1337 1y ago
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.
shoeffner 1y ago
I use pass to manage such things separately. This allows to script around hard-coded secrets: export MY_TOKEN="$(pass token | head -n 1)"
- lillecarl 1y ago
  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.
pabs3 1y ago
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-storage-spec/secrets-api-0.1.html https://www.freedesktop.org/wiki/Specifications/secret-stora...

OptionX 1y ago

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.

drewcoo 1y ago

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.

hk1337 1y ago
Keybase.io was a good option at one point
- porridgeraisin 1y ago
  Curious, what happened to keyvase?
  - jakejarvis 1y ago
    Acquired by Zoom (yes, that Zoom) and left to rot. A huge loss for the internet IMO. :(

whilenot-dev 1y ago

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

hk1337 1y ago

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.

shoeffner 1y ago

I use pass to manage such things separately. This allows to script around hard-coded secrets: export MY_TOKEN="$(pass token | head -n 1)"

lillecarl 1y ago
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.

pabs3 1y ago

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-storage-spec/secrets-api-0.1.html https://www.freedesktop.org/wiki/Specifications/secret-stora...