Include prereleases if affected range starts with a final release
Problem to solve
When the affected range of versions of a security advisory starts with a final release like 1.0.0
, it's likely that prereleases like 1.0.0-rc1
are also affected.
Proposal
Err on the side of caution and mark a prerelease as affected when the affected range of versions starts with a final release (that matches the prerelease). For instance, mark a project dependency as affected if it depends on 1.0.0-rc1
of a package, and the affected range is >=1.0.0
(and all other criteria match).
range | version | affected? | why not? |
---|---|---|---|
\>=1.0.0 | 1.0.0-alpha | ||
\>=1.0.0 | 0.9.0-alpha | Prerelease doesn't match stable release. | |
\>1.0.0 | 1.0.0-alpha | Lower boundary is not included. | |
\>=1.0.0-beta | 1.0.0-alpha | Lower boundary is a prerelease, and version is out of range. | |
<=1.0.0-alpha | 1.0.0-beta | This is an upper boundary. Also, the boundary is a prerelease. |
Implementation Plan
Step 1 -~~ Add the prerelease logic to the Boundary
class:~~
-
In theBoundary
class:In theinitialize
Method: Add a new flaginclude_prerelease_in_comparison
, with a default value offalse
.Include theComparable
module and implement the spaceship method (<=>
)-
In the<=>
method:Use theinclude_prerelease_in_comparison
flag to decide if prereleases are included in comparisons.Assume that both @semver andother.semver
have the required methods for the new logic (for example:#to_final_release
).Fallback: If the version class does not have the required methods - revert to the old logic.
Step 2 - Add the new methods for the version classes:
- In
SemverDialects::BaseVersion
implement theto_final_release
method (if needed - implement in sub-classes as well).
Step 3 - Use the feature's flag:
- Pass the
include_prerelease_in_comparison
flag all the way to the comparison. - Set
include_prerelease_in_comparison=true
in Continuous Vulnerability Scanning.
Edited by Orin Naaman