5 ms·

> The vitriol in the article is pretty surprising to me. Monday morning quarterbacking of an open source project is pretty noxious. Is there some other story th

by rodgerd 12y ago

> The vitriol in the article is pretty surprising to me. Monday morning quarterbacking of an open source project is pretty noxious. Is there some other story that I'm not aware of here? 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.

gcv 12y ago
Could you please post some links with explanations about incompatibilities? I still use GPG 1.4.18; I'm willing to upgrade if necessary, but am I also supposed to re-encrypt everything?!
- fensipens 12y ago
  AFAIK, classic (1.4) and stable (2.0) use a different format/layout for ~/.gnupg than modern (2.1). Edit: see quoted text above.
e12e 12y ago
A legitimate concern, but just as with outdated file formats, I don't think it unreasonable to expect users to forward-port their data. If you have some spreadsheets or dtp documents authored on mac os 9, you might have a hard time using them today. As for old versions - with vms I think we're in a better place for forward-security than we used to be. The day we can't boot up an amd64 linux vm seems to be far, far in the future 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.
- Spooky23 12y ago
  I think that's you're really hitting the nail on the head here. 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/ http://www.keylength.com/en/compare/ for key guidance
fensipens 12y ago
Removal of PGP-2 support 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 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.
- acqq 12y ago
  It affects the data encrypted by GPG until that "new and improved" version, as long as the keys have "older" format. Until recently the GPG was able to use such "older format" key for both encryption and decryption. Now it can't do both. And that was even not necessarily known by the users, that they used something "older": you saw the shorter fingerprint but otherwise everything worked. 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.
  - zaroth 12y ago
    We must maintain perfect backward compatibility back to the beginning of time! We must have pristine clean and cruft-free code to help ensure mistakes are easy to catch! 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.
gwillen 12y ago
Can you give more details about the broken integration? I'd be interested to see the error message / the code in question.
vertex-four 12y ago
> For people who use GPG for e.g. securing transferred documents that might be called in court 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.

by rodgerd 12y ago

gcv 12y ago

Could you please post some links with explanations about incompatibilities? I still use GPG 1.4.18; I'm willing to upgrade if necessary, but am I also supposed to re-encrypt everything?!

fensipens 12y ago
AFAIK, classic (1.4) and stable (2.0) use a different format/layout for ~/.gnupg than modern (2.1). Edit: see quoted text above.

e12e 12y ago

A legitimate concern, but just as with outdated file formats, I don't think it unreasonable to expect users to forward-port their data. If you have some spreadsheets or dtp documents authored on mac os 9, you might have a hard time using them today. As for old versions - with vms I think we're in a better place for forward-security than we used to be. The day we can't boot up an amd64 linux vm seems to be far, far in the future 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.

Spooky23 12y ago
I think that's you're really hitting the nail on the head here. 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/ http://www.keylength.com/en/compare/ for key guidance

fensipens 12y ago

Removal of PGP-2 support 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 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.

acqq 12y ago
It affects the data encrypted by GPG until that "new and improved" version, as long as the keys have "older" format. Until recently the GPG was able to use such "older format" key for both encryption and decryption. Now it can't do both. And that was even not necessarily known by the users, that they used something "older": you saw the shorter fingerprint but otherwise everything worked. 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.
- zaroth 12y ago
  We must maintain perfect backward compatibility back to the beginning of time! We must have pristine clean and cruft-free code to help ensure mistakes are easy to catch! 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.

gwillen 12y ago

Can you give more details about the broken integration? I'd be interested to see the error message / the code in question.

vertex-four 12y ago

> For people who use GPG for e.g. securing transferred documents that might be called in court 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.