Hi, On Mon, 12 Jan 2026 at 05:26, Ian Jackson <[email protected]> wrote: > Simon Josefsson writes ("Re: Please don't stop using uscan (Re: Include git > commit id and git tree id in *.changes files when uploading?)"): > > Could you [Otto] clarify if 'gbp import-orig' will do anything > > substantially different than > > > > git checkout upstream > > git fetch up > > git checkout -B upstream up/v1.2.3 > > git checkout debian/latest > > git merge upstream > > I believe: *yes* it does something different - something hazardous. > As I wrote, earlier: > > To put it more tendentiously: gbp import-orig's function is to import > the xz attack trigger, from the hard-to-audit upstream tarball, into > Debian's git, so that we can ship the vulnerable library, despite the > attack being only in dormant files in a test subdir in upstream git. > > This relieves Jia Tan of the need to put the attack trigger into git > where it is more visible so more likely to be detected. > > Otto Kekäläinen writes ("Re: Include git commit id and git tree id in > *.changes files when uploading? [and 1 more messages]"): > > If there are others who were not fully familiar with how > > git-buildpackage option `upstream-vcs-tag` or command `import-ref` > > works, and most importantly that this can be used to import both > > upstream as a pure git commit/tag with the tarball produced by uscan > > on top of it, I think you will find > > https://optimizedbyotto.com/post/debian-packaging-from-git/ a useful > > read as it explains a full example end-to-end with diagrams and > > "screenshots". > > As I understand it, this workflow privileges orig tarball content over > git content. I think that's what Otto means by "with the tarball > produced by uscan on top of it".
You don't have to guess what I mean - the blog post above is very explicit and you can also look at the example packages in it, or actually any package I maintain, to see that the upstream git release tag is imported with git (thanks to debian/gbp.conf:upstream-vcs-tag) and then the tarball (or whatever uscan downloads) is put on top of it. If they are exactly the same, there is an empty commit proving that there was no difference. If there is a difference, the commit diff will show exactly what it was. > This has the hazard I have identified above. We (Sean and I - > Debian's git transition team) think this is a bad recommendation. You should probably talk about "dgit team" and/or "tag2upload team". The term "git transition" should be reserved for contexts that refers to everyone advancing git usage in Debian, such as the DEP-14 authors, git-buildpackage developers, Salsa admins, Salsa CI developers etc. To me it seems you are trying to portray yourself as promoting git, and label people who disagree with some of your comments or point out flaws or gaps in your approach as if they are not on board on a git transition. Again, you can see that 100% of my Debian source packages are hosted in git (on Salsa), and for every single package where upstream uses git, I have configured git-buildpackage to import the git release tag/commit. I can on all of my packages run commands such as `git blame` to see exactly where each change came from (Debian or upstream, and which upstream commit) and submitting patches to upstream is as easy as switching the git branch and cherry-picking a commit from the `gbp pq` queue to a upstream submission branch etc. In the specific message you quoted I am simply advocating for people to not stop using `uscan` and `debian/watch`, as Debian's infra currently depends on them. > To do this, one would need a workflow capable of dealing with orig > tarballs at, but which will avoid this hazard by preferring the git > contents over the tarball. That means not just failing if the two > disagree, but also then disregarding the tarball (or guiding the user > to do so). > > See my reply to Lucas. > > > Note that in XZ Utils the actual backdoor was in test files that were > > commited to git, and the Autotools change to compile them in was in > > the upstream tarball. If Debian (or Fedora) only imports upstream git > > contents, the attacker would most likely put both parts into git. > > As I wrote earlier in this thread: > > (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.) > > > Stating that by not importing the tarball such attacks can be > > prevented does not hold true. > > I have never made this claim. Otto should stop misrepresenting me. > > I *have* said that not importing tarballs makes the attack harder, > and less likely to succeed. Which is true. I don't believe I am misrepresenting you. You frequently use language in emails, bug reports (e.g. #1109423), and also in DebConf talks, that suggest people should stop using tarballs and refer to the XZ case as if it would have been mitigated if Debian had stopped using tarballs for upstream imports. In this very thread you are suggesting Simon J use 'gbp import-ref' instead of 'gbp import-orig --uscan' and took up XZ as an argument on why you consider tarballs dangerous. I agree that in this paragraph you _do_ clearly acknowledge that we don't actually know if not using tarballs would have actually helped: > 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 would however like to point out that even though we don't have a parallel universe, we do have the other half of the attack and the malicious git commit that it was added in, and that does give us a data point that in this project bad commits got in unreviewed, and uncontested, as the attacker had taken control of the entire project. See https://optimizedbyotto.com/post/xz-backdoor-debian-git-detection/ for more details and longer writeup of my conclusion. > How much harder is a matter of judgement, of course. Maybe we should > play a game of CV? I have a PhD in computer security, and two to > three decades of real-world experience in my various day jobs, before > we even start counting my side projects. I think this kind of remark is inappropriate in Debian, and against Debian's ethos and potentially also Debian's diversity statement, so I have CC'd the Community Team to take notice. This feels yet again as a personal attack trying to silence me, or anyone else in Debian, who is not privileged enough to hold a PhD from a prestigious university or otherwise not "professional" enough. Even though I don't have the ability to write as eloquent English as you, I have done a serious attempt at presenting my arguments extensively, along with references to londer writeups and concrete examples. People should be able to look at them and draw their own conclusions regardless of what my credentials are. - Otto
