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

[Ludovic Courtès]

Hi Efraim,

Efraim Flashner <address@hidden> 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