bug#27943: tar complains about too-long names (guix release)

[Efraim Flashner]

On Tue, Nov 28, 2017 at 03:26:03PM +0100, Ludovic Courtès wrote:
> Hi Danny,
> 
> Danny Milosavljevic <address@hidden> skribis:
> 
> > guix $ make release
> > ... || chmod -R a+r "guix-0.13.0.1849-cf189-dirty"
> > tardir=guix-0.13.0.1849-cf189-dirty && ${TAR-tar} chof - "$tardir" | 
> > GZIP=--best gzip -c >guix-0.13.0.1849-cf189-dirty.tar.gz
> > gzip: warning: GZIP environment variable is deprecated; use an alias or 
> > script
> > tar: 
> > guix-0.13.0.1849-cf189-dirty/gnu/packages/patches/ghc-dont-pass-linker-flags-via-response-files.patch:
> >  file name is too long (max 99); not dumped
> > tar: 
> > guix-0.13.0.1849-cf189-dirty/gnu/packages/patches/libevent-2.0-evbuffer-add-use-last-with-datap.patch:
> >  file name is too long (max 99); not dumped
> > tar: 
> > guix-0.13.0.1849-cf189-dirty/gnu/packages/patches/python-genshi-stripping-of-unsafe-script-tags.patch:
> >  file name is too long (max 99); not dumped
> > tar: 
> > guix-0.13.0.1849-cf189-dirty/gnu/packages/patches/python2-pygobject-2-gi-info-type-error-domain.patch:
> >  file name is too long (max 99); not dumped
> > tar: 
> > guix-0.13.0.1849-cf189-dirty/gnu/packages/patches/t1lib-CVE-2011-1552+CVE-2011-1553+CVE-2011-1554.patch:
> >  file name is too long (max 99); not dumped
> > tar: Exiting with failure status due to previous errors
> > make[1]: Leaving directory '/home/dannym/src/guix-master/guix'
> 
> “make dist” works fine for me with tar 1.29:
> 
> --8<---------------cut here---------------start------------->8---
> || chmod -R a+r "guix-0.13.0.3626-da9b8"
> tardir=guix-0.13.0.3626-da9b8 && ${TAR-tar} chof - "$tardir" | eval GZIP= 
> gzip --best -c >guix-0.13.0.3626-da9b8.tar.gz
> make[1]: Leaving directory '/home/ludo/src/guix'
> --8<---------------cut here---------------end--------------->8---
> 
> Actually,
> “guix-0.13.0.1849-cf189-dirty/gnu/packages/patches/ghc-dont-pass-linker-flags-via-response-files.patch”
> is 101-character long, so without the “-dirty” prefix as above, we’re
> doing OK.  :-)
> 
> Anyway, commit eef01cfe8eac8dee8ecf727e4ca459ae065e15ea augments the
> ‘patch-file-names’ linter to catch this issue.
> 
> There’s one problematic case left, which is t1lib, but I volunteered
> Efraim to split the big CVE patch in several ones.  :-)
> 
> Thanks,
> Ludo’.

It gets worse than that, our t1lib-CVE-2010-2462 is also CVE-2011-0433
and CVE-2011-5244.¹

I tried creating a blank patch (touch t1lib-CVE...) and adding that to
satisfy the linter (and bookeeping) but unsuprisingly patch didn't like
trying to apply a blank file as a patch.

Debian removed it after squeeze², which was Debian 6, so about 6 years
ago. Gentoo apparently still has it³. We don't have anything that
depends on it so I'm in favor of removing it; even the upstream homepage
is gone.

This doesn't deal with the possibility that patches that address
multiple CVEs that can't be split easily and have a very long name will
continue to occur, so the best option I can think of right now is to
change the linter to logic like this:

CVE- -> The following are all CVEs
YYYY-ZZZZ???? -> Full CVE reference
ZZZZ???? -> Follows the year of the previous CVE

which would change t1lib-CVE-2011-1552+CVE-2011-1553+CVE-2011-1554 ->
t1lib-CVE-2011-1552+1553+1554,
and our under-referenced t1lib-CVE-2010-2642 ->
t1lib-CVE-2010-2642+2011-0433+5244


¹ https://github.com/gentoo/gentoo/pull/2906/files
² https://sources.debian.net/src/t1lib/
³ https://security.gentoo.org/glsa/201701-57

-- 
Efraim Flashner   <address@hidden>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

signature.asc
Description: PGP signature