Ian Jackson <[email protected]> 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
signature.asc
Description: PGP signature
