Scott Kitterman writes ("Re: [RFC] General Resolution to deploy tag2upload"):
If I am understanding you correctly, tag2upload is only relevant to the XZ Utils type attack if the maintainer uses the upstream git rather than the upstream provided tarball as the basis for their Debian work. Is that right?
Yes. It is precisely using the upstream git, rather than the upstream
tarball, that eliminates the gap through which the exploit activation
was smuggled in this case.
(Whether the maintainer could uwe the upstream tarball as the
.orig.tar.gz, while using upstream git as the basis for the package
contents, is a complicated question.)
If so, it seems to me that is entirely tangential to this proposed GR.
No, because it is not sufficient to base the maintainer git repository
on the upstream git. It is also necessary that something checks that
those files in the .orig.tar.gz which aren't patched in
debian/patches/ correspond precisely to the git tree the maintainer is
working with.
This check is done by `dgit push-source`, and by tag2upload.
But it is often not done by other workflows. (Because there are so
many workflows, it is difficult to make fully general statements.)
Simon McVittie writes ("Re: [RFC] General Resolution to deploy tag2upload"):
Is your position here that if your upstream releases source tarballs
that intentionally differ from what's in git (notably this is true
for Autotools `make dist`), then any Good™ maintainer must generate
their own .orig.tar.* from upstream git and use those in the upload, disregarding upstream's source tarball entirely?
I don't think I would state that as a general rule. I would rather
say that if upstream provides signed git tags, it is *usually* better
to only use upstream git, and ignore the upstream source tarball.
I'd prefer not to be in a situation where whatever a maintainer does,
some segment of the project will consider them to be failing to meet
the project's basic expectations - that seems like a recipe for burnout.
Debian is a very large and old project now and we have a very wide
range of opinions and workflows. And our mechanisms for resolving disagreements don't work well. I'm think that the problem you lament
already exists.
One non-goal of the tag2upload project is to try to reconcile all
this. Rather, we want to provide a new option, that is convenient,
makes it easy to follow good practices, and will be welcomed and can
be adopted widely.
In the projects where I'm an upstream maintainer, I *am* trying to move towards the official source release being equivalent to a `git archive` (including replacing Autotools with Meson, replacing submodules with subtrees, etc.), but I don't have the resources or social capital to do
that instantaneously, even in the few projects where I have influence.
Yes.
Simon McVittie writes ("Re: source tarballs vs. source from git (was: tag2upload)"):
I think the claim here might be that Debian should stop dealing with
upstream source tarball releases, and instead have the packaging be
branched from upstream git?
That is how I usually prefer to work, personally.
My claim here, specifically, is that working this way would have made
the xz attack harder.
As a concrete example, for bubblewrap_0.9.0 (a convenient example
of a relatively small package), that would mean that instead
of having our packaged version of bubblewrap be based on the bubblewrap-0.9.0.tar.xz with sha256 c6347eac... which can be downloaded
from https://github.com/containers/bubblewrap/releases/tag/v0.9.0, our packaged version of bubblewrap would be based on the tree that forms part
of the tagged commit 8e51677a... in upstream git.
Yes, precisely.
If we did that for xz-utils, then the xz-utils attacker would have
had to include the glue code to activate their malicious payload in
the upstream git history, and not just the official tarball release -
which would hopefully have made it more likely that it would have been discovered before we integrated the malicious version.
Exactly.
I think that's going to be a harder sell for some packages than for
others.
Yes. That's why we're not saying this way of working is (or should
be) mandatory.
As far as I know, git-archive (and therefore git-deborig) doesn't guarantee that repeatedly archiving the same git tree produces the same tarball,
which could be awkward for the ftp archive's tarball-integrity-based rules; but hopefully tag2upload would insulate individual developers from that by always "doing the right thing" for the current contents of the archive?
Yes, it does. Specifically, it won't make a new orig if the archive
already has one.
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.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)