Simon Josefsson <si...@josefsson.org> writes: > Russ Allbery <r...@debian.org> writes:
>> But it's not independent; tag2upload makes this story somewhat better. >> tag2upload is based on a signed Git tag and moves the source package >> construction off of the uploader's system onto more-secure project >> infrastructure. > I've seen this notion repeated a couple of times now, and I don't think > it is a good argument nor that it is particulary relevant to tag2upload. I hear what you're saying, I think your analysis of the security trade off is partly correct, and I still disagree about the conclusion: I think tag2upload makes this better. I think the level of security that we can provide to a central host really is that much higher than the level of security on individual uploader machines, even though this centralizes risk. > One problem is that the tag2upload design aggregates and amplify the > consequences of one successful compromise. Thus the standards of > security of that single centralized machine has to be higher than the > standards for security of developer machines, since there is a more > limited number of things each individual developer machine can do. Yes, agreed. This is standard for a "put all your eggs in one basket and protect that basket" design. As with dak and with buildds, we should try to use as many hardening approaches as we can manage for the tag2upload server. > A more reasonable security comparison here is to compare the security of > the tag2upload design with the security of compromising ALL of the > Debian developers. Both goals leads to similar abilities for the > attacker. This, however, I will object to. I can see the argument *if* tag2upload completely broke the provenance chain and didn't publish any information about how to reproduce its work. Then one could argue that it would be equivalent to the source package construction on each maintainer system, but centralized. However, that's not the case. Compromising the tag2upload server gives you the ability to upload source packages purporting to be from arbitrary Debian developers, but the detection and tracing is much better than compromising every developer system. The information required to figure out that the tag2upload server is compromised is published, and I have a lot of hope that we can automate that detection. Compare that situation to a compromise of an uploader's system. Even if they keep their signing key secure (on a hardware device, on a separate system from where they do source package builds), they are likely to sign malicious code without noticing if it is injected at the right point. And in that case there is then no trace in the archive that we could use to detect that this has happened except for the malicious code itself. > You have to look at security consequences from the attacker point of > view, not the point of view of each (hopefully benign) user of the > system. Yes, I completely agree. > Successfully attacking ALL individual developers, with each own > individual security weaknesses, seems to me more costly than attacking a > single known publicly run instance like tag2upload or Salsa. I also agree with this; I just don't think these cases are equivalent. > Debian has to my knowledge not published any information how private > keys on centralized machines are protected and managed. My understanding is that dak stores its key in a hardware device so that the private key cannot be exfiltrated by a dak compromise, and the plan is to use the same design for the tag2upload server. That's been mentioned deep inside this thread, but I forget if that is explicitly called out in the design. If not, it would be a good thing to mention. I'm all in favor of more documentation about Debian as a whole documents private keys. > My perspective is that for all projects that rely on non-free > software/hardware we have to assume that the output is compromised, > since it is impossible to do a complete audit of the components. I think that's an interesting ideological position but not really that defensible of a security analysis. That said, if there are good OpenPGP hardware keys that are also free software and hardware, I'm certainly in favor of using them if feasible. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
