It doesn't sound like a personal dispute to me, it sounds technical. One camp (Open) wants to move faster and break backward compatibility, the other (Libre) wants to move slower and maintain backwards compatibility
Both groups would create a new format (Libre = v5; crypto-refresh = v6). v4-only wouldn't be able to handle either new format, and newer software could presumably be told to create files in the older format.
The Proton folks are choosing to support both v5 and v6:
The correct way to maintain backwards compatibility in those contexts is to decrypt and re-encrypt, not support broken ciphers or weak modes of encryption indefinitely. The latter is security theater.
A read-only operation should not cause an insane amount of writes. This is perilous for a great many reasons, one of which is the risk of data corruption should something go wrong.
You're thinking about this the wrong way: if your data needs to be secure, then it's already perilous to keep it around with with weak or broken encryption. Security models where data is too important to risk encryption upgrades but not important enough to encrypt correctly are internally incoherent.
(This is sidestepping the other parts of the comment that don't make sense, like why a single read implies multiple writes or why performing cryptographic upgrades is somehow uniquely, unacceptably risky from a data corruption perspective.)
No, I think you're thinking about it the the wrong way: write failures are common. The failure mode for a bad disk is often that reads will succeed and writes will lose data. Something that silently writes like this is increasing the risk of data loss.
It probably depends a lot on the application, but I think it's often much better to have something that will warn the user about security risks and let them decide what to do with that risk. If you do design something with these silent writes, you absolutely need to think hard about failure cases and test them, and not handwave them away. Having the most "secure" data be corrupted is ultimately an unacceptable outcome.
That's not even getting into the other problems, such as ... is it ok for the user to take a performance hit of writing X GB when all they want to do is read a file?
Your cryptosystem is not responsible for the stability of your storage medium, and your storage medium is not responsible for the security of your cryptosystem. They are black boxes to each other; to confound their responsibilities is to ensure doom in your designs.
Put another way: your cryptosystem isn't responsible for saving your ass from not making backups. If your data is valuable, treat it that way.
This is silly. Nothing that happens with the standard or its implementation is going to prevent you from decrypting a 20 year old email. It shouldn't need saying, but one reason for that is that PGP's cryptography is schoolbook cryptography.
Upstream spoke of deprecated support for older emails. My response is aimed there.
And there is loads of software that will not compile on modern hardware. End users don't often have that ability to re-write, or even to easily validate a random bit of code on github.
A project like this, needs to maintain backwards operability. For decades.
Once again: this is silly, because whatever conversation we are having about the standard, your ability to decrypt old messages would not have been impacted. Standard revisions don't turn the previous standard into secret forbidden knowledge.
What's really being asked for here is the capability to seamlessly continue sending messages with the previous, weak constructions, into the indefinite future, and have the installed base of the system continue seamlessly reading them. I think that is in fact a goal of PGP, and one of its great weaknesses.
The article specifically refers to backward compatibility with RFC4880, RFC5581, and RFC6687. These specifications include encryption techniques. So no. I was not just "free associating". Please do not assume the worst, because it could be that you just haven't understood the implications of the article.
On the other hand, as long as earlier versions or their sources remain available, it doesn't sound like a major problem to me. The sources would effectively be documentation for the previous format and can be reimplemented if needed.
There is no breaking of backward compatibility. The crypto-refresh draft and the LibrePGP draft are equally backward-compatible.
See 'A Critique on “A Critique on the OpenPGP Updates”':
* https://blog.pgpkeys.eu/critique-critique
Both groups would create a new format (Libre = v5; crypto-refresh = v6). v4-only wouldn't be able to handle either new format, and newer software could presumably be told to create files in the older format.
The Proton folks are choosing to support both v5 and v6:
* https://github.com/ProtonMail/go-crypto/pull/182
As is the Thunderbird/RNP team:
* https://github.com/rnpgp/rnp/commit/fdfc1f5bb11d439e35f3c855...