> 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. _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
