Your Thoughts

[Robert J. Hansen]

> GnuPG is cross-platform and in no way tied to Linux, but I think you
> have a point about the CLI-focused design of it. The problem isn't that
> it's CLI-based per se, but that this design has made it far too easy for
> it to accumulate features without much consideration for how the whole
> thing works together.

Eh.  Yes, no.  I agree with the claim that GnuPG's "we-do-it-all"
approach is overall a net negative for security: but there's a strong
argument to be made that if GnuPG didn't do it all, it wouldn't get done
at all.

Remember that for about fifteen years GnuPG received basically nil for
funding.  For a long while each Christmas I'd run a fundraiser match for
GnuPG, where I'd match dollar-for-dollar every dollar donated to GnuPG
for development.  My donation capped at $500.  For several of those
years, I was one of the largest individual contributors to GnuPG.

During that long period when GnuPG was short of funds and developers, it
could have focused on just one part of the crypto puzzle.  "This will
verify operating system packages with OpenPGP" or "this will verify
emails with OpenPGP", to use one simple distinction.  But doing that
would've left the other, just as important, need unaddressed: so the
developers did their best to make one package be useful to as many
OpenPGP users as possible.

This approach created some problems.  Some of the Efail bugs were
created when GnuPG generates output data even though the file fails
integrity checks.  This is not behavior you want in an email crypto
engine: if the email fails, you want to just bomb out and create no
data.  But this *is* behavior you want in a bulk crypto engine, where
there is no reasonable way to store petabytes of encrypted data in RAM
to check for consistency before writing to disk.