GNU bug report logs - #27943
tar complains about too-long names (guix release)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 27943 in the body.
You can then email your comments to 27943 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: <bug-guix <at> gnu.org>
Subject: tar complains about too-long names (guix release)
Date: Fri, 4 Aug 2017 09:22:12 +0200

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'

Message #10 received at 27943 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: 27943 <at> debbugs.gnu.org, Efraim Flashner <efraim <at> flashner.co.il>
Subject: Re: bug#27943: tar complains about too-long names (guix release)
Date: Tue, 28 Nov 2017 15:26:03 +0100

Hi Danny,

Danny Milosavljevic <dannym <at> scratchpost.org> 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’.

Message #13 received at 27943 <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Danny Milosavljevic <dannym <at> scratchpost.org>, 27943 <at> debbugs.gnu.org
Subject: Re: bug#27943: tar complains about too-long names (guix release)
Date: Thu, 30 Nov 2017 15:05:10 +0200

[Message part 1 (text/plain, inline)]

On Tue, Nov 28, 2017 at 03:26:03PM +0100, Ludovic Courtès wrote:
> Hi Danny,
> 
> Danny Milosavljevic <dannym <at> scratchpost.org> 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   <efraim <at> flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[signature.asc (application/pgp-signature, inline)]

Message #16 received at 27943 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: Danny Milosavljevic <dannym <at> scratchpost.org>, 27943 <at> debbugs.gnu.org
Subject: Re: bug#27943: tar complains about too-long names (guix release)
Date: Thu, 30 Nov 2017 14:55:52 +0100

Hi Efraim,

Efraim Flashner <efraim <at> flashner.co.il> skribis:

> 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.

Yeah that’s no good.

> 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.

I don’t have an opinion.  Could you poll guix-devel?

> 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

