Description
Hiya lovelies
I've sent to PR corrections around two advisories re: rust vendored openssl-src
- [GHSA-g323-fr93-4j3c] 111.20.0 fixed version for openssl-src 111 #406 - <-- Issue 2
- [GHSA-mmjf-f5jw-w72q] openssl-src 111 stream is not affected #407 - <-- Issue 1
The above advisories are pinging a lot of people in Rust ecosystem as it's the vendored openssl where 111 is typically pulled
Background vendored OpenSSL release streams and how this translates in 🦀 ecosystem
In Rust 🦀 we have two release streams for openssl-src 1.1.1 and 3.0 and there was CVE outlining patched versions:
OpenSSL 1.1.1 users should upgrade to 1.1.1o
OpenSSL 3.0 users should upgrade to 3.0.3
We today updated RUSTSEC-2022-0025,26,27 to reflect the reality for openssl-src :
rustsec/advisory-db#1263
In crates 1.1.1 are under 111. and 3.0 are under 300.
1.1.1o is brought by 111.20.0 which resolves this advisory
This should meant that anyone either below 111.20.0 (in 1.1.1 release stream) or below 300.0.6 (in 3.0 stream) should upgrade to either of release stream relevant patched versions.
Original issue in RustSec
rustsec/advisory-db#1262
I'll be making some noise to perhaps adopt OSV in the future for best translation
Issue 1 - Is RustSec unaffected field taken into account?
Related to second PR and also for the first one before we updated the advisory for the first.. we had marked all / anything below version 300.0 as "unaffected" and is still as such on the second correct advisory
[versions]
patched = [">= 300.0.6"]
unaffected = ["< 300.0"]However dependabot both before was and is still currently atm asking 🦀 to switch from 111.0.0 openssl-src release stream to 300.0.6 which is incorrect advice as 111 release stream was supposed to be unaffected by the unaffected statement
Basically this has made all crates that use vendored openssl (quite few of those) to have this advisory pinged on where the vendored openssl typically pulls from 111 release stream leading to this ping.
I suspect this might be an issue where dependabot might not be reading the unaffected attribute from RustSec ?
Going by above should not have asked 111. users to switch to 300.0.6 - a separate issue related to unaffected field perhaps?
Issue 2 - How do the advisories get synced on crates with multiple release streams?
We also resolved this separate issue with the first advisory in list as it should have flagged vulnerable 111. versions too
But fact is that 111 release stream was affected as well so we upgraded our advisory to below to take 111. into account:
The advisory on the first PR related advisory was today changed to:
[versions]
patched = [">= 111.20.0, < 300.0.0", ">= 300.0.6"]This might also stop dependabot asking 111 release stream users to switch 300 on first PR but in case this doesn't fix it these two issues should probably be addressed.
I am not sure whether this needs to be synced manually over after the advisory has been correlated for the 111 stream ?