March 2021 Update

This proposal was accepted and due to lack of maintenance, the golang.org/x/crypto/openpgp package is now frozen and deprecated. No new changes will be accepted except for security fixes. The package will not be removed.

If you find a security issue, please email security@golang.org.

If you're looking for alternatives, consider the crypto/ed25519 package for simple signatures, golang.org/x/mod/sumdb/note for inline signatures, Tink for various cryptographic tools, or filippo.io/age for encryption (the latter two are not maintained by the Go team). You can read a summary of OpenPGP issues and alternatives here.

If you are required to interoperate with OpenPGP systems and need a maintained package, we suggest considering a maintained community fork of golang.org/x/crypto/openpgp. We don't endorse any specific one.

Intent

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.

Summary

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.

Details

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 golang-openpgp@googlegroups.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 replace in applications that import x/crypto/openpgp. This is a problem because it slows down fixes that land in other packages of x/crypto. If we let x/crypto/openpgp go, the fork(s) can hopefully eventually become a normal module that provides just the openpgp package.