affected ranges in PYSEC-2019-169

[afdesk]

Hi Team!
thanks for your database! it's really useful content.

a few day ago we ran into a strange affected range in PYSEC-2019-169:

advisory-database/vulns/pyspark/PYSEC-2019-169.yaml

Lines 12 to 19 in c51e363

	events:
	- introduced: 2.1.0
	- introduced: 2.3.0
	- fixed: 2.3.2
	- introduced: 1.0.2
	- introduced: 2.0.0
	- introduced: 2.2.0
	- fixed: 2.2.3

Looks like the security advisory doesn't comply with the schema of Open Source Vulnerability.
https://ossf.github.io/osv-schema/

the next records are redundant:

 - introduced: 2.1.0 
 ...
 - introduced: 2.0.0 
 - introduced: 2.2.0 
 ...

GHSA contains a more shorter entry for CVE-2018-11760

Affected versions
">= 2.3.0, < 2.3.2"
"< 2.2.2"

That weird advisory breaks the Trivy's database. We're asking PyPA to check if it is a bug or not.

thanks!

[oliverchang]

Hi there! This was scraped from the NVD CVE database, which resulted in these redundant entries.

While these are redundant entries, they don't necessarily conflict with OSV schema. These "events" represent points on the version timeline for describing which ranges are vulnerable. There are no ordering requirements for the actual encoding itself.

This encoding means:
1.0.2 (vulnerable) ---> 2.0.0 (vulnerable) --> 2.1.0 (vulnerable) --> 2.2.0 (vulnerable) --> 2.2.3 (fixed) --> 2.3.0 (vulnerable) --> 2.3.2 (fixed)

The first few vulnerable events are redundant -- this could be expressed more concisely as:

introduced: 1.0.2
fixed: 2.2.3
introduced: 2.3.0
fixed: 2.3.2

Note that this is slightly different from GitHub's encoding: they claim 2.2.2 is fixed but the CVE description claims it's not.

[afdesk]

introduced: 1.0.2
fixed: 2.2.3
introduced: 2.3.0
fixed: 2.3.2

@oliverchang this records look good. thanks!

yes, it seems GHSA contains incorrect fixed version...

[oliverchang]

introduced: 1.0.2
fixed: 2.2.3
introduced: 2.3.0
fixed: 2.3.2

@oliverchang this records look good. thanks!

yes, it seems GHSA contains incorrect fixed version...

👍 I'd recommend in either case to be able to handle the original encoding, since it's still consistent with the OSV schema.

[afdesk]

ok, we'll take a look at this moment. thanks again.

[westonsteimel]

@oliverchang did you want to submit an update to the GitHub advisory? Otherwise I can on Monday. I think this Jira link should be sufficient to show that 2.2.3 is the fix version: https://issues.apache.org/jira/browse/SPARK-26802

[westonsteimel]

Nevermind, it was quick enough I just went ahead and submitted it now: github/advisory-database#362