security/vuxml: Add CVE-2020-1730 affecting security/libssh

[salvadore]

I have two problems with this review.

1 - I do not know the real discovery date: I put the date when I learned about the CVE and when the update to version 0.9.4 that fixes the vulnerabilty has been released, but it is unlikely that it is the real discovery date. I tried not putting such a date (no discovery field or "before 2020-04-10"), but nothing, make validate enforces a date in %Y-%m-%d format.

2 - According to https://www.freebsd.org/doc/en/books/porters-handbook/security-notify.html what I wrote says that 0.9.4 is affected by the vulnerability, although it is the security fix (same for 0.8.9). I think that page of the porter handbook is wrong, in particular in the part that says "The above example specifies that affected are versions from 1.6 to 1.9 inclusive": I think it should be instead "The above example specifies that affected are versions from 1.6 (inlcuded) to 1.9 (excluded)".
I think so because of the <ge> and <lt> tags and because of the output of pkg audit -f vuln.xml libssh which says ">= 0.9.0 : < 0.9.4" (and ">= 0.8.0 : < 0.8.9") with the proposed patch.

[gerald]

In D24377#536225, @salvadore wrote:

1 - I do not know the real discovery date: I put the date when I learned about the CVE and when the update to version 0.9.4 that fixes the vulnerabilty has been released, but it is unlikely that it is the real discovery date. I tried not putting such a date (no discovery field or "before 2020-04-10"), but nothing, make validate enforces a date in %Y-%m-%d format.

For the real discovery date, go upstream:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1730

Interestingly in this specific case upstream still has "This candidate has been reserved", but it has a specific date for the discovery and should be updated soon, hopefully.

You also may find http://lists.suse.com/pipermail/sle-security-updates/2020-April/006694.html useful, or the overview page at
https://www.suse.com/security/cve/ .

[gerald]

Regarding your interpretation, indeed it appears the Porters' Handbook needs fixing. Can you please file a PR or Phabricator item and use that to check in with [e-mail] ?

(Sadly none of the doc ssues I have reported so far in the course of our mentorship has been resolved; that one we should definitely see to expedite.)

[salvadore]

In D24377#536251, @gerald wrote:

Interestingly in this specific case upstream still has "This candidate has been reserved", but it has a specific date for the discovery and should be updated soon, hopefully.

Which specific date? It has a reservation date, but I can't find any discovery date. I did search upstream and on the web for a discovery date, but could not find any.
If I commit it with the date I have put in there, shall I add a comment in the file explaining that it is not (probably) the real discovery date?

In D24377#536252, @gerald wrote:

Regarding your interpretation, indeed it appears the Porters' Handbook needs fixing. Can you please file a PR or Phabricator item and use that to check in with [e-mail] ?

(Sadly none of the doc ssues I have reported so far in the course of our mentorship has been resolved; that one we should definitely see to expedite.)

Phabricator review coming soon.

[salvadore]

I kept searching upstream and found the git commit that fixed the vulnerability:
https://git.libssh.org/projects/libssh.git/commit/?id=b36272eac1b36982598c10de7af0a501582de07a

I asked the committer if he could tell me the discovery date, as I cannot access the bug report referenced in the commit log: he has not answered yet.
If he does not answer, shall I put 2020-02-11 as discovery date? This is the date in the author field of the git commit (not sure what it represents however).
According to https://bugzilla.redhat.com/show_bug.cgi?id=1801998 the vulnerability was known in 2020-02-12.

By the way, is specifing a precise date in the discovery field of vuln.xml so important? Isn't it fine to put a reasonable date in there even if it is not sure it is the real one? This detail has caused the announcement of the vulnerability in the ports tree to be postponed for several days...

[gerald]

In D24377#538854, @salvadore wrote:

I kept searching upstream and found the git commit that fixed the vulnerability:
https://git.libssh.org/projects/libssh.git/commit/?id=b36272eac1b36982598c10de7af0a501582de07a

I asked the committer if he could tell me the discovery date, as I cannot access the bug report referenced in the commit log: he has not answered yet.
If he does not answer, shall I put 2020-02-11 as discovery date? This is the date in the author field of the git commit (not sure what it represents however).
According to https://bugzilla.redhat.com/show_bug.cgi?id=1801998 the vulnerability was known in 2020-02-12.

I would not overthink this / spend too much time on this: when there is no clear, distinct discovery date, simply use the earliest date you can find in the CVE database - which may then be the reservation date.

By the way, is specifing a precise date in the discovery field of vuln.xml so important? Isn't it fine to put a reasonable date in there even if it is not sure it is the real one?

Agreed.

This detail has caused the announcement of the vulnerability in the ports tree to be postponed for several days...

Getting fixes and announcements to our users is more important than ultimate precision

[salvadore]

Committed with the reservation date as suggested. We can always fix it later if we find a better discovery date.

@gerald: May I remind you that I also have the update to libssh ready? https://reviews.freebsd.org/D24374
Thanks!

[salvadore]

Manually close the revision: apparently something went wrong with automatic closure (maybe an extra space after the link to the differential revision?)

Here is the link to the commit:
https://svnweb.freebsd.org/ports?view=revision&revision=532108