On Wed, 12 Jun 2024 at 15:20:45 +0100, Ian Jackson wrote:
> tag2upload, like dgit, ensures and insists that the git tree you are
> uploading corresponds precisely [1] to the generated source package.
>
> If you base your Debian git maintainer branch on the upstream git (as
> you should) and there is a discrepancy between the contents of the
> upstream git branch, and the .orig.tar.gz you're using, the upload
> will fail.
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?
That approach has many advantages, but it flatly contradicts what devref
claims a Good™ maintainer would do, which is to always use the pristine
source tarball as released by upstream (unless it's non-free) - which
implies that if they're using dgit, then the upstream tree must match
an import of the tarball.
Or are you saying that we should simply not package software produced
by such upstreams? (If that, we're going to need replacements for most
of GNU...)
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.
> In the xz case, if the .orig.tar.gz is upstream's, that would have
> detected the attack.
xz-utils is built using Autotools, so if the .orig.tar.gz is upstream's
`make dist`, it is *always* going to differ from what's in git[1]: for
example ./configure exists in the tarball but not in git. The xz attacker
was counting on that - the glue code to activate their malicious payload
was hidden in a diff that was already expected to be inconveniently
large for reasons that are usually considered to be benign.
It would be easy to say "well your upstream shouldn't behave like that"
but, realistically, many of them do, and they are not all going to change
just because we say so.
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.
smcv
[1] unless your upstream is one of the rare upstreams that is happy to
commit all the Autotools-generated files to upstream git, which
comes with its own problems
