Am 16.06.2024 21:11 schrieb Scott Kitterman <deb...@kitterman.com>:

Yes.  I think that's the core of the disagreement.  In my view, when I type the passphrase for my key, I'm asserting responsibility for the contents of what I'm signing.  It doesn't mean it is correct or uncompromised, but I am taking responsibility for it.

(When I say "you did/you signed" below, it's meant speculatively.)

Yes, but you still would take responsibility for the git tag (i.e. the repo content at that tag). What you would not take responsibility for is the source package that's generated from that. That's what tag2upload is responsible for (and thus signs that, with an annotation that it generated that based on the tag that you signed).
I find that quite similar to what build daemons do: generate binary packages from a source package and uploading them, with (sorta) reference to the source package they were generated from.

Personally, I find it easier to see and sign the content/source that is related to a git tag than signing a source package generated by dpkg-buildpackage. (Side note: I avoid git when I can.)

Given the two signatures, I can go from the source package in the archive, find the associated .changes file, see that it came from tag2upload (and verify that signature), look at the source metadata, find the git repo+tag and the info on the signature on the tag, verify the signature and see that you claimed responsibility for that specific tag and the associated repo state.

Which is actually more than I can currently see, since it shows me the specific source you signed, not the product generated from it (the source package). I'm not sure if you check the generated source packages (I usually didn't), but if you don't, you didn't sign what you saw (the repository content) but the resulting source package. If you do check the generated source package, respect, I don't believe most developers do.

Now, you might argue that tag2upload doesn't sign what it wants to sign either, but IMHO, it actually does. It claims that it generated the source package using trusted tools from the git tag you signed.

The design doesn't feel ideal to me, but it still seems like an improvement both in workflow and traceability to me. Provided that we trust the tag2upload service/server. There were proposals to improve this by the requiring two completely separate instances to upload identical source packages. Which I think is a good idea. 

Cheers, 
Sven

Reply via email to