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".
This has the hazard I have identified above. We (Sean and I -
Debian's git transition team) think this is a bad recommendation.
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.
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.
Ian.
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
