signed release tarballs and chain of trust

[dvzrv]

Hi! When packaging (ostree) for Arch Linux I would like to use signed upstream sources wherever possible.
We are able to verify PGP signed commits or tags from a repository clone or use detached PGP signatures for (custom) source tarballs.

With ostree it is currently only possible to verify the signed tag, as the custom source tarball does not come with a detached signature.
However, verifying the signature on either repository or source tarball only makes sense if a chain of trust between releases (if there are different keys used to sign a tag/source tarball) is established.

So far mainly @cgwalters has signed the tags using DC45FD5921C13F0B and A866D7CCAE087291 (the latter has been used to sign the former), which also established the initial chain of trust for this project.
However there are also signed tags from @jlebon (936F29E9519CE313) and @lucab (A9834A2252078E4E) for which no cross-signatures with the keys of @cgwalters exist (breaking the chain of trust). From a distribution point-of-view I would not be able to use those releases, as I can not verify whether they are malicious or not (no offense).

To establish a chain of trust going forward and increase transparency, it could be helpful to create a short section in the README, that lists the person(s) responsible for crafting a release and their accompanying PGP key id, in a signed commit (by @cgwalters). Going forward only signed commits using the established key(s) should then be used to amend the section (e.g. to change/update the keys). Additionally, cross-signatures of the established keys are of course always a good idea.

Somewhat related: Have you considered offering the custom source tarball alongside a PGP signature?

Thanks for the consideration! :)

[cgwalters]

We sign each git tag using https://github.com/cgwalters/git-evtag - please take a look at that project. I hope that Arch Linux would prefer consuming git tags directly and not tarballs, and using the extended verification there instead!

[cgwalters]

As far as cross signing - yes, agree we should do that and also maintain a keyring.

[dvzrv]

I hope that Arch Linux would prefer consuming git tags directly and not tarballs, and using the extended verification there instead!

That is indeed preferred.
I just wanted to check whether you are committed to the signing of releases (not all upstreams are ;-) ), point out the missing chain of trust for a few releases and figure out whether you have a document or similar in place for "who is doing the releases".

Thanks for responding to this topic so fast!

[lucab]

and @lucab (A9834A2252078E4E) for which no cross-signatures with the keys of @cgwalters exist (breaking the chain of trust).

Please do note that the one above is just a content-signing subkey of mine, it cannot perform/carry keytrust signatures.
My actual main key is the one with fingerprint 4C8413AA38176150A8906994BB1A3A854F3BBEBF, and that one does carry keytrust signatures (although not directly from Colin).
If you are just interested in existing trust-paths with Colin (i.e. including those longer than one step), there are multiple and non-overlapping chains going in both directions (to my key, from my key).

But yes, assembling a keyring would be the best solution here. For prior-work references, this is how the libuv project does it: https://github.com/libuv/libuv/blob/47e0c5c575e92a25e0da10fc25b2732942c929f3/MAINTAINERS.md

[dvzrv]

@lucab: Yes, e.g. a MAINTAINERS file or a section in the README (as described in the initial comment to this ticket) would be good from my point of view (given that SKS is gone now and it is sometimes hard to find the relevant cross-signatures, if the respective domains do not offer WKD).

@cgwalters Is that something you could establish before the next release? That would be really awesome! :)

[dvzrv]

@cgwalters did you have some time to further look into this?

FTR: For Arch Linux we maintain a tool called keyringctl, which we use in the context of archlinux-keyring. This tool uses python and sequoia to maintain a keyring infrastructure based on the web of trust.
We plan on releasing this as a separate piece of software (it currently lives in the context of archlinux-keyring) and maybe it will be of use for you.

[dvzrv]

Ping?