deal with deprecation of x/crypto/openpgp

[bobcallaway]

Description

Per golang/go#44226 golang.org/x/crypto/openpgp is now frozen and deprecated. We should look to switch to a different implementation to ensure we stay up to date as best we can with this technology.

[Foxboron]

I took another look at the situation and it hasn't really changed.

The library has gotten a new name and some work. But still depends on V3 signatures for signature packet parsing which the protonmail fork doesn't support.

https://github.com/cavaliergopher/rpm/blob/main/signature.go#L75

This is unfortunate as we can't parse ed25519 PGP keys which are getting more popular. Rekor would have problems parsing the kernel.org keyring as an example.

[haydentherapper]

Golang recommends https://github.com/ProtonMail/go-crypto, which seems to be supported. Keybase has a fork too but it hasn't been updated in 2 years.

cc @lukehinds

[Foxboron]

@haydentherapper The situation hasn't changed around the https://github.com/cavaliergopher/rpm library which uses deprecated SignatureV3 packet, so we can't move to the ProtonMail library unless we also spend time fixing the underlying rpm library.

However I haven't been able to figure out if we can rip out the SignatureV3 packet support from the RPM library, I don't really understand if it's still used in the RPM ecosystem or not.

[haydentherapper]

Spent a little bit of time digging into this issue:

• RPM packages use the OpenPGP V3 signature format - See the documentation. While I know nothing about the format, I can't find anything that suggests there's any interest in moving to the V4 format. Maybe someone from RedHat would know more.
• https://github.com/ProtonMail/go-crypto is backwards compatible, but unfortunately dropped support for V3 signatures awhile ago (because they're less secure, but I haven't dug into the spec to understand why). I filed Support for OpenPGP V3 signatures ProtonMail/go-crypto#164 asking if they'd be open to adding back support for verification of them. If so, then we'd be able to update the RPM Golang library and switch Rekor's library over too.
• If not, then there's really no other options for V3 signature support, besides maintaining a fork of the above library with V3 support patched back in.
• We should be able to add in support for V4 signatures and other key types in the pgp PKI type, requested in Support PGP Ed25519 keys #1438, by using ProtonMail/go-crypto. We can treat V3 as a special case and use the deprecated library. I'd recommend adding a deprecation warning for providing a V3 public key for any non-RPM Rekor type. (Another option would be to have a second PGP PKI type for V4+ keys, but that seemed more confusing to me).

[pmatilai]

Actually rpm supports V4 signatures for closer to twenty years, that's not an issue at all.
However until recently, a surprising amount of rpm packages has been signed as V3, presumably originally for compatibility but then just forgotten, and --force-v3-sigs becoming a part of a magic incantation folks just copy-paste around without stopping to think about it.

We (rpm upstream) ran into this in 2022 and were just as surprised as anybody, see https://bugzilla.redhat.com/show_bug.cgi?id=2141686#c23 and onwards for the long story.
I pushed for changing to V4 where-ever I could, the Fedora ecosystem is all V4 nowadays and Red Hat signing server switched sometime last year, so any new packages from there will be V4 signed. But of course there will be tonnes of V3 signed content around for years to come, which rpm will need to deal with, I don't know if that's the case for you guys.

[haydentherapper]

Hey, thanks for looking into this! Ideally we would continue to support V3 signatures, but if Red Hat has moved over to V4, maybe now is the time to switch. It's looking to be quite difficult to support V3 anyways given what libraries are actively maintained in Go. There is a fork of protonmail/go-crypto that added back support for v3, though I'm not sure if the fork is trying to concurrently support both v3 and v4 or primarily v3.

We may also recommend to push this down to the client, and rather than deal with rpm support in Rekor, clients should parse rpms themselves and upload the signature as a hashedrekord type. This would be necessary when working with very large rpms anyways.