On Tue, 2024-06-25 at 07:42:11 +0200, Matthias Urlichs wrote: > On 25.06.24 01:26, HW42 wrote: > > 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. > > It's not that easy.
[ rearranged paragraphs ] > Hiding compromised code in git is difficult, given that actual people > routinely look at commit histories and diffstats and diffs, esp. right > between "I create the signed tag" and "I push the t2u tag to Salsa" (we > could even tell the push script to show the git log by default before doing > so). How often do people look at merge commits? I'm in general not a fan of using merge-based workflows because they make the history "dirty" and way harder to review and understand. I do use «git show» on merge commits if I want to see what did really change there (but that outputs "diff-of-a-diff" by default, which is good to detect spurious additions but people were complaining about this format for debian/patches/ in git), I might «git diff» the entire branch points (but that can become very tedious with huge changes), but in general I simply use «git log -p», so merge commit changes disappear from sight. I even had to look up the option to show merge commits with «git log -p» (that is --diff-merges), but its output seems pretty terrible in general. Using «git merge --no-commit» and then adding anything there (or amending it) is trivial, and could easily go unnoticed with a big merge, even more when merging a new upstream release for example (depending on the packaging workflow). And you'd need to compare what a clean merge would become against what the trojaned merge ends up being, which I doubt anyone is doing? Perhaps people are checking some other way? I created this small example repo: https://git.hadrons.org/cgit/wip/git-sneaky.git/ https://salsa.debian.org/guillem/git-sneaky On the web side, if you go into the merge commits, then for this simple example the change is visible in both cgit and salsa, but not obvious that it was an addition on top of the merge (like with diff-of-a-diff), but if you drown it with other changes then it seems it could easily go by unnoticed. On the CLI, I doubt (although might be wrong) people usually look at them? > Hiding compromised code in our tarballs is easy. Nobody will ever look at > them (ordinarily) and you only need a single shell script running as the > developer in question; given inotify it doesn't even show up in "top" while > it waits for an opportunity to strike. I either use debdiff to compare tarballs, or unpack them and «diff -Naur» the two trees, but depending on the magnitude both approaches can indeed get unwieldy, just like «git diff». But I probably do this more often than checking merge commits. If the tarballs include autogenerated stuff, then that makes it easier to inject into. But both quoted statements seem a bit reductionist. If tarballs do not include autogenerated stuff, then diffing them is pretty easy, and you are sure there are no hidden traps behind a merge commit for example. The same goes for git with a fast-forward history with no merge commits and no autogenerated files. Otherwise ISTM git could also be as susceptible or more to trojaning than a tarball with no autogenerated stuff within. And by its nature I think git will always offer more places to hide stuff than within a bare tarball. Thanks, Guillem
