Russ Allbery: > [...] > I worked on an update of my security review last night to take into > account the additional concerns that people have raised and other > feedback. > > [...] > > The source package signature can be used for three purposes: > > 1. Detect modifications to the source package after it was uploaded. > 2. Determine who uploaded this source package. > 3. Verify that the source package repesents the intent of the uploader. > > [...] > > For the third purpose, I believe only weak intent information can be > derived from the uploader signature today. It is common practice in Debian > to verify the Git tree that one wants to upload, run a package build step, > and then blindly sign the resulting source package. The uploader signature > therefore does not say that the uploader verified the correctness of the > source package, only that they triggered a build process and trusted its > results.
Assuming they run this on the same system, I don't think that for integrity protection the source package build process makes a meaningful difference. In both cases they run a tool they trust on a system they trust with singing access to their key. And if their system is compromised the attacker can modify what they push, whether it's a bunch of git objects or a source package. It might be a bit easier for someone else to spot a suspect git change, but that's far from given. Also based on the description in this thread at least for dgit workflows you can already generate and check that the uploaded source is tree-same. So someone actually reviewing things can review that step automatically. Also the code in the source package is not just a hidden artifact that is temporarily used during the build. It's surfaced at various places, like sources.debian.org, apt-get source, dgit clone, .... So spotting an unusual change by accident is possible here too. > This is equivalent in the tag2upload case except that the uploader > signature happens before the build process (on the Git tag) rather > than after the build process (on the source package). In both cases, > the uploader does not subsequently verify the content of the source > package; in both cases, if the system on which the source package is > built is compromised, the source package may be compromised and the > uploader signature step will not detect this compromise. But you are trusting the Developer system that signs the tag or source package anyway. If compromised it can simply sign malicious code in both cases. > Therefore, for this purpose, the current uploader signature appears to > provide stronger evidence of intent than it truly does. The signature on > the original Git tag triggering the upload provides equal evidence of > uploader intent. As described above I'm not convinced by that "intent" argument from a security point of view. (There are other advantages, and I think it's up to Debian to make the organizational decision if it wants tag2upload in that design. I'm just commenting here because I have followed the security discussion with interest.) What might be worth mentioning is that verifying the signature by the developer on a .dsc or a git tag, can be actually quite involved. Especially if you don't want to trust the Debian archive (which some seem to see as a feature of shipping the signed .dscs). You first need to find out when the signature was made without trusting the included timestamps (since they could be faked). Then check the state of the Debian keyring at that time. Then check if the key was revoked later. Then you can finally check the actually file signature. Given this I'm not sure if tag2upload would make it much harder (but yes you would need things not on the mirrors, although you already kind of need this for checking the timestamps).
OpenPGP_signature.asc
Description: OpenPGP digital signature
