PGP signatures for packaging

[dvzrv]

Hi! I'm about to package netavark for Arch Linux. This is more of a general inquiry about how this project will handle PGP signatures for tags and/or release artifacts.

As a short background info: We are able to use PGP signed source tarballs or PGP signed tags for building a given upstream. This is all assuming that a chain of trust between releases is maintained by upstreams though.

Currently it seems that @baude is using 74FE091D25519980B2D84447160386BECB6F0643 to sign the tags of this project and has therefore started a chain of trust (of length 1 :) ):

pub   ed25519/160386BECB6F0643 2022-02-10 [SC]
      74FE091D25519980B2D84447160386BECB6F0643
uid                 [ unknown] Brent Baude <bbaude@redhat.com>
sub   cv25519/4CA7B97243164176 2022-02-10 [E]

At the time of writing I was not yet able to find the PGP key anywhere else but here on github via the developer's profile page (probably because it is still very new).

Given that a bus factor == 1 on releases is never a good idea and that we have seen issues with the chain of trust with quite a few projects in the past, I would like to hereby ask about your stance on the topic for this project.

Are you able to ensure, that

• you maintain a chain of trust (i.e. cross signatures between keys, or by signed changes to a document such as the README) between different keys of the same developer
• you maintain a chain of trust (i.e. cross signatures between keys, or by signed changes to a document such as the README) between keys of existing and new developers
• you do not allow releases by developers outside of the chain of trust

Answering the above will help us a great deal in assessing whether we can rely on the PGP signed tags or not. Thank you! :)

[baude]

would Matt Heon's signature be better? He is the one that signs podman.

[dvzrv]

would Matt Heon's signature be better? He is the one that signs podman.

It's not so much about the "who" but more about the "how" in this case.
The chain of trust is TOFU by design at the beginning (and you are the first one to sign tags in this repository and make releases). Going forward it is more important to have an intact chain of trust between releases (i.e. the releases are always signed either by you or by someone that you "legitimize").
This can be done by signing their PGP key and/or by stating this in a (section of a) document in this repository that is only altered using signed commits.
The latter can be done in the README in a separate section that lists the people and their PGP key IDs, who are legitimized to do releases (see e.g. how qtile is doing that, while having cross-signed keys).

Establishing a chain of trust basically enables outsiders to verify that you "trust" the given other person to do releases as well and outsiders may then use those respective keys to verify their signed tags.

[baude]

@dvzrv understood. let us rap about this as a team this week.

[mheon]

Getting everyone on the team authorized to do a release together and doing mutual signatures on our keys seems like a perfectly doable thing that should resolve this, so long as we can figure out how to actually distribute the keys once this is done; I remember that we had a second developer do a Podman release to ensure I wasn't the only one capable of doing so, and that was rather a mess as I was able to sign her key, but not to actually upload the signed version anywhere. I don't think PGP key distribution has improved much since then, unfortunately. Maybe we should just publish the public keys of everyone with release authority in a repo under the containers/ org? Though then we run into security concerns if that repo were to be compromised...

[dvzrv]

Providing a separate repository with relevant PGP public keys (and their signatures) could work.
However, on a company level this should really be solved by a Red Hat wide Web Key Directory (WKD) setup, so that noone has to rely on flaky keyservers (which may or may not support key types and or signatures in use) anymore :)

[dvzrv]

Gentle bump on whether there has been any progress on this :)