Re: Reaction to potential PGP schism
Enrico Zini wrote:
>
>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".
^^^ 100% on all of that.
Trying to drive gnupg with automation is *such* a hateful,
error-prone, *inconsistent* experience. Trying to do (what should be)
simple things is really hard and messy. Simply trying to identify keys
reliably is harder than it should be. Semantics of command lines
change from one version to the next.
>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.
Again 100% on this. Just like you, I've spent countless hours writing
code to parse GPG output because of this mess.
>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.
*grin* I look forwards to it!
--
Steve McIntyre, Cambridge, UK. steve@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...
Reply to: