Hi Efraim, Efraim Flashner <efr...@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