* bug#36571: icecat's CPE data is wrong
@ 2019-07-10 7:05 Efraim Flashner
2019-07-11 20:34 ` Ludovic Courtès
0 siblings, 1 reply; 3+ messages in thread
From: Efraim Flashner @ 2019-07-10 7:05 UTC (permalink / raw)
To: 36571
[-- Attachment #1.1: Type: text/plain, Size: 2338 bytes --]
currently we have:
(cpe-name . "firefox_esr")
(cpe-version . ,(first (string-split version #\-)
and it should be:
(cpe-name . "firefox")
(cpe-version . ,(first (string-split version #\.)
however, this returns results for firefox@60, which I'm pretty sure
doesn't take into account that we're not running 60.0.0 but 60.8.0. With
the change 'guix lint -c cve iceat' returns:
icecat@60.8.0-guix1: probably vulnerable to CVE-2019-9788, CVE-2019-9789, CVE-2019-9791, CVE-2019-9792, CVE-2019-9793, CVE-2019-9794, CVE-2019-9795, CVE-2019-9796, CVE-2019-9797, CVE-2019-9798, CVE-2019-9799, CVE-2019-9801, CVE-2019-9802, CVE-2019-9803, CVE-2019-9804, CVE-2019-9805, CVE-2019-9806, CVE-2019-9807, CVE-2019-9808, CVE-2019-9809, CVE-2019-9810, CVE-2019-9813, CVE-2018-12358, CVE-2018-12359, CVE-2018-12360, CVE-2018-12361, CVE-2018-12362, CVE-2018-12363, CVE-2018-12364, CVE-2018-12365, CVE-2018-12366, CVE-2018-12367, CVE-2018-12368, CVE-2018-12369, CVE-2018-12370, CVE-2018-12375, CVE-2018-12376, CVE-2018-12377, CVE-2018-12378, CVE-2018-12379, CVE-2018-12381, CVE-2018-12383, CVE-2018-12385, CVE-2018-12386, CVE-2018-12387, CVE-2018-12388, CVE-2018-12390, CVE-2018-12391, CVE-2018-12392, CVE-2018-12395, CVE-2018-12396, CVE-2018-12397, CVE-2018-12398, CVE-2018-12399, CVE-2018-12400, CVE-2018-12401, CVE-2018-12402, CVE-2018-12403, CVE-2018-12405, CVE-2018-12406, CVE-2018-12407, CVE-2018-18492, CVE-2018-18493, CVE-2018-18494, CVE-2018-18495, CVE-2018-18496, CVE-2018-18497, CVE-2018-18498, CVE-2018-18499, CVE-2018-18500, CVE-2018-18501, CVE-2018-18502, CVE-2018-18503, CVE-2018-18504, CVE-2018-18505, CVE-2018-18506, CVE-2018-18510, CVE-2018-5150, CVE-2018-5151, CVE-2018-5152, CVE-2018-5153, CVE-2018-5154, CVE-2018-5155, CVE-2018-5156, CVE-2018-5157, CVE-2018-5158, CVE-2018-5159, CVE-2018-5160, CVE-2018-5163, CVE-2018-5164, CVE-2018-5166, CVE-2018-5167, CVE-2018-5168, CVE-2018-5169, CVE-2018-5172, CVE-2018-5173, CVE-2018-5174, CVE-2018-5175, CVE-2018-5176, CVE-2018-5177, CVE-2018-5179, CVE-2018-5180, CVE-2018-5181, CVE-2018-5182, CVE-2018-5186, CVE-2018-5187, CVE-2018-5188
which just seems like too much.
--
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-gnu-icecat-Update-cpe-name.patch --]
[-- Type: text/plain, Size: 1090 bytes --]
From 2eb51419218e77c4ccb517c642e8fc7e40724973 Mon Sep 17 00:00:00 2001
From: Efraim Flashner <efraim@flashner.co.il>
Date: Wed, 10 Jul 2019 09:59:03 +0300
Subject: [PATCH] gnu: icecat: Update cpe-name.
* gnu/packages/gnuzilla.scm (icecat)[properties]: Update cpe-name,
cpe-version.
---
gnu/packages/gnuzilla.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm
index ff382b2388..c3931c2594 100644
--- a/gnu/packages/gnuzilla.scm
+++ b/gnu/packages/gnuzilla.scm
@@ -939,8 +939,8 @@ features built-in privacy-protecting features.")
(license license:mpl2.0) ;and others, see toolkit/content/license.html
(properties
`((ftp-directory . "/gnu/gnuzilla")
- (cpe-name . "firefox_esr")
- (cpe-version . ,(first (string-split version #\-)))))))
+ (cpe-name . "firefox")
+ (cpe-version . ,(first (string-split version #\.)))))))
(define-public conkeror
;; The Conkeror web browser relied on XULRunner, which IceCat > 50 no longer
--
2.22.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [flat|nested] 3+ messages in thread
* bug#36571: icecat's CPE data is wrong
2019-07-10 7:05 bug#36571: icecat's CPE data is wrong Efraim Flashner
@ 2019-07-11 20:34 ` Ludovic Courtès
2019-07-14 12:33 ` Efraim Flashner
0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2019-07-11 20:34 UTC (permalink / raw)
To: Efraim Flashner; +Cc: 36571
Hello,
Efraim Flashner <efraim@flashner.co.il> skribis:
> currently we have:
> (cpe-name . "firefox_esr")
> (cpe-version . ,(first (string-split version #\-)
>
> and it should be:
> (cpe-name . "firefox")
> (cpe-version . ,(first (string-split version #\.)
>
> however, this returns results for firefox@60, which I'm pretty sure
> doesn't take into account that we're not running 60.0.0 but 60.8.0. With
> the change 'guix lint -c cve iceat' returns:
> icecat@60.8.0-guix1: probably vulnerable to CVE-2019-9788, CVE-2019-9789, […]
Indeed, something seems to be wrong.
--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(guix cve)
scheme@(guile-user)> (vulnerabilities->lookup-proc (current-vulnerabilities))
fetching CVE database for 2019...
fetching CVE database for 2018...
scheme@(guile-user)> $2
$3 = #<procedure 1f64baa0 at guix/cve.scm:268:2 (package #:optional version)>
scheme@(guile-user)> (length ($2 "firefox" "60"))
$4 = 107
scheme@(guile-user)> (length ($2 "firefox" "60.8"))
$5 = 0
scheme@(guile-user)> (length ($2 "firefox" "60.5"))
$6 = 0
--8<---------------cut here---------------end--------------->8---
Actually, the procedure returned by ‘vulnerabilities->lookup-proc’
performs exact matches on version string. So “60” is _not_ equivalent
to “60 or any 60.x version”.
Here are the versions we see for one of these CVEs:
--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(srfi srfi-1)
scheme@(guile-user)> (find (lambda (vuln)
(string=? (vulnerability-id vuln)
"CVE-2019-9788"))
(current-vulnerabilities))
$9 = #<<vulnerability> id: "CVE-2019-9788" packages: (("thunderbird" …) ("firefox_esr" "60.5.0" "60.4.0" "60.3.0" "60.2.2" "60.2.0" "60.1.0" "60.0" "53.0.0" "52.9.0" …) ("firefox" "9.0.1" "9.0" "8.0.1" "8.0" "7.0.1" "7.0" "65.0" "64.0.2" "64.0" "63.0.3" "63.0.1" "63.0" "62.0.3" "62.0.2" "62.0" "61.0.2" "61.0.1" "61.0" "60.6.1" "60.5.0" "60.4.0" "60.3.0" "60.2.2" "60.2.1" "60.2.0" "60.1.0" …)>
--8<---------------cut here---------------end--------------->8---
So IceCat probably corresponds to “firefox_esr”, but we got the CPE
version string wrong: we should just strip the “-gnu*” suffix, nothing
more.
WDYT?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#36571: icecat's CPE data is wrong
2019-07-11 20:34 ` Ludovic Courtès
@ 2019-07-14 12:33 ` Efraim Flashner
0 siblings, 0 replies; 3+ messages in thread
From: Efraim Flashner @ 2019-07-14 12:33 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 36571-done
[-- Attachment #1: Type: text/plain, Size: 3010 bytes --]
On Thu, Jul 11, 2019 at 10:34:00PM +0200, Ludovic Courtès wrote:
> Hello,
>
> Efraim Flashner <efraim@flashner.co.il> skribis:
>
> > currently we have:
> > (cpe-name . "firefox_esr")
> > (cpe-version . ,(first (string-split version #\-)
> >
> > and it should be:
> > (cpe-name . "firefox")
> > (cpe-version . ,(first (string-split version #\.)
> >
> > however, this returns results for firefox@60, which I'm pretty sure
> > doesn't take into account that we're not running 60.0.0 but 60.8.0. With
> > the change 'guix lint -c cve iceat' returns:
> > icecat@60.8.0-guix1: probably vulnerable to CVE-2019-9788, CVE-2019-9789, […]
>
> Indeed, something seems to be wrong.
>
> --8<---------------cut here---------------start------------->8---
> scheme@(guile-user)> ,use(guix cve)
> scheme@(guile-user)> (vulnerabilities->lookup-proc (current-vulnerabilities))
> fetching CVE database for 2019...
> fetching CVE database for 2018...
> scheme@(guile-user)> $2
> $3 = #<procedure 1f64baa0 at guix/cve.scm:268:2 (package #:optional version)>
> scheme@(guile-user)> (length ($2 "firefox" "60"))
> $4 = 107
> scheme@(guile-user)> (length ($2 "firefox" "60.8"))
> $5 = 0
> scheme@(guile-user)> (length ($2 "firefox" "60.5"))
> $6 = 0
> --8<---------------cut here---------------end--------------->8---
>
> Actually, the procedure returned by ‘vulnerabilities->lookup-proc’
> performs exact matches on version string. So “60” is _not_ equivalent
> to “60 or any 60.x version”.
>
> Here are the versions we see for one of these CVEs:
>
> --8<---------------cut here---------------start------------->8---
> scheme@(guile-user)> ,use(srfi srfi-1)
> scheme@(guile-user)> (find (lambda (vuln)
> (string=? (vulnerability-id vuln)
> "CVE-2019-9788"))
> (current-vulnerabilities))
> $9 = #<<vulnerability> id: "CVE-2019-9788" packages: (("thunderbird" …) ("firefox_esr" "60.5.0" "60.4.0" "60.3.0" "60.2.2" "60.2.0" "60.1.0" "60.0" "53.0.0" "52.9.0" …) ("firefox" "9.0.1" "9.0" "8.0.1" "8.0" "7.0.1" "7.0" "65.0" "64.0.2" "64.0" "63.0.3" "63.0.1" "63.0" "62.0.3" "62.0.2" "62.0" "61.0.2" "61.0.1" "61.0" "60.6.1" "60.5.0" "60.4.0" "60.3.0" "60.2.2" "60.2.1" "60.2.0" "60.1.0" …)>
> --8<---------------cut here---------------end--------------->8---
>
> So IceCat probably corresponds to “firefox_esr”, but we got the CPE
> version string wrong: we should just strip the “-gnu*” suffix, nothing
> more.
>
> WDYT?
>
I was about to go and make the change but it seems that this is already
what we have. 'firefox_esr' and '(first (string-split version #\-))'. So
it looks like the vulnerability list just hasn't caught up with the
version we have now.
Closing as 'everything works as expected'
--
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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-07-14 12:34 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-10 7:05 bug#36571: icecat's CPE data is wrong Efraim Flashner
2019-07-11 20:34 ` Ludovic Courtès
2019-07-14 12:33 ` Efraim Flashner
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).