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
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature