On June 13, 2024 10:46:59 AM UTC, Ian Jackson <ijack...@chiark.greenend.org.uk>
wrote:
>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.)
Maybe it's a matter of perspective, but I don't think that it is reasonable to
claim tag2upload as helpful relative to xz-utils. Even if tag2upload had been
available before the bad upload was made, it wouldn't have been helpful since
it wouldn't have been usable to upload it.
I agree that it might help with similar situations as long as a number of other
conditions are met, which are not the most common cases. Ultimately, I think
the claim has so many unwritten caveats that it's not useful relative to the GR.
Scott K
Scott K
