x/crypto/openpgp: mark as frozen and deprecated #44226
This is a proposal to freeze and deprecate but not remove the golang.org/x/crypto/openpgp package, providing only security patches going forward. Open issues and CLs would be triaged, fixed if they are security issues, and closed otherwise.
The golang.org/x/crypto/openpgp package is effectively unmaintained.
Maintaining it would require significant effort, which would not be the best use of our team's resources, and a community maintainer has not materialized.
Not communicating this clearly to users is making them a disservice, and stifling the opportunity for the community to converge on a third-party fork.
OpenPGP is not something we want Go developers to use. OpenPGP is incompatible with https://golang.org/design/cryptography-principles, it's complex, fragile, and unsafe, and using it exposes applications to a dangerous ecosystem. (Just the other day there was an exploitable heap overflow in GnuPG.) Oceans of ink have been spilled about this, and a debate about the qualities of PGP wouldn't be productive for anyone, so let's keep it off topic, except to the extent that it informs team resource allocation.
Maintaining x/crypto/openpgp would require a disproportionate amount of resources. x/crypto/openpgp is the crypto package with the most open CLs, and only crypto/tls, crypto/x509, and x/crypto/ssh have a similar number of open issues. These are all packages that implement old, complex, evolving protocols with significant ecosystem complexities. crypto/tls and crypto/x509 are used by most Go applications, and x/crypto/ssh powers the DevOps ecosystem. OpenPGP doesn't deserve the same amount of resources.
A community maintainer did not materialize. In #30141 we decided to look for a maintainer for x/crypto/openpgp in the community. There was some discussion on email@example.com, but such a maintainer has not materialized. This might be partially due to not providing enough support to onboard a new maintainer, but that requires resources too, and is an investment that for obvious reasons can't be guaranteed to pay off: maintainers are free to move on and step down, at which point we'd have to start over.
There is an expectation of quality for x/crypto packages. The community has an expectation of quality for the packages provided by the Go team. x/crypto/openpgp in its current state, with its 42 open issues, simply doesn't meet that bar, and it would be a lot of work (in terms of design, review, and implementation) to get it there.
The x/crypto/openpgp API has issues. There are issues like #22312 (and probably others judging from the CLs) that would be better fixed with a new API revision. x/crypto is not going to v2 just for x/crypto/openpgp, so an API revision is more likely to happen in a third-party package.
Forks abound. Every major player that actually relies on OpenPGP and Go maintains a fork (https://github.com/keybase/go-crypto, https://github.com/ProtonMail/go-crypto, ...). Developers would be better served by finding those, and by centralizing efforts onto one, without blocking on the resource limits of the Go team. Moreover, these forks regrettably fork the whole x/crypto module, presumably to be usable as a
The text was updated successfully, but these errors were encountered:
I think I was one of the people arguing most for letting the community work on x/crypto/openpgp, but since no one has stepped forward, deprecating and freezing it seems like it makes sense.
And the openpgp ecosystem has lost even more traction since two years ago (when we discussed the previous proposal).