This guy has sacrificed a lot and built something that is pretty critical to people all over the world. As a pretty casual, I recall directing direct answers from the author in hours from the author. If the code is mess, at least it has been implemented in such a way that the mess is harder to exploit.
The two most recent upsets were GPG deliberately breaking a whole bunch of compatability, meaning newer versions will not decrypt older files. For people who use GPG for e.g. securing transferred documents that might be called in court, it's pretty upsetting, to put it mildly, that the maintainer has told us we're on our own if we want to be able to access old files[1]. Since this is one of the core uses for GPG it's generated a lot of angst.
The more obnoxious one for me is going out of his way to break a whole bunch of GPG integration, complete with acerbic error messages for people who had been relying on it. Making encryption harder to use will not improve security.
[1] Sure, you can keep old sources around and hope GPG 1.x will still build 10 years from now, but that's a bit of a gamble.
Some algorithms and parts of the protocols as used by the 20 years old PGP-2 software are meanwhile considered unsafe. In particular the baked in use of the MD5 hash algorithm limits the security of PGP-2 keys to non-acceptable rate. Technically those PGP-2 keys are called version 3 keys (v3) and are easily identified by a shorter fingerprint which is commonly presented as 16 separate double hex digits.
With GnuPG 2.1 all support for those keys has gone. If they are in an existing keyring they will eventually be removed. If GnuPG encounters such a key on import it will not be imported due to the not anymore implemented v3 key format. Removing the v3 key support also reduces complexity of the code and is thus better than to keep on handling them with a specific error message.
There is one use case where PGP-2 keys may still be required: For existing encrypted data. We suggest to keep a version of GnuPG 1.4 around which still has support for these keys (it might be required to use the --allow-weak-digest-algos option). A better solution is to re-encrypt the data using a modern key.
https://gnupg.org/faq/whats-new-in-2.1.html
This only affects data encrypted by PGP-2, the original Phil Zimmerman PGP. If you are on GPG 1.4 or 2.0 and want to switch over to 2.1 this shouldn't be a problem.
GPG even doesn't inform the users in the runtime that it silently removes user's "old format" keys from the set of keys they had. They just "dissaper."
The people who use the PGP the longest are the ones most inconvenienced. The old data, supposed to be backups, can't be read by the new version.
Sounds like the age old, More Taste! Less Filling! Backward compatibility for insecure algorithms is exactly the code which should be jettisoned. We have VMs which run Amiga and DOS, if you're terrified of not being able to decrypt then grab a cup of coffee and get to re-encrypting with a key that doesn't inline MD5!
You did get the part where this is free software, and you are free to fork it if you wish?
I tend to think it's the users responsibility, by choosing to use the package, to actually understand how it works. The maintainer owes you nothing. It's stated right there in the license.
P.S. The scare quotes do not help your argument. The old keys are technically weak. That happens with crypto from time to time. If you can't plan for that, might as well keep it cleartext.
Actually, if you are writing archiving software, yeah. Especially for official or legal records.
Keep that around for a year or two, then drop support fully.
If you have legal compliance issues like that, surely you have enough money to pay someone to maintain a tool (even a GPG derivative!) that promises never to break backwards-compatibility?
It seems like people are angry that something that was maintained for free is no longer being maintained for free. Given that they have never lifted a finger to help out (either financially or by providing code), that seems a bit petty.
Anyway, if the spec is foobared and leads to ugly implementations, surely breaking compatability is the only sane choice? If you have legal compliace isdues, pay the 100000 euros required to forward-port what you need - or re-enceypt your data?
On a side note: do you need to use signatures in your legal compliance? It would be interesting if there are legal frameworks based on/depending on PGP/GPG.
In the case of data encrypted 20 years ago with legacy era PGP, it has done its job, and now it is time to destroy or migrate the data to crypto with an appropriate lifespan.
See: http://www.keylength.com/en/compare/ for key guidance
Edit: see quoted text above.
If it's from Goodin, you should always take it with a teaspoon of salt. He is often in way over his head with certain subjects he decides to write about, best example being BADBIOS, the story about a hearsay BIOS uber-virus. Made everybody shit their pants for days (even the MSM picked it up) and after weeks of waiting, the swarm of curious FW/BIOS analysts that were demanding dumps from Goodins source finally declared the story BS.
That aside, the following paragraph alone says a lot about Goodin's ham-handed journalism:
Still, it's not clear whether it makes sense to dump massive amounts of cash to refurbish code in such disrepair.
I glimpsed over the 1.4 branch for a few minutes (I bet longer than Goodin) and while some parts look complicated, it is not remotely as ugly as for example fetchmail or certain parts of the glibc.
BADBIOS is a particularly unreasonable thing to hold over his head. Goodin is a journalist, not a security researcher. He depends on researchers as sources for his story (and in that regard, he is unusually well-sourced; possibly second only to Krebs). Security researchers were not unanimous about BADBIOS. Some of them --- Robert Graham jumps to mind --- were happy to entertain the idea that Dragos really did have a mysterious malware infection. It doesn't help that so many researchers are friends of Dragos.
Matthew Green is a radiant cut emerald of a crypto source. He's a professor of cryptography at Johns Hopkins and a former appsec consultant at Avi Rubin's old company. As far as news sources go, he's extraordinarily well-connected to crypto research; much more so than Schneier, who is reverently quoted everywhere without a peep from HN.
I think Green is being a bit unfair to GPG in this piece, and that it's reasonable to take issue with that. I don't think it's reasonable to direct that ire at Goodin.
I've worked with plenty of unprofessional reporters who butcher stuff, and don't care about the details. Dan isn't like that.
My main issue with the article was the way he presented the story as if it was based on facts instead of a few unproven claims. Subsequently, the story spread to other non-technical platforms, re-reported as fact.
> Robert Graham (...)
Well, that doesn't really matter.. extraordinary claims were made in the complete absence of extraordinary proof. And then a multi-page story was written based on nothing.
> I think Green is being a bit unfair to GPG in this piece
I agree, his comments were slightly smug.