Signing of tags, release artifacts and source transparency

[dvzrv]

Hi! :wave:

I package this project for Arch Linux. We are looking into improving the transparency of our package sources wherever we can.

In this context I have identified libpcap as a central and high value package, that relies on signed, custom source tarballs. Downloads of the source tarballs currently happens from the tcpdump.org website.

With the xz incident in mind, we would like to change to a more transparent source for our libpcap package: a signed git tag. Unfortunately, the OpenPGP certificate with fingerprint 1F166A5742ABB9E0249A8D30E089DEF1D9C15D0D that we use for verifying the custom source tarball now seems expired since 2023-05-11 and has not been used to sign tags.

Would it be possible to sign tags going forward, with the same key that is/ will be used for signing release artifacts? Also, please ensure to provide a cryptographic trust path between current release signing key to any new one (in case the current one will remain expired or will be revoked) by e.g. cross-certifying.

[infrastation]

The public key validity period a while ago was extended, it is currently valid until May 2025. This was announced on the tcpdump-workers mailing list at the time. Eventually it will be replaced with a new public key with a longer validity period. Git tag signing indeed used to be done in the past and has not been done for quite a while, this is one (but not the only) problem that should be addressed next.

In any case, it would be very useful to state which specific problem you suggest to solve, because there are more meaningful factors to this problem space than you mentioned. The best place to hold such a discussion would be on the mailing list. It will be most useful if you have completely read the thread with the subject "openwrt Conclusions from CVE-2024-3094 (libxz disaster)".

[dvzrv]

Hi @infrastation, thanks for getting back to me on this!

The public key validity period a while ago was extended, it is currently valid until May 2025.

Ah, this was not clear to me. I've looked at commonly used keyservers (keyserver.ubuntu.com, keys.openpgp.org and pgpkeys.eu). I've sent the updated certificate to all of them now, so they are searchable in central/ expected places :)

Git tag signing indeed used to be done in the past and has not been done for quite a while, this is one (but not the only) problem that should be addressed next.

As long as signed tags seem possible by whoever has access to the private key material and is able to craft releases for this project, I'm fine :)

In any case, it would be very useful to state which specific problem you suggest to solve, because there are more meaningful factors to this problem space than you mentioned.

I'm not sure I follow. My request is about being able to use signed tags, because that is the most transparent (sources are not crafted into a custom tarball on a separate system, that is opaque to us) and easy (allows commit cherry-picking based on commit hashes instead of dealing with separate patch files) source type for us as a distribution to use. Personally I'd like to see GitHub to also support a "protected tags" feature (tags are immutable once created), but I guess for now it is what it is. So for us as a distribution, there really is not much more to this request.

It will be most useful if you have completely read the thread with the subject "openwrt Conclusions from https://github.com/advisories/GHSA-rxwq-x6h5-x525 (libxz disaster)".

I read your two messages (1 2) in the mail thread you were referring to and I have to say I do not agree with your overall assessment as many of the points raised appear quite tangential to me.

For me as a packager it is not so much about whether to choose autotools or cmake for building a project (both have their own annoyances and as long as the project in question is happy with whatever they use and the build system works, it works), but rather whether I am able to trust the sources I am building from, whether I can easily patch it and transparently reason about it. When building from a custom source tarball, I have to trust, that it has been created on a trustworthy machine from the git tag I want, by a trustworthy person and hope that it only contains the things I want, which hopefully are mostly equal to the files in a git repository at a tag for example.

With signed git tags on the other hand, the person crafting a release certifies an assertion about what it deems to be the release in the context of the version control system and I do not have to trust more than that. Our build tooling is able to verify signatures (detached or signed git tags) and lock source checksums (tarballs or content of repositories at specific git commits or tags) and this approach does scale. Verifying whether (and trusting in that) the contents of a custom source tarball (more or less hopefully) match the files in a git repository at a specific tag does not.

I hope the above makes clear why we as a distribution would prefer (signed) git tags over custom (signed) source tarballs.

[dvzrv]

@infrastation do you have a rough ETA on when to use signed tags? (1.10.5 - released yesterday - is not yet accompanied by a signed tag)

[infrastation]

Which verification commands are you trying and which verification errors are you observing?

[dvzrv]

Whoops, my bad! I tried with the previous tag! :facepalm:

[dvzrv]

Many thanks! With >= 1.10.5 we may also rely on signed git tags :partying_face: