Skip to content(if available)orjump to list(if available)

GPG and Me (2015)

GPG and Me (2015)

3 comments

·November 11, 2025

kincl

Having done just a small to moderate amount of automation in CI/CD pipelines around GPG tools I know this pain. Back then I was waiting for https://sequoia-pgp.org/ which recently (Dec 2024) released its v1.0 of the sq CLI which seemed to have a lot of promise of fixing the strange and inconsistent ergonomics of using the gpg tools.

jmclnx

>Now I’m still excited about the future, but I dream of a world where I can uninstall it.

From 10 years ago, but still, there is nothing today as secure as GPG. Why, because I control the key, not some application or company that embeds encryption into their product.

Since 2015 we have seen may applications that use encryption, and almost every one has given up their key once the company get a legal request from their government. Just look a China for an example.

The only thing I still do not fully understand are 'sub' keys, but that does not prevent me from using gpg.

Another thing is gpg2 pinentry on *BSD needs to be fixed. It fails 100% of the time when gpg2 is called on a GUI application (ex: Emacs) on Net/OpenBSD. On gpg1, a text prompt use to be presented in Emacs, when in X, gpg2 GUI call fails.

kaoD

> there is nothing today as secure as GPG

Depending on what part of the huge hulk that GPG is, there are many tools that are as secure (or more) than it.

For encryption age[0] comes to mind. For signing minisign[1] or, more recently, plain ssh-keygen[2]. For encryption at rest, restic[3].

PGP having all this built-in with forward-compatibility is a liability.

[0] https://github.com/FiloSottile/age

[1] https://github.com/jedisct1/minisign

[2] https://man.openbsd.org/ssh-keygen.1

[3] https://github.com/restic/restic