INCOMPATIBLE: Replace golang.org/x/crypto/openpgp with github.com/ProtonMail/go-crypto/openpgp

[mtrmac]

x/crypto/openpgp now contains a stronger deprecation warning:

// Deprecated: this package is unsafe by design, and has numerous known security
// issues. It is not maintained, and should not be used.

and points at github.com/ProtonMail/go-crypto/openpgp, so use that one.

That is an INCOMPATIBLE change in that this implementation completely removes support for v3 signature packets (but we retain support for them with the other mechanism implementations).

We can also remove the SigLifetimeSecs code because that is automatically enforced now (but we keep the expired-signature test).

This currently adds an entirely new copy because ocicrypt still uses x/crypto, hopefully that can migrate as well.
(But, still, this adds support for various algorithms that are a long-term net new code.)

[mtrmac]

containers/ocicrypt#142 updates ocicrypt.

[packit-as-a-service]

Packit jobs failed. @containers/packit-build please check.

[Luap99]

I guess it would be nice to wait for the ocicrypt PR to land to avoid the duplication (and resulting bloat?!).

[mtrmac]

Yes, and there might be some process questions about all the crypto implementations this brings in, even on non-openpgp builds (where they are not used but they are present in the binary).

[Luap99]

and there might be some process questions about all the crypto implementations this brings in, even on non-openpgp builds (where they are not used but they are present in the binary).

Well those processes (AFAIK) do not get to tell us what we merge and release upstream, if other non upstream builds or distros do not accept it they would need to patch it out themselves again. But upstream wise it sounds much worse to continue using something that says "this package is unsafe by design, and has numerous known security issues. It is not maintained, and should not be used."

[mtrmac]

All the extra implementations probably mean extra maintenance overhead (new releases of the dependencies, users running “CVE scanners” asking for updates / backports).

But then again, it’s not clear what other options we have. I don’t know what other forks of x/crypto are popular / maintained / viable.

I suppose we could just drop that build tag (and delegate to mechanisms for UntrustedSignatureContents), but that would break people building “standalone Skopeo binaries” and the like, so I’d expect quite an uproar.

[mtrmac]

containers/ocicrypt#142 updates ocicrypt.

Merged (+ #998 ), rebased.

[Luap99]

LGTM