On 08/01/26 at 11:12 +0000, Ian Jackson wrote: > I don't think gbp import-orig has a mode where it will defend its user > (and everyone downstream) against Jia Tan. Whereas, not running gbp > import-orig (and using git-merge or git-rebrebase instead) *does* > protect us, by simply ignoring the tarball. > > (Of course as the xz attacker was targeting Debian specifically, in > practice a better maintainer workflow doesn't foil the attack - > it forces Jia Tan to a more visible and so more risky attack vector. > We don't have a control universe to see what Jia Tan would have > written in the commit message and whether anyone would have noticed it > sooner, so we can't be sure how much it would have helped.) > > I find your focus on tarballs and your distrust of git perplexing. > The difficulties with SHA1 aren't negligible, but they have not been > used to carry out actual attacks and indeed I'm not aware even of > collisions (let alone second preimages) in git's hardened SHA1. > This is a largely theoretical problem, right now. > > Whereas Debian's practice of importing tarball contents, instead of > using only the actual source coce from git, was the vector used for > the most serious and successful attack we have faced in many years.
I think that you are arguing against using tarballs in general, while you should really be arguing against using tarballs like GitHub "releases" tarballs that are generated in an opaque way. Tarballs like GitHub tags tarballs that are automatically generated are not really less trustworthy than using the git repository directly. Of course one needs to trust the hosting provider, but that's also true when using git (the hosting provider could forge additional commits to inject vulnerabilities). Lucas
