OpenPGP signatures for releases

[dvzrv]

Hi! 👋

I'm currently en-route packaging this project for Arch Linux, as we need it for latest ostree.

If available, we usually also want to rely on OpenPGP signature verification on top of checksum validation of sources.
To not run into issues later, I would like to make sure you are providing OpenPGP signatures intentionally and are also interested in providing a trust path between releases for this project (as without trust path guarantees I will not consider using OpenPGP for signature verification).
Further, I would like to point out that the key currently in use (6A2B067FB5E17A1A3FC8A0DAEB6216DDB76C70E9) relies on unsafe cryptographic mechanisms (DSA1024). As the key material can be considered forgeable, I am currently not considering it for OpenPGP signature verification. It would be great if you could create a new one, cross-sign it with your old one and then permanently move to the new one.

In regards to trust path between releases:
@alexlarsson you seem to be the only person creating releases for this project so far.
Are there plans for others to also create releases (which is usually a good idea, given bus factor and all)? If so, are you planning to provide a trust path between releases up front?
By trust path between releases I mean one of:

• adding your own OpenPGP fingerprint as well as any other person's OpenPGP fingerprint, that will be allowed to create releases to a document in this repository in a commit signed by your current key before a new person creates a release with a key unknown to us
• certifying (aka. cross-signing) User IDs of any new person allowed to create releases (in advance), so that downstreams such as Arch Linux can cryptographically verify a path between you and any new person allowed to tag (and sign) releases.

Thank you for your time! 🙇

[cgwalters]

This is just my soapbox but I created https://github.com/cgwalters/git-evtag long, long before the xz fiasco was a reality.

I think what we should sign and what people should build by default is from the git commit. Which nowadays, can be signed with SSH signatures (the same one people use to push, which need to be maintained). OpenPGP and trust chains and maintaining keys is just...well, a whole distinct thing.

So what do you think about that? We just stop publishing pre-generated tarballs here, and if you want integrity, fetch the tagged release git commit which should be signed with e.g. git-evtag.

[dvzrv]

We don't really have integration for git-evtag in our package tooling as of yet, so I am not sure whether your proposed scheme will work for validation or not. Would we need git-evtag for validation?

We are able to create checksums for the contents of a given git object (can be a commit or tag object). In a way that is similar to what git-evtag achieves (as we usually aim for sha512 or b2 sums).
In short, we are able to rely on strong checksums for either git objects or tarballs already (but they are set outside of the context of a given repository and rely on the particular implementation's way of creating a git archive).

That said, the OpenPGP signature also has value for us, but for different reasons: To ensure a trust path between releases. This ticket exists, because the trust path validation is a separate topic from source checksum validation and I would like to find out whether I can rely on it or not (which depends on the project).

So what do you think about that? We just stop publishing pre-generated tarballs here,

I have no particular feeling about pre-generated tarballs (if anything I avoid them at all costs already anyways). This is really up to you as a project.

and if you want integrity, fetch the tagged release git commit which should be signed with e.g. git-evtag.

This still leaves my question open about whether this project is able/ wants to uphold an OpenPGP trust path for releases or not.

[dvzrv]

@cgwalters As an additional data point, I would like to point out that - to me - this interaction feels a bit like a non-answer, given that I got a similar reply in ostree in 2021 (see ostreedev/ostree#2349) and ever since that ticket has been stalling.

I understand that these things are not necessarily high priority for a team working on a project. Coming to a conclusion would be great though (specifically wrt to the particular issues raised) as this helps me to either close a topic or implement a solution for it.

[kpcyrd]

I took the liberty to check what vendors currently consider "the source code of composefs 1.0.3" and there's two different artifacts at the moment:

• sha256:16ae1477cd08a1bdcf7def60a59a129438a15ef1c2a8a593a4dbfb531aca7b68 according to Arch Linux
  • Provenance: https://github.com/containers/composefs/archive/refs/tags/v1.0.3.tar.gz
• sha256:096d8d76e3e1f93c7de78d3a0783bc6852c08bccce19bd8292c32aa3123686e2 according to Fedora
  • Provenance: https://github.com/containers/composefs/releases/download/v1.0.3/composefs-1.0.3.tar.xz

There's a diff available. Note the content of composefs-1.0.3.tar.xz is not sorted alphabetically, the linked diff explicitly sorts them beforehand.

@dvzrv is asking for a signature on the sha256:16ae1477cd08a1bdcf7def60a59a129438a15ef1c2a8a593a4dbfb531aca7b68 tarball since it's content matches the git tree-ish of the git tag, while sha256:096d8d76e3e1f93c7de78d3a0783bc6852c08bccce19bd8292c32aa3123686e2 clearly doesn't.

Any kind of pre-processing of the VCS source code needs to happen on Arch Linux build servers to be secured by Arch Linux reproducible builds infrastructure.

If you prefer ssh signing or cosign Arch Linux can integrate with this in the prepare() function, see e.g. the libchewing PKGBUILD. The only quirk is, this verification happens after the archive has been unpacked.

[dvzrv]

@dvzrv is asking for a signature on the sha256:16ae1477cd08a1bdcf7def60a59a129438a15ef1c2a8a593a4dbfb531aca7b68 tarball since it's content matches the git tree-ish of the git tag, while sha256:096d8d76e3e1f93c7de78d3a0783bc6852c08bccce19bd8292c32aa3123686e2 clearly doesn't.

No, I am asking whether this upstream is willing to uphold a trust path going forward (see #281 (comment)) and whether the currently used OpenPGP key can be exchanged for a new one.
The tag is already signed:

git verify-tag v1.0.3
gpg: Signature made 2024-01-29T14:14:07 CET
gpg:                using DSA key 6A2B067FB5E17A1A3FC8A0DAEB6216DDB76C70E9
gpg:                issuer "[email protected]"
gpg: Good signature from "Alexander Larsson <[email protected]>" [unknown]
gpg: WARNING: The key's User ID is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 6A2B 067F B5E1 7A1A 3FC8  A0DA EB62 16DD B76C 70E9

[alexlarsson]

Honestly, I don't really think we have a defined process here. I just sort of by default sign release tags with my (admittedly ancient) gpg key. So, no, at this point I don't think I don't think you can robustly rely on use upholding a trust path for every release. Maybe in the future we can make a project-wide decision here.

That said, I will at least try to update my personal key to a larger one.

[dvzrv]

Honestly, I don't really think we have a defined process here.

I understand and that's entirely fine :)

Maybe in the future we can make a project-wide decision here.

If you do, please ping me! :)

Feel free to keep this ticket open until then or close and re-open (or whatever suits best).

[alexlarsson]

I'll close this for now