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 <enrico@enricozini.org>
Attachment:
signature.asc
Description: PGP signature