Russ Allbery <r...@debian.org> writes: > HW42 <h...@ipsumj.de> writes:
>> And, if yes: Why wouldn't they do the equivalent with the sources in >> git (work on the less trusted system, transfer commits (git push/pull) >> to the system with signing access and sign there, without review)? > They will, I assume. But tag2upload requires that the malicious code > that could be added during that process be pushed to Salsa or the > signature will not validate and tag2upload will fail. My contention is > that this makes detection of the attack easier. Oh, I'm sorry, now I see your point. You're saying that my contention that tag2upload is better at prevention of attacks via the developer's local system is not correct because the same attack can be done during Git signing. I think I didn't get this quite right in that part of the review, but my point is that having to push commits to the Git repository makes detection more likely *before* the upload, and detection before the upload is prevention. I'm not sure how to get at this point without using a lot more words, though, so maybe I should just relax the claim to say that I think tag2upload is better at detection and tracing, which is obviously correct. But let me write this up anyway, since I'm thinking about. It is true, in theory, that if a system is compromised, every command run on that system is suspect, and attackers can hide any activity and modify any tool output that they choose. In general, because I'm a hardening person primarily, I try to analyze systems assuming that case. However, *in practice*, most attackers, even sophisticated attackers, are nowhere near that careful. Most attackers get caught because they do something that makes noise. Staying entirely silent is quite challenging. What that means in practice is that the more things a human looks at that the attacker has to hide, the more likely it is that someone will detect the attack, possibly early enough to prevent it. Pushing a Git branch produces different output than pushing a Git tag: the uploader might notice. Pushing a tag that isn't on a commit in the direct history of the working branch means the tag doesn't appear in git log: the uploader might notice. If the addition isn't done carefully, the uploader may see the attacker's commit in git log or on Salsa and notice. Building a source package is a lot more opaque and gives the attacker a lot more room to hide. Adding malicious code to tar to inject something into source packages is a lot quieter: the contents of the tar file are no longer what the uploader expected, but there's no reason for the uploader to look at the tar file after the build process is done, or use much care in eyeballing it, since 99.9% of the time it will look exactly like what they expect. Back in the day when we were all using the 1.0 source format, I often did read at least a filterdiff version of the Debian diff; now, with 3.0 (quilt) packages, I never bother. And if the malicious code is hidden in debian/rules in the source package during the build process, I don't think I'd ever notice unless Lintian did. I think (my guess at) your critique is correct: I shouldn't say prevention here because there isn't real protection against a compromised uploader system in either approach. It's specifically a detection and tracing advantage. But I do think having to push the attack into the Git repository raises the chances that the detection might be early enough that someone can throw up a quick alarm and get the source package rolled back before there's serious damage done. Stuff hiding in the build source package is a lot sneakier. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
