-
-
Notifications
You must be signed in to change notification settings - Fork 14.6k
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
nixpkgs: allow packages to be marked insecure (reverted) #22890
Conversation
@grahamc, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @codyopel and @svanderburg to be potential reviewers. |
This is my first time hacking around this close to the core. Please review carefully and leave liberal amounts of feedback. This does work. I'm working on documentation, but wanted to get something up for review sooner than later. |
pkgs/stdenv/generic/default.nix
Outdated
@@ -75,6 +75,12 @@ let | |||
isUnfree (lib.lists.toList attrs.meta.license) && | |||
!allowUnfreePredicate attrs; | |||
|
|||
allowInsecurePredicate = x: builtins.elem x.name (config.permittedInsecurePackages or []); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that for allowUnfreePredicate
the whole point is to allow user to define a more complicated policy (allow all flashplayer
but nothing else). It is not described in the error message to avoid confusing users, though.
So I would prefer the same approach here:
allowInsecurePredicate = x: ((config.allowInsecurePredicate or y: false) x) ||
(builtins.elem x.name (config.permittedInsecurePackages or []));
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 fixed
Will I get this prompt if I apply fix patch manually (via |
pkgs/stdenv/generic/default.nix
Outdated
|
||
b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add | ||
‘${attrs.name or "«name-missing»"}’ to `permittedInsecurePackages` in | ||
~/.nixpkgs/config.nix, like so: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since 9d6a55a you can use ~/.config/nixpkgs/config.nix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 fixed
It appears that this code requires you add the exception and then override:
but I can then install foobar2 without a warning. |
If a package's meta has `knownVulnerabilities`, like so: stdenv.mkDerivation { name = "foobar-1.2.3"; ... meta.knownVulnerabilities = [ "CVE-0000-00000: remote code execution" "CVE-0000-00001: local privilege escalation" ]; } and a user attempts to install the package, they will be greeted with a warning indicating that maybe they don't want to install it: error: Package ‘foobar-1.2.3’ in ‘...default.nix:20’ is marked as insecure, refusing to evaluate. Known issues: - CVE-0000-00000: remote code execution - CVE-0000-00001: local privilege escalation You can install it anyway by whitelisting this package, using the following methods: a) for `nixos-rebuild` you can add ‘foobar-1.2.3’ to `nixpkgs.config.permittedInsecurePackages` in the configuration.nix, like so: { nixpkgs.config.permittedInsecurePackages = [ "foobar-1.2.3" ]; } b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add ‘foobar-1.2.3’ to `permittedInsecurePackages` in ~/.config/nixpkgs/config.nix, like so: { permittedInsecurePackages = [ "foobar-1.2.3" ]; } Adding either of these configurations will permit this specific version to be installed. A third option also exists: NIXPKGS_ALLOW_INSECURE=1 nix-build ... though I specifically avoided having a global file-based toggle to disable this check. This way, users don't disable it once in order to get a single package, and then don't realize future packages are insecure.
433aeec
to
38771ba
Compare
Should we wait for a 👍 from @edolstra prior to merging? |
Patches currently available don't seem to apply.
Ping again: should we wait for @edolstra? I just used it for the first time, marking libplist insecure. |
you might want to change the base to staging |
@FRidh this PR doesn't cause anything to rebuild, is there another reason to do that? |
oh, I thought it would. Nevermind then. |
👍 thanks! |
Shouldn't we document this feature? (changelog/manual) |
Yes we should, I evidently forgot that part. I'm reverting this merge until docs are here. |
Thank you for the bump on that, @jgeerds. |
You didn't have to revert, writing changelog/docs before the branch-off on 27.02. would've been enough IMHO. |
There will be nontrivial conflicts with #22277, but never mind that. I need to find time to fix the performance regression in there first. Alternatively, I could split up a move-code-out part and merge that – that's what conflicts with this and it has no performance impact. |
I'll have docs ready by morning. My reasoning for reverting was so that I was highly incentivized to write the docs, and didn't just let them go. |
If a package's meta has
knownVulnerabilities
, like so:and a user attempts to install the package, they will be greeted with
a warning indicating that maybe they don't want to install it:
Adding either of these configurations will permit this specific
version to be installed. A third option also exists:
though I specifically avoided having a global file-based toggle to
disable this check. This way, users don't disable it once in order to
get a single package, and then don't realize future packages are
insecure.
Motivation for this change
Things done
(nix.useSandbox on NixOS,
or option
build-use-sandbox
innix.conf
on non-NixOS)
cc @globin @domenkozar @fpletz @edolstra