all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Efraim Flashner <efraim@flashner.co.il>
Cc: 27943@debbugs.gnu.org
Subject: bug#27943: tar complains about too-long names (guix release)
Date: Thu, 30 Nov 2017 14:55:52 +0100	[thread overview]
Message-ID: <877eu750rb.fsf@gnu.org> (raw)
In-Reply-To: <20171130130510.GT991@macbook41> (Efraim Flashner's message of "Thu, 30 Nov 2017 15:05:10 +0200")

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

  reply	other threads:[~2017-11-30 13:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-04  7:22 bug#27943: tar complains about too-long names (guix release) Danny Milosavljevic
2017-11-28 14:26 ` Ludovic Courtès
2017-11-30 13:05   ` Efraim Flashner
2017-11-30 13:55     ` Ludovic Courtès [this message]
2017-11-30 21:49       ` Efraim Flashner
2017-11-30 23:12         ` Leo Famulari
2017-12-01 16:50           ` Ludovic Courtès
2017-12-01 18:20             ` Leo Famulari
2017-12-02  9:55         ` Ludovic Courtès
2017-12-02  9:57         ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877eu750rb.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=27943@debbugs.gnu.org \
    --cc=efraim@flashner.co.il \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.