/cc @golang/security

We don't remove functionality per the Go 1 Compatibility Promise.

I'm open to applying fixes for ecosystem-disrupting issues, but from a quick look we have two not-great options:

1. start rejecting incorrectly serialized MPIs, which means we will suddenly reject signatures we produced in a previous version, which is likely to break users
2. keep accepting incorrectly serialized MPIs, but serialize them correctly, which is likely to cause bugs where a structure gets parsed from an incorrect encoding and re-serialized to a correct encoding (e.g. for hashing or signature verification), causing a mismatch, which is likely to break users

This kind of lose-lose problems are part of why we deprecated the package and encouraged moving to a different one.

We don't remove functionality per the Go 1 Compatibility Promise.

Is this package subject to that guarantee? Arguably, it isn’t really usable in practice, not least due to the lack of ed25519 support.

I'm open to applying fixes for ecosystem-disrupting issues, but from a quick look we have two not-great options:

1. start rejecting incorrectly serialized MPIs, which means we will suddenly reject signatures we produced in a previous version, which is likely to break users
2. keep accepting incorrectly serialized MPIs, but serialize them correctly, which is likely to cause bugs where a structure gets parsed from an incorrect encoding and re-serialized to a correct encoding (e.g. for hashing or signature verification), causing a mismatch, which is likely to break users

What about storing the original byte representation, so that round-trip stability is not a requirement? That was also recommended as a solution to problems with encoding/xml.

This kind of lose-lose problems are part of why we deprecated the package and encouraged moving to a different one.

Maybe go vet should throw a warning if this package is imported.

Is this package subject to that guarantee? Arguably, it isn’t really usable in practice, not least due to the lack of ed25519 support.

If it wasn't used it wouldn't matter what signatures it generates. x/crypto is a large module, and breaking functionality would block developers from upgrading other packages, including to apply security patches. It's not an option.

If we ever make a v2, the openpgp package will not be in it.

I'm open to applying fixes for ecosystem-disrupting issues, but from a quick look we have two not-great options:

1. start rejecting incorrectly serialized MPIs, which means we will suddenly reject signatures we produced in a previous version, which is likely to break users
2. keep accepting incorrectly serialized MPIs, but serialize them correctly, which is likely to cause bugs where a structure gets parsed from an incorrect encoding and re-serialized to a correct encoding (e.g. for hashing or signature verification), causing a mismatch, which is likely to break users

What about storing the original byte representation, so that round-trip stability is not a requirement? That was also recommended as a solution to problems with encoding/xml.

That is indeed the correct way to do things, but it's not how x/crypto/openpgp works, and changing it would be a significant effort. (Or maybe not, and someone can show that in a CL!)

Maybe go vet should throw a warning if this package is imported.

go vet does not show deprecation warnings, but staticcheck does, and it's on by default in gopls.