Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
michaelkedar opened this issue Aug 13, 2024 · 2 comments · Fixed by #1191
Assignees
Labels
guided remediation Related to guided remediation / osv-scanner fix

Comments

@michaelkedar
Copy link
Member

Currently, osv-scanner fix has two flags:

  • --disallow-major-upgrades (bool), which prevents major updates in all packages
  • --disallow-package-upgrades (list of string), which prevents all updates to the listed packages.

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:

  • Should this be allowed-upgrades or disallowed-upgrades?
  • Is pkg1=type1,pkg2=type2 okay syntax for all ecosystems? (i.e. does any ecosystem allow for '=' in a package name?)
  • How to apply rules to all packages (e.g. all=major could refer to the package named all)
  • What can be allowed.? e.g. major/minor/patch/none
    • Consider what this would mean for non-semver ecosystems
    • Maybe allow for some regex rules to deal with e.g. com.google.guava:guava having versions that end with -jre and -android
@michaelkedar michaelkedar added the guided remediation Related to guided remediation / osv-scanner fix label Aug 13, 2024
@oliverchang
Copy link
Collaborator

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
Copy link
Member Author

michaelkedar commented Aug 14, 2024

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 🤔).

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
guided remediation Related to guided remediation / osv-scanner fix
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants