Release attestation has degraded

[alerque]

I'm a distro release packager and package this library for Arch Linux (currently via the AUR). One of the things we do is verify checksums of assets, and to the degree upstream signs them we also verify the signatures. Of particular concern is releases have been signed, then suddenly something comes along that is not signed at all or not by the same keys.

Up until 1.19.1 all the release tags were signed with a verified signature. For 1.20.0 the commit was signed, but not the tag. For 1.21.0 neither the tag nor the underlying commit is verifiable.

Can I ask that future releases be signed again, or a signed notification be put out (even a signed note from a previously trusted key) stating what the expected signature status of verified releases is?

Thank you.

[JanEbbing]

Hi @alerque , 1.21.0 should be verifiably signed now. I got a new GPG key as my old one expired and only added it to our internal version control, but I added it to GitHub now. I'll check what happened on 1.20

[JanEbbing]

Hm it seems the 1.20.0 tag was not signed at all. Would it break something if I signed a new tag at the same date and force pushed that?

We have 1 library that has tooling that does not allow signed tags, so maybe when I made that release my git was still configured not to sign by default, sorry :( I've it on the backlog to remove that tooling.

[alerque]

Would it break something if I signed a new tag at the same date and force pushed that?

It would not break Arch because we avoided packaging it at all, but it would potentially break other usage because the tag's hash and type would both change. This could break existing verification and/or require deleting local tags in order to fetch the actual upstream ones. As a general rule that shouldn't be done. Given you already have a later release out I would be inclined to just let it go.

Thanks for responding to this. I'll go check that I can verify chain of custody for whatever signed 1.21.0 now.

[alerque]

I got a new GPG key as my old one expired

Um, you know GPG keys can be extended right? Even after they expire? As long as you have access to the private key part you can keep extending the expiration date.

The situation with a completely unrelated key popping up is somewhat unfortunate. The GitHub account access continuity is a significant data point so I assume I'm not talking to a malicious actor, but discarding the key signature data and starting over kind of ruins the chain of custody as far as GPG is concerned.

Even if you stick with your all new key can you at least sign the new key with your old one (or have @daniel-jones-dev sign your new key) and upload that signature to public key servers?

[JanEbbing]

Sorry, I'm discussing the best way around this with our security team. Might get an answer only next week.
Thanks for all your work around open source!