Simon Josefsson writes ("Re: Include git commit id and git tree id in *.changes
files when uploading? [and 1 more messages]"):
> Ian Jackson <[email protected]> writes:
> > We would generally recommend against using gbp import-orig.
>
> Please don't: gbp import-orig can be teached to work the way you want.
> Instead, encourage that configuration.
Currently gbp import-orig does not seem to have an option for
requiring that the tarball it's importing is treesame to upstream git.
Even if it did have an option to check the tarball contents was right,
it would be very tempting for a maintainer who's trying to get shit
done to override the check, rather than deciding not to import the
tarball at all, since they probably don't have a procedure they're
confident in that doesn't involve gbp import-orig. So what would be
needed is a mode for gbp import-orig where it is able to *not import a
tarball at all*, thus preferring git when tarballs and git disagree.
That way the user faced with a discrepancy can proceeed.
> > If the upstream orig tarball came out of git-archive then importing it
> > into git again is at best pointless
>
> I disagree with that as a general conclusion
I think we are going to have to agree to disagree about this.
> > 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.
...
> While I mostly agree, I think this is somewhat over-generalizing: 'gbp
> import-orig' can support the scheme you seem to prefer, unless I'm
> missing something. Recommend the 'upstream-vcs-tag' approach.
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.
> >> This leads to me to believe that it would be better to use 'git-debpush
> >> --upstream-tag=v1.2.3' instead of 'git-debpush
> >> --upstream-tag=upstream/1.2.3', right?
> >
> > Yes.
>
> It would be nice to document this somewhere. The consequences of this
> choice was not at all clear to me, and maybe others will be similarily
> confused in the future.
Sean, where do you think we should put this? We have our dgit
workflow manpages but we don't have that for git-debpush. Should this
be in git-debpush(1) ?
> >> Is there any advantage to using --upstream-tag=upstream/1.2.3?
> >
> > If your upstream's origs come from git-archive, none.
>
> One example to the contrary: git-archive from a Git SHA256 repository.
> It seems Salsa nor dgit supports these now?
So not any gitlab, nor github. Codeberg supports it AIUI but you
can't get there from a SHA1 repo. This is a largely theoretical
situation. See my other comments about git upstream's approach to
this transition.
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.
