11–20 of 43 posts
Couldn't you just use pass and have something like this in your bash script/env: export SOME_SECRET="$(pass show some/secret)"
Coincidentally I’ve written something similar to this too. My main takeaway was that GPG isn’t nearly as user friendly as it needs to be.
Highly true. Yet. If you complain or even offer patches (which will, always, without fail, be rejected). You'll get told off by the GPG devs with something along the lines of "encryption is supposed to be hard".
Age has a simpler interface and SSH key support https://github.com/FiloSottile/age
ejson2env has the environment variable integration and ejson has multiple backends https://github.com/Shopify/ejson2env
direnv can support any cli secrets manager per project directory https://direnv.net/
I've dealt with enough "why did this break" situations with gpg secrets files used by capable teams that I'd never recommend that to anyone. And unless you really need the public key support (teams and deployment support), you're unlikely to gain anything better over a password manager.
Earlier quoted context omitted.
Highly true. Yet. If you complain or even offer patches (which will, always, without fail, be rejected). You'll get told off by the GPG devs with something along the lines of "encryption is supposed to be hard".
How hard would it be to devise an easy to use wrapper on top of GPG, kind of porcelain-like?
It's used by quite a few companies and public administrations.
Earlier quoted context omitted.
Highly true. Yet. If you complain or even offer patches (which will, always, without fail, be rejected). You'll get told off by the GPG devs with something along the lines of "encryption is supposed to be hard".
How hard would it be to devise an easy to use wrapper on top of GPG, kind of porcelain-like?
https://github.com/FiloSottile/age is this for encrypting files.
https://en.wikipedia.org/wiki/Signify_(OpenBSD) and https://jedisct1.github.io/minisign/ are this for signing files.
Signal/Whatsapp/etc that use the Signal Protocal are this for messaging.
It turns out solving one problem at a time and ending up with a bunch of purpose-built tools is way easier to get right than trying to jam an entire toolbox into one thing.
Earlier quoted context omitted.
Highly true. Yet. If you complain or even offer patches (which will, always, without fail, be rejected). You'll get told off by the GPG devs with something along the lines of "encryption is supposed to be hard".
How hard would it be to devise an easy to use wrapper on top of GPG, kind of porcelain-like?
>GnuPG Made Easy (GPGME) is a library designed to make access to GnuPG easier for applications. It provides a High-Level Crypto API for encryption, decryption, signing, signature verification and key management. Currently it uses GnuPG's OpenPGP backend as the default, but the API isn't restricted to this engine. We have, in fact, already developed a backend for CMS (S/MIME).
Unless you're good at actually maintaining your gpg keychain and need other people to access this, I really wouldn't bother with gpg. There are way better and simpler options. Age has a simpler interface and SSH key support https://github.com/FiloSottile/age ejson2env has the environment variable integration and ejson has multiple backends https://github.com/Shopify/ejson2env direnv can support any cli secrets manage…
Unless you're good at actually maintaining your gpg keychain and need other people to access this, I really wouldn't bother with gpg. There are way better and simpler options. Age has a simpler interface and SSH key support https://github.com/FiloSottile/age ejson2env has the environment variable integration and ejson has multiple backends https://github.com/Shopify/ejson2env direnv can support any cli secrets manage…
age looks really interesting, thanks. I also learned from that page that appending ".keys" to your GitHub profile URL (so https://github.com/yourusername.keys ) returns a list of your SSH public keys! (Where is this documented...?)
https://github.com/rust-lang/rust/pull/139966