I thought about it, but since it’s an unsual case, what about adding a
special property to packages instead?  You’d write:

  (package
    ;; …
    (properties '((fixed-vulnerabilities "CVE-123-4567" "CVE-123-4568"))))

‘guix lint’ would honor this property, and that would address both cases
like this and situations where a CVE is known to no longer apply, as is
the case with unversioned CVEs¹.

Thoughts?

Ludo’.

¹ http://www.openwall.com/lists/oss-security/2017/03/15/3

Message #19 received at 27943 <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Danny Milosavljevic <dannym <at> scratchpost.org>, 27943 <at> debbugs.gnu.org
Subject: Re: bug#27943: tar complains about too-long names (guix release)
Date: Thu, 30 Nov 2017 23:49:01 +0200

[Message part 1 (text/plain, inline)]

On Thu, Nov 30, 2017 at 02:55:52PM +0100, Ludovic Courtès wrote:
> Hi Efraim,
> 
> Efraim Flashner <efraim <at> flashner.co.il> skribis:
> 
> > 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.
> 
> Yeah that’s no good.
> 
> > 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.
> 
> I don’t have an opinion.  Could you poll guix-devel?
> 
> > 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
> 
> I thought about it, but since it’s an unsual case, what about adding a
> special property to packages instead?  You’d write:
> 
>   (package
>     ;; …
>     (properties '((fixed-vulnerabilities "CVE-123-4567" "CVE-123-4568"))))
> 
> ‘guix lint’ would honor this property, and that would address both cases
> like this and situations where a CVE is known to no longer apply, as is
> the case with unversioned CVEs¹.
> 
> Thoughts?
> 
> Ludo’.
> 
> ¹ http://www.openwall.com/lists/oss-security/2017/03/15/3

I like that idea. It also allows us to mitigate a CVE without needing to
specifically add a patch. I've attached my first attempt at implementing
it.

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

[0001-lint-check-vulnerabilities-also-checks-package-prope.patch (text/plain, attachment)]

[0002-gnu-t1lib-Change-how-patched-CVEs-are-listed.patch (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #22 received at 27943 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 27943 <at> debbugs.gnu.org
Subject: Re: bug#27943: tar complains about too-long names (guix release)
Date: Thu, 30 Nov 2017 18:12:20 -0500

[Message part 1 (text/plain, inline)]

> On Thu, Nov 30, 2017 at 02:55:52PM +0100, Ludovic Courtès wrote:
> > I thought about it, but since it’s an unsual case, what about adding a
> > special property to packages instead?  You’d write:
> > 
> >   (package
> >     ;; …
> >     (properties '((fixed-vulnerabilities "CVE-123-4567" "CVE-123-4568"))))
> > 
> > ‘guix lint’ would honor this property, and that would address both cases
> > like this and situations where a CVE is known to no longer apply, as is
> > the case with unversioned CVEs¹.
> > 
> > Thoughts?

I'd rather the property's name more clearly reflect that it doesn't
actually fix the vulnerability, but just prevents the linter from
complaining about it.

Someone who sees this property used in a package could reasonably assume
that it's required to list all fixed CVEs in a 'fixed-vulnerabilities'
list, and that it is the "single source of truth" for which bugs apply
to a package. But, it would not actually have anything to do with that,
just being a way to silence the linter.

However, I can't think of a good idea for another name...

On Thu, Nov 30, 2017 at 11:49:01PM +0200, Efraim Flashner wrote:
> I like that idea. It also allows us to mitigate a CVE without needing to
> specifically add a patch. I've attached my first attempt at implementing
> it.

I think of `guix lint -c cve` as one of many tools for discovering
important problems in our packages, but I don't think that we must
absolutely silence the linter. It's always going to be imprecise, with
both false negative and positive results.

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 27943 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Leo Famulari <leo <at> famulari.name>
Cc: 27943 <at> debbugs.gnu.org, Efraim Flashner <efraim <at> flashner.co.il>
Subject: Re: bug#27943: tar complains about too-long names (guix release)
Date: Fri, 01 Dec 2017 17:50:01 +0100

Leo Famulari <leo <at> famulari.name> skribis:

>> On Thu, Nov 30, 2017 at 02:55:52PM +0100, Ludovic Courtès wrote:
>> > I thought about it, but since it’s an unsual case, what about adding a
>> > special property to packages instead?  You’d write:
>> > 
>> >   (package
>> >     ;; …
>> >     (properties '((fixed-vulnerabilities "CVE-123-4567" "CVE-123-4568"))))
>> > 
>> > ‘guix lint’ would honor this property, and that would address both cases
>> > like this and situations where a CVE is known to no longer apply, as is
>> > the case with unversioned CVEs¹.
>> > 
>> > Thoughts?
>
> I'd rather the property's name more clearly reflect that it doesn't
> actually fix the vulnerability, but just prevents the linter from
> complaining about it.
>
> Someone who sees this property used in a package could reasonably assume
> that it's required to list all fixed CVEs in a 'fixed-vulnerabilities'
> list, and that it is the "single source of truth" for which bugs apply
> to a package. But, it would not actually have anything to do with that,
> just being a way to silence the linter.

Yes, I see it as a last resort, and thus rarely used.  When used, it
should be accompanied by a comment clearly explaining what we’re doing.

I think people are unlikely to see it as a “single source of truth”
because it’ll be used in a handful of packages only, and because
comments there should make it clear that it’s really just to placate the
linter.

> However, I can't think of a good idea for another name...

Maybe ‘lint-hidden-vulnerabilities’ or ‘hidden-vulnerabilities’, or
‘ignored-vulnerabilities’, or…?  What’s you preference?  :-)

> On Thu, Nov 30, 2017 at 11:49:01PM +0200, Efraim Flashner wrote:
>> I like that idea. It also allows us to mitigate a CVE without needing to
>> specifically add a patch. I've attached my first attempt at implementing
>> it.
>
> I think of `guix lint -c cve` as one of many tools for discovering
> important problems in our packages, but I don't think that we must
> absolutely silence the linter. It's always going to be imprecise, with
> both false negative and positive results.

I agree.  Like patch file names, I view this new property as a way to
silence the reader when we have reliable info to do that.

Would you be OK with a more appropriate name and the understanding that
it’s there to address rare cases like this one?

Thanks for your feedback!

Ludo’.

Message #28 received at 27943 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 27943 <at> debbugs.gnu.org, Efraim Flashner <efraim <at> flashner.co.il>
Subject: Re: bug#27943: tar complains about too-long names (guix release)
Date: Fri, 1 Dec 2017 13:20:59 -0500

[Message part 1 (text/plain, inline)]

On Fri, Dec 01, 2017 at 05:50:01PM +0100, Ludovic Courtès wrote:
> Maybe ‘lint-hidden-vulnerabilities’ or ‘hidden-vulnerabilities’, or
> ‘ignored-vulnerabilities’, or…?  What’s you preference?  :-)

I like 'lint-hidden-vulnerabilities' because it communicates that we are
"hiding" a vulnerability somehow and that it's related to the linter.

Maybe even 'lint-hidden-cve', since it's really about the CVE system and
not so much about vulnerabilities as vulnerabilities.

> Would you be OK with a more appropriate name and the understanding that
> it’s there to address rare cases like this one?

Yes, definitely!

[signature.asc (application/pgp-signature, inline)]

Message #31 received at 27943 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: Danny Milosavljevic <dannym <at> scratchpost.org>, 27943 <at> debbugs.gnu.org
Subject: Re: bug#27943: tar complains about too-long names (guix release)
Date: Sat, 02 Dec 2017 10:55:05 +0100

Efraim Flashner <efraim <at> flashner.co.il> skribis:

> From ad48d84c8659985d706cfe2f8e07314d6017611a Mon Sep 17 00:00:00 2001
> From: Efraim Flashner <efraim <at> flashner.co.il>
> Date: Thu, 30 Nov 2017 23:41:29 +0200
> Subject: [PATCH 1/2] lint: 'check-vulnerabilities' also checks package
>  properties.
>
> * guix/scripts/lint.scm (check-vulnerabilities): Also check for CVEs
> listed as mitigated in the package properties.
> ---
>  guix/scripts/lint.scm | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/guix/scripts/lint.scm b/guix/scripts/lint.scm
> index 1b43b0a63..8112595c8 100644
> --- a/guix/scripts/lint.scm
> +++ b/guix/scripts/lint.scm
> @@ -7,6 +7,7 @@
>  ;;; Copyright © 2016 Hartmut Goebel <h.goebel <at> crazy-compilers.com>
>  ;;; Copyright © 2017 Alex Kost <alezost <at> gmail.com>
>  ;;; Copyright © 2017 Tobias Geerinckx-Rice <me <at> tobias.gr>
> +;;; Copyright © 2017 Efraim Flashner <efraim <at> flashner.co.il>
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -881,10 +882,11 @@ the NIST server non-fatal."
>                                       (or (and=> (package-source package)
>                                                  origin-patches)
>                                           '())))
> +              (known-safe (assq-ref (package-properties package) 'fixed-vulnerabilities))

Can you change that to ‘lint-hidden-cve’ as Leo suggested?

>                (unpatched (remove (lambda (vuln)
>                                     (find (cute string-contains
>                                             <> (vulnerability-id vuln))
> -                                         patches))
> +                                         (append patches known-safe)))
>                                   vulnerabilities)))

To be accurate, we’d rather do:

  (remove (lambda (vuln)
            (let ((id (vulnerability-id vuln)))
              (or (find … patches)
                  (member id known-safe))))
          …)

Also could you add a simple test in tests/lint.scm?  You can start from
one of the existing CVE tests in there and just add a ‘properties’ field
to the test package.

Thank you!

Ludo’.

Message #34 received at 27943 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: Danny Milosavljevic <dannym <at> scratchpost.org>, 27943 <at> debbugs.gnu.org
Subject: Re: bug#27943: tar complains about too-long names (guix release)
Date: Sat, 02 Dec 2017 10:57:19 +0100

Efraim Flashner <efraim <at> flashner.co.il> skribis:

> From 3ae1af75fe7304a05ca8ac0edd8582d581108d05 Mon Sep 17 00:00:00 2001
> From: Efraim Flashner <efraim <at> flashner.co.il>
> Date: Thu, 30 Nov 2017 23:46:55 +0200
> Subject: [PATCH 2/2] gnu: t1lib: Change how patched CVEs are listed.
>
> * gnu/packages/fontutils.scm (t1lib)[source]: Change patch name.
> [properties]: New field, register patched CVEs.
> * gnu/packages/patches/CVE-2011-1552+CVE-2011-1553+CVE-2011-1554.patch:
> Rename to CVE-2011-1552+.patch.
> * gnu/local.mk (dist_patch_DATA): Change patch name.

[...]

>              (patches (search-patches
> -                       "t1lib-CVE-2010-2642.patch"
> +                       "t1lib-CVE-2010-2642.patch" ; 2011-0443, 2011-5244
>                         "t1lib-CVE-2011-0764.patch"
> -                       "t1lib-CVE-2011-1552+CVE-2011-1553+CVE-2011-1554.patch"))))
> +                       "t1lib-CVE-2011-1552+.patch")))) ; 2011-1553, 2011-1554
>     (build-system gnu-build-system)
>     (arguments
>      ;; Making the documentation requires latex, but t1lib is also an input
> @@ -323,6 +323,10 @@ describe character bitmaps.  It contains the bitmap data as well as some
>  metric information.  But t1lib is in itself entirely independent of the
>  X11-system or any other graphical user interface.")
>     (license license:gpl2)
> +   (properties `((fixed-vulnerabilities . ("CVE-2011-0433"
> +                                           "CVE-2011-1553"
> +                                           "CVE-2011-1554"
> +                                           "CVE-2011-5244"))))

Perhaps move ‘properties’ right below ‘patches’ for clarity.  And
s/fixed-vulnerabilities/lint-hidden-cve/.  :-)

OK with these changes, thank you!

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.