bug#40142: CVE checker return false positives

2020-03-20 Thread Brice Waegeneire

Hello,

The CVE checker of “guix lint” returns false positives:
┌
│ LANGUAGE=C guix lint git 2>&1
├───
│ gnu/packages/version-control.scm:149:2: git@2.25.1: probably 
vulnerable to CVE-2020-2136, CVE-2019-1003010, CVE-2018-1000110, 
CVE-2018-1000182
│ 
/gnu/store/8q0nfd6vnc6lnjh13rwl7fyimwlv7fml-guix-module-union/share/guile/site/3.0/gnu/packages/version-control.scm:153:12: 
git@2.25.1: can be upgraded to 2.25.2
│ 
/gnu/store/8q0nfd6vnc6lnjh13rwl7fyimwlv7fml-guix-module-union/share/guile/site/3.0/gnu/packages/version-control.scm:154:11: 
git@2.25.1: source not archived on Software Heritage

└


• [CVE-2020-2136]: “Jenkins Git Plugin 4.2.0 and earlier […]”
• [CVE-2019-1003010]: “[…] Jenkins Git Plugin 3.9.1 and earlier […]”
• [CVE-2018-1000110]: “[…] Jenkins Git Plugin version 3.7.0 and earlier
  […]”
• [CVE-2018-1000182]: “[…] Jenkins Git Plugin 3.9.0 and older […]”

Also note the missing / on the first line and it output on `stderr'
instead of `stdout'.

[CVE-2020-2136] 

[CVE-2019-1003010] 

[CVE-2018-1000110] 

[CVE-2018-1000182] 

Brice.





bug#40142: CVE checker return false positives

2020-03-21 Thread Ludovic Courtès
Hi,

Brice Waegeneire  skribis:

> The CVE checker of “guix lint” returns false positives:
> ┌
> │ LANGUAGE=C guix lint git 2>&1
> ├───
> │ gnu/packages/version-control.scm:149:2: git@2.25.1: probably
> vulnerable to CVE-2020-2136, CVE-2019-1003010, CVE-2018-1000110,
> CVE-2018-1000182

[...]

> • [CVE-2020-2136]: “Jenkins Git Plugin 4.2.0 and earlier […]”
> • [CVE-2019-1003010]: “[…] Jenkins Git Plugin 3.9.1 and earlier […]”
> • [CVE-2018-1000110]: “[…] Jenkins Git Plugin version 3.7.0 and earlier
>   […]”
> • [CVE-2018-1000182]: “[…] Jenkins Git Plugin 3.9.0 and older […]”

(guix cve) reports it as applying to “git”:

--8<---cut here---start->8---
scheme@(guix cve)> (define items
 (call-with-decompressed-port 'gzip (http-fetch 
(yearly-feed-uri 2020))
   json->cve-items))
scheme@(guix cve)> (find (lambda (item)
   (string=? (cve-id (cve-item-cve item)) 
"CVE-2020-2136"))
 items)
$130 = #< cve: #< id: "CVE-2020-2136" data-type: CVE 
data-format: MITRE references: (#< url: 
"http://www.openwall.com/lists/oss-security/2020/03/09/1"; tags: ("Third Party 
Advisory")> #< url: 
"https://jenkins.io/security/advisory/2020-03-09/#SECURITY-1723"; tags: ("Vendor 
Advisory")>)> configurations: (("git" (<= "4.2.0"))) published-date: # last-modified-date: #>
--8<---cut here---end--->8---

I think the problem stems from the fact that the CVE configuration
specify “jenkins:git” (where “jenkins” is the “vendor” and “git” is the
“product”), but we just strip the vendor part:

--8<---cut here---start->8---
$ wget -O - -q https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-2020.json.gz| 
gunzip | jq

[…]

  "configurations": {
"CVE_data_version": "4.0",
"nodes": [
  {
"operator": "OR",
"cpe_match": [
  {
"vulnerable": true,
"cpe23Uri": "cpe:2.3:a:jenkins:git:*:*:*:*:*:jenkins:*:*",
"versionEndIncluding": "4.2.0"
  }
]
  }
]
--8<---cut here---end--->8---

It’s usually the case that the vendor part has little relevance for free
software packages, but in this case it does make a difference.

Probably the fix would be to preserve the vendor part in the API and to
somehow use it meaningfully.

Ideas & patches welcome!

> Also note the missing / on the first line and it output on `stderr'
> instead of `stdout'.

What do you mean?

Thanks,
Ludo’.





bug#40142: CVE checker return false positives

2020-03-21 Thread Brice Waegeneire

Hello,

On 2020-03-21 16:25, Ludovic Courtès wrote:

Probably the fix would be to preserve the vendor part in the API and to
somehow use it meaningfully.

Ideas & patches welcome!


I'll see what I can write a patch to fix it then.


Also note the missing / on the first line and it output on `stderr'
instead of `stdout'.


What do you mean?


I misunderstood the meaning of “gnu/packages/version-control.scm:149:2:”
and thought there was a missing / before “gnu/”; this is irrelevant. 
About
the output stream of “guix lint” I think it should output to `stdout', 
not

`stderr' as it's currently the case.

Brice.