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

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

[Danny Milosavljevic]

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'

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

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic <dannym@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’.

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

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 3724 bytes --]

On Tue, Nov 28, 2017 at 03:26:03PM +0100, Ludovic Courtès wrote:
> Hi Danny,
> 
> Danny Milosavljevic <dannym@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@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ludovic Courtès]

Hi Efraim,

Efraim Flashner <efraim@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

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

[Efraim Flashner]

[-- Attachment #1.1: Type: text/plain, Size: 2311 bytes --]

On Thu, Nov 30, 2017 at 02:55:52PM +0100, Ludovic Courtès wrote:
> Hi Efraim,
> 
> Efraim Flashner <efraim@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@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

[-- Attachment #1.2: 0001-lint-check-vulnerabilities-also-checks-package-prope.patch --]
[-- Type: text/plain, Size: 1710 bytes --]

From ad48d84c8659985d706cfe2f8e07314d6017611a Mon Sep 17 00:00:00 2001
From: Efraim Flashner <efraim@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@crazy-compilers.com>
 ;;; Copyright © 2017 Alex Kost <alezost@gmail.com>
 ;;; Copyright © 2017 Tobias Geerinckx-Rice <me@tobias.gr>
+;;; Copyright © 2017 Efraim Flashner <efraim@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))
               (unpatched (remove (lambda (vuln)
                                    (find (cute string-contains
                                            <> (vulnerability-id vuln))
-                                         patches))
+                                         (append patches known-safe)))
                                  vulnerabilities)))
          (unless (null? unpatched)
            (emit-warning package
-- 
2.15.0


[-- Attachment #1.3: 0002-gnu-t1lib-Change-how-patched-CVEs-are-listed.patch --]
[-- Type: text/plain, Size: 3345 bytes --]

From 3ae1af75fe7304a05ca8ac0edd8582d581108d05 Mon Sep 17 00:00:00 2001
From: Efraim Flashner <efraim@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.
---
 gnu/local.mk                                                      | 2 +-
 gnu/packages/fontutils.scm                                        | 8 ++++++--
 ...E-2011-1553+CVE-2011-1554.patch => t1lib-CVE-2011-1552+.patch} | 0
 3 files changed, 7 insertions(+), 3 deletions(-)
 rename gnu/packages/patches/{t1lib-CVE-2011-1552+CVE-2011-1553+CVE-2011-1554.patch => t1lib-CVE-2011-1552+.patch} (100%)

diff --git a/gnu/local.mk b/gnu/local.mk
index 05a86ac17..398839682 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1079,7 +1079,7 @@ dist_patch_DATA =						\
   %D%/packages/patches/synfigstudio-fix-ui-with-gtk3.patch 	\
   %D%/packages/patches/t1lib-CVE-2010-2642.patch		\
   %D%/packages/patches/t1lib-CVE-2011-0764.patch		\
-  %D%/packages/patches/t1lib-CVE-2011-1552+CVE-2011-1553+CVE-2011-1554.patch		\
+  %D%/packages/patches/t1lib-CVE-2011-1552+.patch		\
   %D%/packages/patches/tar-CVE-2016-6321.patch			\
   %D%/packages/patches/tar-skip-unreliable-tests.patch		\
   %D%/packages/patches/tcl-mkindex-deterministic.patch		\
diff --git a/gnu/packages/fontutils.scm b/gnu/packages/fontutils.scm
index d2306a942..2edbe31d1 100644
--- a/gnu/packages/fontutils.scm
+++ b/gnu/packages/fontutils.scm
@@ -302,9 +302,9 @@ high quality, anti-aliased and subpixel rendered text on a display.")
             (sha256 (base32
                      "0nbvjpnmcznib1nlgg8xckrmsw3haa154byds2h90y2g0nsjh4w2"))
             (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"))))
    (home-page "http://www.t1lib.org/")))
 
 (define-public teckit
diff --git a/gnu/packages/patches/t1lib-CVE-2011-1552+CVE-2011-1553+CVE-2011-1554.patch b/gnu/packages/patches/t1lib-CVE-2011-1552+.patch
similarity index 100%
rename from gnu/packages/patches/t1lib-CVE-2011-1552+CVE-2011-1553+CVE-2011-1554.patch
rename to gnu/packages/patches/t1lib-CVE-2011-1552+.patch
-- 
2.15.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ludovic Courtès]

Leo Famulari <leo@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’.

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

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

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!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ludovic Courtès]

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

> From ad48d84c8659985d706cfe2f8e07314d6017611a Mon Sep 17 00:00:00 2001
> From: Efraim Flashner <efraim@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@crazy-compilers.com>
>  ;;; Copyright © 2017 Alex Kost <alezost@gmail.com>
>  ;;; Copyright © 2017 Tobias Geerinckx-Rice <me@tobias.gr>
> +;;; Copyright © 2017 Efraim Flashner <efraim@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’.

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

[Ludovic Courtès]

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

> From 3ae1af75fe7304a05ca8ac0edd8582d581108d05 Mon Sep 17 00:00:00 2001
> From: Efraim Flashner <efraim@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’.