Re: Reaction to potential PGP schism

Enrico Zini <[email protected]> Thu, 21 Dec 2023 11:38:43 +0100
Newsgroups	gmane.linux.debian.devel.general,gmane.linux.debian.devel.security
Message-ID	<[email protected]>
On Wed, Dec 20, 2023 at 10:16:28PM -0500, Daniel Kahn Gillmor wrote:

> # Why is GnuPG on Debian's Critical Path?
> 
> In 2023, I believe GnuPG is baked into our infrastructure largely due to
> that project's idiosyncratic interface.  It is challenging even for a
> sophisticated engineer to figure out how to get GnuPG to (probably,
> hopefully!) fulfill a cryptographic task in their project.  Once that is
> done, it's especially painful to consider moving to a different OpenPGP
> implementation, because the interface to another implementation rarely
> lines up cleanly with GnuPG's interface.

I maintain critical code that calls out to gnupg, in part because at the
time I wrote it that was the only thing available, and in part because
I'm supposed to offer the broadest possible compatibility with what
other people in Debian are using, so if everyone else seems to use
gnupg, gnupg is the first thing I would consider.

I hated and still hate every single moment I spent having to interface
with gnupg. The protocol to interact with it is custom, hydiosincratic,
poorly documented, and very hard to speak correctly. When in the end I
managed to make things work, I was always left with the feeling that
there would still be a corner case that I missed, or that will be
introduced in a future gnupg release, waiting to become a security issue
in our infrastructure, despite having asked for peer review from
appropriate people in Debian.

New releases make things harder rather than easier. Now gnupg is a
mini-ecosystem of security-critical daemons that need to be brought up
and killed, that may time out or run partly off sync with configuration,
which adds even more know-how to the amount require to survive as
downstream consumer of that one single "API".

I've been wanting for literally decades something with language
bindings, or with a protocol that is built on existing well-known
standards, outputting data that I can parse with an existing and tested
parser library, using I/O channels that I can manage using an existing
and tested communication library.

I hate it every single time I need to use gnupg, but still I use it
because I understand it's what Debian has been expecting me to use, so I
add that requirement to the pile of historical quirks that geologically
accrete in our community, which make our barrier of entry so stylishly
high, and make us appear oh so fearfully smart.


> # What Can Debian Do About This?
> 
> If you are implementing or maintaining an OpenPGP implementation in
> debian, please consider encouraging upsteam to add a sop frontend, and
> get it tested in the interop test suite!

This. 

I don't know if it should be sop or a protocol or a standard, but I'd
like to see Debian clearly document its expectations on its crypto
requirements, and stand behind it.

I personally believe that we should depend, for our core security, on an
interoperable standard with multiple implementations rather than a
project that follows the hydiosincracies of a single isolated upstream.

Whatever we do, though, I want that to be official. As things stand I'll
keep suffering with gnupg until at a DebConf I'll have at least 5 people
look at me wide-eyed and say "are you still using THAT? Everyone moved
to THIS instead!"

I'd like to ask for what mature OpenPGP implementations exist today,
pick one I feel I can confidently control, and then when somebody comes
and says "my gpg/$TOOL segfaults on your input", I want to be able to
point them at a documented decision and say "please report a bug to
$TOOL" instead of taking a week off to port everything again to gpg.

Thank you for all the work you've done on this over the years! I've
appreciated it with great gratitude and a big hope that some day, thanks
to you and others like you, those >=5 people at a DebConf will really
look at me wide-eyed and show me a way out of the pit.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <[email protected]>
signature.asc (application/pgp-signature, 833 B)