Koch: A New Future for GnuPG

Posted Jan 3, 2022 18:43 UTC (Mon) by vadim (subscriber, #35271)
In reply to: Koch: A New Future for GnuPG by cyperpunks
Parent article: Koch: A New Future for GnuPG

It's very old school, and IMO that has greatly handicapped it. I think it could have been a far more successful project if it had modernized a bit.

The sensible modern way would be to have a GPG library, and the gpg command be an UI to that. This way the code could be reused for other purposes, and parts that are not necessary could just be avoided.

Instead of that, GPGME is a wrapper around the binary. Which means it still reads the user's configuration, uses ~/.gnupg, and so on. It makes it incredibly inconvenient if you'd like to create an application that's not completely connected to the user's normal identity. And calling gpg to decrypt messages incurs a significant performance impact, because of the initialization cost.

I remember long ago back when KDE had integrated GPG support I enthusiastically tried to use with some friends, but found it sucked. Any GPG message froze the UI for a couple seconds while GPG started up and decrypted every message one at a time. Rather than facilitating encryption it made it awfully inconvenient.

Until fairly recently doing anything with the GPG ecosystem was extremely annoying, because either you use /usr/bin/gpg, which sucks for many use cases, or you reimplement it, which is a lot of delicate work. Fortunately people are finally starting to write OpenPGP libraries, but of course that bypasses GPG entirely and doesn't benefit it.

to post comments

Koch: A New Future for GnuPG

Posted Jan 3, 2022 20:20 UTC (Mon) by ballombe (subscriber, #9523) [Link] (4 responses)

Using a library means sensitive data end up in the process memory space and might be swapped out to disk, or leaked by other mean.

Koch: A New Future for GnuPG

Posted Jan 3, 2022 20:41 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

There is no reason a separate process has to behave like /usr/bin/gpg does (i.e. en/decrypt one message at a time, then exit). You could have a gpg-like daemon and send it commands over a pipe or (Unix domain) socket. You could even order it to zero and free all heap allocations, kill itself, and relaunch at the end of each session, or separate instances could be launched by each process which wants to use GPG functionality (just make sure they kill themselves after a reasonable amount of idle time has elapsed so they can't be orphaned for too long). Such a daemon could also sandbox itself, e.g. by running inside of some sort of heavily-restricted container.

Koch: A New Future for GnuPG

Posted Jan 4, 2022 17:30 UTC (Tue) by vadim (subscriber, #35271) [Link] (2 responses)

How does a process make that any better? If GPG is decrypting something for you, you end up with cleartext on the output, then it's your responsibility to deal with that properly.

I also don't see why a library couldn't do that. These days gpg runs as a normal user, because locking a small amount of memory is allowed by the kernel without any extra privileges. So a hypothetical libgpg could just do that.

Koch: A New Future for GnuPG

Posted Jan 4, 2022 17:44 UTC (Tue) by ballombe (subscriber, #9523) [Link]

At least the decrypted private keys, nonce used and anciliary secrets are not exposed.

Koch: A New Future for GnuPG

Posted Jan 4, 2022 18:07 UTC (Tue) by ibukanov (subscriber, #3942) [Link]

In-process library implementing crypto in software can be attacked via Spectre. So to protect against key and password leaks a separated process must be used with defenses against cross-process attacks exploiting hardware vulnerabilities that are not yet fixed.

Koch: A New Future for GnuPG

Posted Jan 4, 2022 17:25 UTC (Tue) by ballombe (subscriber, #9523) [Link] (2 responses)

> Instead of that, GPGME is a wrapper around the binary. Which means it still reads the user's configuration, uses ~/.gnupg, and so on. It makes it incredibly inconvenient if you'd like to create an application that's not completely connected to the user's normal identity.

Also gpgme cannot encrypt.
I solved this issue in Debian popularity-contest by creating a HOMEDIR before calling gpg and removing it afterward:

GPGHOME=`mktemp -d`
$GPG --batch --no-options --no-default-keyring --trust-model=always \
--homedir "$GPGHOME" --keyring $KEYRING --quiet \
--armor -o "$POPCONGPG" -r $POPCONKEY --encrypt "$POPCON"
rm -rf "$GPGHOME"

Koch: A New Future for GnuPG

Posted Jan 4, 2022 17:28 UTC (Tue) by vadim (subscriber, #35271) [Link]

Yup, that works, but that's a pain.

Koch: A New Future for GnuPG

Posted Jan 5, 2022 9:38 UTC (Wed) by ber (subscriber, #2142) [Link]

> Also gpgme cannot encrypt.

GPGME can encrypt:

https://gnupg.org/documentation/manuals/gpgme/Encrypt.html

Koch: A New Future for GnuPG

Posted Jan 5, 2022 9:32 UTC (Wed) by ber (subscriber, #2142) [Link] (1 responses)

When using GPGME to run gpg with one context, I could do more than 12 signatures a second in a simple server application in 2016 (see cold code https://github.com/Intevation/intelmq-mailgen/tree/master... here). So when using GPGME I believe speed is not really an issue for user facing applications.

The (very old) KMail integration blocked on some processes, which was also solved more than a decade ago (so long ago that I do not remember when) and was more an UI issue with network data always having the chance of being late and not being in control of the local application.

Using GPGME/gpg with a different identity works fine by setting a different GNUPGHOME environment variable in my experience.

The good part about GnuPG's technical structure from my point of view is that processes also separate concerns (like network access in dirmngr and private key operations in gpg-agent) and it makes it simpler to understand and reason about.

Koch: A New Future for GnuPG

Posted Jan 5, 2022 9:53 UTC (Wed) by ber (subscriber, #2142) [Link]

s/see cold code/see old code/
(sorry for the potentially confusing typo)