google / osv-scanner

Vulnerability scanner written in Go which uses the data provided by https://osv.dev
https://google.github.io/osv-scanner/
Apache License 2.0
6.26k stars 362 forks source link

Allow control over allowed individual package upgrade versions in non-interactive guided remediation #1177

Closed michaelkedar closed 2 months ago

michaelkedar commented 3 months ago

Currently, osv-scanner fix has two flags:

We should replace these flags with per-package allowed update levels e.g. --allowed-upgrades=foo=none,bar=major,baz=minor.

Syntax might be a bit tricky and needs some thought:

oliverchang commented 3 months ago

How about something like --upgrade-config ? and rather than having this be comma-separated, something like:

# Don't upgrade `PKG`
--upgrade-config=PKG:none

# Allow major upgrades
--upgrade-config=PKG:major

# Allow major upgrades, along with minor, patch and less significant upgrades
--upgrade-config=PKG:major

# Allow minor upgrades, along with patch and less significant
--upgrade-config=PKG:minor

# Allow patch only upgrades (and less significant)
--upgrade-config=PKG:patch

# Allow major upgrades to all packages (default)
--upgrade-config=major

# Allow minor (and less significant) only upgrades to all packages
--upgrade-config=minor

Now what happens if an ecosystem allows ":" in package names? This seems OK because we can just split on the last ":". If someone has a package name called "foo:patch", and it's incorrect to pass that directly as --upgrade-config=foo:patch.

And we can specify this flag multiple times for different packages:

--upgrade-config=PKG1:none --upgrade-config:PKG2:minor
michaelkedar commented 3 months ago

and rather than having this be comma-separated, something like

urfave/cli's StringSliceFlag seems to by default accept both comma-separated strings and repeating the flag multiple times. e.g. --flag a,b --flag=c,d gives ["a", "b", "c", "d"], so we could support either way (unless commas are valid in some ecosystem's package names :thinking:).

I'm happy with this suggestion, with --upgrade-config being what is allowed.

Just to clarify how we'd treat the unspecified packages:

# allow all upgrades for all packages (default behaviour if unspecified)
--upgrade-config=major

# allow up to minor version upgrades for PKG, and any upgrades for all other packages
--upgrade-config=PKG:minor

# allow up to minor version upgrades for PKG, and no upgrades to any other packages
--upgrade-config=none --upgrade-config=PKG:minor

And mapping the existing flags to the new one:

--disallow-major-upgrades => --upgrade-config=minor
--disallow-package-upgrades=PKG1,PKG2 => --upgrade-config=PKG1:none,PKG2:none