On 16.06.24 21:11, Scott Kitterman wrote:
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.
Right. But in both cases what you're signing is a random hash consisting of bits you didn't personally verify. IMHO, asserting that responsibility means that I'm able to verify that yes, what I say I'm signing is what I actually intend to sign – and that I'm able to prove this assertion next month when somebody accuses me of smuggling an exploit into Debian.
Using tag2upload presumably you can do a "git fsck" and "git status" and whatnot to verify that what git says you signed corresponds to what git says the contents referred to by the current HEAD (and hence the generated tag are). Assuming of course that your git and the (few) libraries it uses aren't compromised.
More to the point, the system that receives your tag doesn't even need to trust your git. It has its own, thus your compromised source needs to get pushed to Salsa, where the bad code is readily visible (assuming somebody takes a look) (unless somebody managed to also compromise Salsa).
On the other hand, when you're uploading signed sources you trust whatever tool cleaned, patched/assembled/combined/your-git-workflow-here'd and tarballed your sources. This includes a significantly larger toolchain as well as the absence of unrelated compromised code on your system that e.g. detects the "tar" command and swiftly adds+undoes a backdoor to some file – one attack vector of many. Worse, it's up to random chance whether anybody will ever look at the source you just generated, yourself included, given that everything's supposed to be in git. The xz compromise amply demonstrated this problem.
-- -- mit freundlichen Grüßen -- -- Matthias Urlichs
OpenPGP_signature.asc
Description: OpenPGP digital signature
