Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> 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.
You removed the essential part of what I wrote. After the commands
above, and before your quote, I wrote:
> in a "friendly low-complexity upstream" case when 1) debian/gbp.conf has
> upstream-vcs-tag and 2) debian/watch points to upstream git? Assume we
> don't have to care about debian/copyright Files-Excluded and other
> complexity that doesn't hold for >50% of packages.
With those limitations, I don't think the attack you describe works. By
having 'gbp import-orig' import verbatim pristine git from upstream, you
avoid the hard-to-audit upstream tarball. Or can you describe how
things would go wrong in that setup?
/Simon
Attachment:
signature.asc
Description: PGP signature