Russ Allbery <r...@debian.org> writes: > Scott Kitterman <deb...@kitterman.com> writes: > >> I agree that there's a risk that what the uploader thought they were >> uploading and what they actually uploaded are different, but that's >> independent of tag2upload or not. > > 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. 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. 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. 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. 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. So now attackers are probably put off attacking large subsets of individual developer machines, but may be more interested in attacking the tag2upload or Salsa box if that leads to the same ability with lower cost. Debian has to my knowledge not published any information how private keys on centralized machines are protected and managed. Some developers (like myself) do publish information how they store and protect their private keys. This suggests to me that the argument that centralized Debian systems are unconditionally more secure than individual developers systems is not valid. 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. Still, I think Debian is already too deep in too many security and trust issues already that adding another attack vector will not break this camel's back. We are collectively good at handling technical/security incidents when they become public, so let's utilize that property to allow people to do what they want. The bigger problem in Debian is IMHO how some people use their technical powers to limit what other people can do effectively, and I think this is harmful. /Simon
signature.asc
Description: PGP signature
