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

[20.03] lynis: 2.7.5 -> 3.0.0 #92051

Open
wants to merge 1 commit into
base: release-20.03
from

Conversation

@ryneeverett
Copy link
Contributor

ryneeverett commented Jul 2, 2020

Motivation for this change

Resolve #92031.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.
(cherry picked from commit e674498)
@mweinelt
Copy link
Member

mweinelt commented Jul 6, 2020

A major version bump for a stable release is a tough call, since there can be breaking changes.

Can you try and see if the patches can be applíed onto 2.7.5? It should be these two:

@mweinelt
Copy link
Member

mweinelt commented Jul 25, 2020

@ryneeverett Ping! Can you look into this?

@ryneeverett
Copy link
Contributor Author

ryneeverett commented Jul 28, 2020

@mweinelt Thank you for your vigilance and apologies for the delay.

A major version bump for a stable release is a tough call, since there can be breaking changes.

A fair point, but the first patch was not merged for a year and a half because it's a breaking change. It strikes me as more harmful to merge breaking changes into a prior major version than to merge a major version with breaking changes, especially when upstream was confronted with the same choice and chose to accept the vulnerability. Perhaps we should make the same choice? (We could still apply the second patch, which does not appear to be breaking.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.