Once set up, accessing the secrets is a matter of using the pass command line tool:

    pass edit some/secret
    # Copy the first line of a secret; by convention 
    # this is meant for a password:
    pass -c some/secret
    # Show the whole secret file:
    pass some/secret

    # Combined with git:
    pass git pull
    # Generate a 24-character random password:
    pass generate some/othersecret 24
    pass git push

1: https://www.passwordstore.org/

On the flip-side, at least we've (partially?) succeeded in taming the beast, and the end result is something moderately usable that you happily recommend to folks on HN. So that's good I suppose. :)

>can also it encrypt .env files or some sort of it?

What are .env files? You mean the config dotfiles in your home directory? If so you'll probably have to use something like EncFS to encrypt these files. Personally I don't encrypt them but I also avoid storing cleartext passwords in them as much as possible, many unix programs support getting passwords from an application, for example in my muttrc I have:

    set imap_pass = `pass mail/myemail`

<quote>

I use:

    git init --bare $HOME/.myconf
    alias config='/usr/bin/git --git-dir=$HOME/.myconf/ --work-tree=$HOME'
    config config status.showUntrackedFiles no

    config status
    config add .vimrc
    config commit -m "Add vimrc"
    config add .config/redshift.conf
    config commit -m "Add redshift config"
    config push

No extra tooling, no symlinks, files are tracked on a version control system, you can use different branches for different computers, you can replicate you configuration easily on new installation.

</quote>

But synchronizing shared configuration is clunky (you have to cherry pick commits between branches I guess).

I use NixOS and Nix on my MacBook, which allows you to store and version your whole system configuration. I have factored out different parts of my configuration (emacs, zsh, etc.) in different .nix files. So, I just have one file per machine where I import the relevant configurations and specify the packages that I want to have available. E.g. this is my user configuration on NixOS:

https://github.com/danieldk/nix-home/blob/master/machines/mi...

and macOS:

https://github.com/danieldk/nix-home/blob/master/machines/ma...

https://www.agwa.name/projects/git-crypt/

This reminds me so much about a tip in Effective Java .. 'Always provide an option for users to access every relevant part of your object. If not people will start to parse your toString output and you will have created an inofficial API that you have to support whether you want or not' (paraphrased from my faulty memory). That programmers make that mistake again and again is just sad. :(

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

http://www.hyrumslaw.com/

I'm in a team where all the consumers are only other internal teams and yet this still happens. I've found that it doesn't matter if you explicitly state to not rely on a particular behavior in your documentation, clients still will. It's always your fault if you break it because "it was your change that broke this client" and "it was working fine yesterday".

For example in java the iteration order of hash maps or the behavior of sorts in presence of non-reflexive comparators changed and people did depend on that. Sun was able to change it because it was not part of the API contract.

Which has been the source of a number of bugs in various GPG clients in the past (a few even on the HN frontpage for a few moments) and probably will into the future until GPG is no longer used.

tbh, GPG should just provide an RPC option so applications can securely pass data back and forth and receive proper error messages and codes. But I bet this won't happen because GNU fears that sort of things considering they won't split up the GCC compiler.

But yes I mostly parse colon separated text.

That's unfounded, there are plenty of GNU projects that have an API.

I can see that the same reasoning here would be valid; someone could write a proprietary GPG frontend.

Furthermore the GCC decision is well documented in mailing list posts, have you ever seen anyone involved in GPG development claim that they won't allow a library/frontend split for fear of someone writing a proprietary frontend?

Take for instance a socket class in C++, you might have a private method that deals with the low level details of the libc's socket calls. It's called at construction time and never later, and calling it would cause the current socket to be replaced by the new one (leaking the fd in the process) because it's only meant to be used at init time. Clearly it's not "use at your own risk", it's "code that calls this from the outside is fundamentally broken". Having the compiler enforce this invariant is a useful feature.

Meanwhile you can also have "use at your own risk" methods, for instance "get_raw_fd" if you want to be able to access the underlying socket. It makes it easy to break things but has legitimate use cases.

Of course you could say that you could just tag these private in a certain way and let coder discipline do the rest, but then again you could say that of pretty much all static validation (which, I suppose, makes sense if you like very dynamic languages like Python).

That's what double underscores are for:

  $ python3
  Python 3.5.2 (default, Nov 23 2017, 16:37:01) 
  [GCC 5.4.0 20160609] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> class Foo:
  ...     def foo(self):
  ...         print("I'm a public method.")
  ...     def _foo(self):
  ...         print("I'm a private method.")
  ...     def __foo(self):
  ...         print("I'm so private that you have to really know what you're doing to even call me.")
  ... 
  >>> foo = Foo()
  >>> foo.foo()
  I'm a public method.
  >>> foo._foo()
  I'm a private method.
  >>> foo.__foo()
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  AttributeError: 'Foo' object has no attribute '__foo'
  >>> foo._Foo__foo()
  I'm so private that you have to really know what you're doing to even call me.
  >>> 

At least in Java, the reflection API serves as a "break glass" barrier to make sure folks understand they're doing something they shouldn't. Someone will still do it, and they'll still blame you when their app breaks later... but I like to believe it at least scares some folks away.

The common example: programmer grabs a library to solve a problem; a few weeks later they realize it doesn't really solve the problem and requires modifications to the library to do some custom job; they make the modifications. That's normally the end of the story for several years. No point in upgrading the library unless it really solves a business problem.

That constitutes the vast majority of developers.

Of course there are other organizations that always want the latest and greatest version and are constantly upgrading. To them, I'd say sure, stick to the public methods, otherwise you're creating a big headache down the road. But I wouldn't require it of them.

https://gnupg.org/software/gpgme/index.html

... which internally calls gnpg using the --with-colons argument which is how you're supposed to get machine-readable output.

That said, maybe your use case isn't very accessible via the standard gpg commands. It sounds like you want to parse the ciphertext and extract the recipient keyids? You can do that with gpg --list-packets, but this is really intended for debugging, not automated consumption. That said it doesn't look too hard to parse, but who knows how stable it will be in the future.

gpg --list-only --list-packets foo | gawk '/^:pubkey\>/ { print $9 }'

The magic you are missing is `--quiet --status-fd 1`, then look for ENC_TO lines - the documentation can be found in https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;...

Based on my testing this works with gnupg 2.1 and 2.2, so I think it should help with your problem.

And then there was Ubuntu 16 that couldn't seem to import private keys at all or must have required some kind of super secret commandline option to allow it.

Honestly at this point I've been waiting for the inevitable article about how GPG has been maintained by one starving guy in his basement for the past 20 years and it turns out it's a total mess and nobody noticed because nobody was looking. Basically OpenSSL all over again.

Perhaps you missed it in 2015:

https://www.propublica.org/article/the-worlds-email-encrypti...

The current funding page is at https://gnupg.org/donate/

> Of course imported keys default to the lowest (most useless) level so you have to change it

You don't need to adjust trust levels, just sign the key locally (lsign) and it'll be valid. (there is a difference between key validity and trust, check out this excellent resource https://www.linux.com/learn/pgp-web-trust-core-concepts-behi... ).

For a key to be considered valid it must be either ultimately trusted, signed by ultimately trusted key or one fully trusted valid key or 3 marginally trusted valid keys.

It seems to me there are only two properties to track and quite easy calculation to do (fizz buzz level).

It's like ACLs. On the surface they seem so easy, but in practice they're a nightmare to manage because you have to track so many dependencies to figure out a simple yes/no question.

I'd be very happy to see a simpler solution to the problem of decentralized authenticity.

Some projects do rely on Web of Trust, for example Linux kernel (https://www.kernel.org/signature.html#kernel-org-web-of-trus...) or Arch Linux (https://www.archlinux.org/master-keys/).

The sq frontend uses git style subcommands to clearly separate actions from options. This is something that gpg doesn't do too well. For instance, commands (e.g., -e) look like options (e.g., -r). If no command is given, gpg tries to guess what you meant, which is perhaps good for users, but bad for programmers. And if an option isn't relevant to a command, it is often just ignored, which again, is perhaps reasonable for users, but bad for programmers.

But, I suspect that some people will insist on a shell script. So, we'll probably go this route sooner rather than later to avoid developers trying to parse the output of sq in an ad-hoc manner.

It uses OpenPGP.js (maintained by ProtonMail) and golang's crypto/x/openpgp instead of gpg.

1 - https://www.envkey.com

This works for gpg 2.1.18

gpg -u ${MYHEX} --batch --passphrase-file /path/to/some/hard-coded-passphrase --compress-level 1 --cipher-algo AES256 --sign --encrypt -r ${MYHEX} -r ${RECP1} -r ${RECP2} -r ${RECPn} -o ${OUTPUTFILE}.gpg ${INPUTFILE}