How to use "permittedInsecurePackages"?

[sevillaarvin]

I have a very similar problem with https://github.com/cachix/devenv/issues/623. I see that a new key was added to address this https://github.com/cachix/devenv/issues/619.

However, when I added it, the error still shows.

devenv.nix

```nix { pkgs, ... }: { # https://devenv.sh/basics/ env.GREET = "devenv"; # https://devenv.sh/packages/ packages = [ ]; # https://devenv.sh/scripts/ scripts.hello.exec = "echo hello from $GREET"; enterShell = '' ''; # https://devenv.sh/languages/ languages.ruby = { enable = true; version = "2.6.5"; }; # languages.ruby.bundler = { # enable = true; # package = ?; # }; # https://devenv.sh/pre-commit-hooks/ # pre-commit.hooks.shellcheck.enable = true; # https://devenv.sh/processes/ # processes.ping.exec = "ping example.com"; # See full reference at https://devenv.sh/reference/options/ } ```

devenv.yaml

```yaml inputs: nixpkgs: url: github:NixOS/nixpkgs/nixpkgs-unstable nixpkgs-ruby: url: github:bobvanderlinden/nixpkgs-ruby inputs: nixpkgs: follows: nixpkgs permittedInsecurePackages: - "openssl-1.1.1v" - "openssl-1.1.1t" - "openssl_1_1" ```

cli error

``` error: Package ‘openssl-1.1.1v’ in «github:NixOS/nixpkgs/9b2aa98db6b10503666a50f4eb93b2fc0d57bde5»/pkgs/development/libraries/openssl/default.nix:222 is marked as insecure, refusing to evaluate. Known issues: - OpenSSL 1.1 is reaching its end of life on 2023/09/11 and cannot be supported through the NixOS 23.05 release cycle. https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/ You can install it anyway by allowing this package, using the following methods: a) To temporarily allow all insecure packages, you can use an environment variable for a single invocation of the nix tools: $ export NIXPKGS_ALLOW_INSECURE=1 Note: For `nix shell`, `nix build`, `nix develop` or any other Nix 2.4+ (Flake) command, `--impure` must be passed in order to read this environment variable. b) for `nixos-rebuild` you can add ‘openssl-1.1.1v’ to `nixpkgs.config.permittedInsecurePackages` in the configuration.nix, like so: { nixpkgs.config.permittedInsecurePackages = [ "openssl-1.1.1v" ]; } c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add ‘openssl-1.1.1v’ to `permittedInsecurePackages` in ~/.config/nixpkgs/config.nix, like so: { permittedInsecurePackages = [ "openssl-1.1.1v" ]; } ```

devenv version

devenv: 0.6.3

Any advice is appreciated, thanks!

[sevillaarvin]

I should note that I am able to use it in another project successfully:

cli error without permittedInsecurePackages

``` error: Package ‘nodejs-16.20.2’ in «github:NixOS/nixpkgs/f0451844bbdf545f696f029d1448de4906c7f753»/pkgs/development/web/nodejs/v16.nix:16 is marked as insecure, refusing to evaluate. Known issues: - This NodeJS release has reached its end of life. See https://nodejs.org/en/about/releases/. You can install it anyway by allowing this package, using the following methods: a) To temporarily allow all insecure packages, you can use an environment variable for a single invocation of the nix tools: $ export NIXPKGS_ALLOW_INSECURE=1 Note: For `nix shell`, `nix build`, `nix develop` or any other Nix 2.4+ (Flake) command, `--impure` must be passed in order to read this environment variable. b) for `nixos-rebuild` you can add ‘nodejs-16.20.2’ to `nixpkgs.config.permittedInsecurePackages` in the configuration.nix, like so: { nixpkgs.config.permittedInsecurePackages = [ "nodejs-16.20.2" ]; } c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add ‘nodejs-16.20.2’ to `permittedInsecurePackages` in ~/.config/nixpkgs/config.nix, like so: { permittedInsecurePackages = [ "nodejs-16.20.2" ]; } direnv: loading the environment failed direnv: error exit status 1 ```

success with permittedInsecurePackages in devenv.yaml

```yaml inputs: nixpkgs: url: github:NixOS/nixpkgs/nixpkgs-unstable permittedInsecurePackages: - "nodejs-16.20.2" ```

direnv.nix

```nix { pkgs, ... }: { packages = with pkgs; [ nodePackages.typescript-language-server nodePackages.volar ]; enterShell = '' export VUE_LANGUAGE_SERVER_TSDK="$(dirname $(dirname $(which -a typescript-language-server)))/lib/node_modules/typescript/lib" ''; languages.javascript = { enable = true; package = pkgs.nodejs-16_x; }; # https://devenv.sh/pre-commit-hooks/ # pre-commit.hooks.shellcheck.enable = true; } ```

EDIT: Also I'm using MacOS 13.5 if that matters.

[domenkozar]

The issue here is that nixpkgs is imported by https://github.com/bobvanderlinden/nixpkgs-ruby doesn't pass our settings.

We'd have to somehow collect config in flakes at central location so all imports of nixpkgs can use it.

cc @bobvanderlinden

[domenkozar]

We can fix this for #745 by setting NIXPKGS_CONFIG so that all nixpkgs imports respect it.

[bobvanderlinden]

Hmm, that is indeed unfortunate. NIXPKGS_CONFIG sounds like a way to go for now since we're using impure Nix in devenv. Hopefully these kinds of issues can be resolved in Nix Flakes eventually.

[domenkozar]

We got rid of --impure so we'll have to be creative solving this one.

[bobvanderlinden]

Hmm, indeed. This is tricky.

I'm thinking that nixpkgs-ruby should allow injecting pkgs or nixpkgs config? Downside is that it doesnt seem to match with any flake standard and we're thinking up a new solution.

Or avoid using nixpkgs in nixpkgs-ruby by using the overlay on devenvs nixpkgs. More standardized, but it'll probably not be able to use the cache of nixpkgs-ruby.

[domenkozar]

I managed to come up with a way to fix this, going to write a prototype tomorrow.

It should work as long as you use nixpkgs.legacyPackages and follow the nixpkgs we provide.

[instantepiphany]

I managed to come up with a way to fix this, going to write a prototype tomorrow.

It should work as long as you use nixpkgs.legacyPackages and follow the nixpkgs we provide.

I just came up against this. nodejs-16* was removed from nixpkgs November 2023.

My understanding is that to use it, I need to have a specific input that uses the revision that still had that package in the tree.

Are you saying your fix will only work for nixpkgs inputs that follow the devenv one?

As that means old packages (that are no longer in the nixpkgs tree provided with devenv) can't be installed, right?

I suppose one workaround is repackaging nodejs-16* in my own flake and pulling that in that way.

Would that be the best path forward for this case?

[bobvanderlinden]

Regarding nodejs-16, it is a different issue. It isn't so much an insecure package, it is removed from nixpkgs. See https://github.com/cachix/devenv/issues/218#issuecomment-1365842092 for an example on how to use packages from older nixpkgs. The issues that cover this are: https://github.com/cachix/devenv/issues/16 and https://github.com/cachix/devenv/issues/681

As for insecure packages, they could also be overridden in an overlay. Always use an overlay for (for instance) nixpkgs-ruby and having a way to mark packages as non-insecure (which uses override of meta behind the scenes).

[domenkozar]

Relevent nix issue https://github.com/NixOS/nix/issues/9875

[domenkozar]

I've implemented this in 427d360faec649842761919c6be9911e5286603a, but there's no way to convince flakes to allow importing an absolute path here: https://github.com/NixOS/nixpkgs/blob/c2e03072b8e365b0a76cf884f781f0f196b96214/pkgs/top-level/impure.nix#L31

Tests for this are in 4af4099b14dfd6802b81bfa2dd6059ab4b332c26 once someone circles back to it.

[instantepiphany]

Regarding nodejs-16, it is a different issue. It isn't so much an insecure package, it is removed from nixpkgs. See #218 (comment) for an example on how to use packages from older nixpkgs. The issues that cover this are: #16 and #681

The second sentence of my comment was that nodejs-16 was removed 😄 My problem was that even specifying an older revision of nixpkgs as an input (the last one that had nodejs-16), I got the same error as the original comment in this issue, and when I followed the instructions it didn't fix it - just like the original comment.

As for insecure packages, they could also be overridden in an overlay. Always use an overlay for (for instance) nixpkgs-ruby and having a way to mark packages as non-insecure (which uses override of meta behind the scenes). I'm not sure what you mean by this - I haven't used overlays a lot, but I think I understand roughly what they do - overlay certain packages on top of nixpkgs - like using the // operator. Does this somehow avoid the insecure check?

I ended up fixing it by running export NIXPKGS_ALLOW_INSECURE=1 devenv shell --impure, or by adding something to my global nix config, I can't recall (it is on a different machine).

@domenkozar the commit you reference isn't in a branch on this repo, I can't see it in the rust rewrite you mentioned this issue in, and when I look at the code in the commit you referenced, that code change isn't in the same file on main.

I also can't see anything in docs about it. Did it maybe get lost in that sizeable PR, or did you achieve the same functionality with different code?

[domenkozar]

I've explored this in different directions and found out the only way to make it work with by using NIXPKGS_CONFIG, the problem is that the current semantics allow for builtins.pathExists to only return true to paths references by self, so that needs to be addressed bofore this can be fixed.

We could support NIXPKGS_ALLOW_INSECURE, but not permittedInsecurePackages in the current form. Note that I'm wary of supporting NIXPKGS_ALLOW_INSECURE as a global hook, I'd prefer each insecure package should be marked as accepted individually.

[instantepiphany]

We could support NIXPKGS_ALLOW_INSECURE, but not permittedInsecurePackages in the current form. Note that I'm wary of supporting NIXPKGS_ALLOW_INSECURE as a global hook, I'd prefer each insecure package should be marked as accepted individually.

That is unfortunate! I also would much prefer to allow packages individually. I'm hoping to get my company onboard with nixpkgs, probably via devenv. It would certainly be better from a security point of view to have the list of permitted insecure packages approach be possible.

I'd then be able to import that list from a separate file, which requires me or someone from my team to approve changes. Would make keeping things secure a lot easier.

Otherwise, setting NIXPKGS_ALLOW_INSECURE in our systems would make it too easy IMO for insecure packages to get into our code.

Thanks for reopening.

[domenkozar]

This issue is a top priority for me, and I need to brainstorm a way to make progress.

[lucasvignolireis]

Hey same issue here. While commit https://github.com/cachix/devenv/commit/7fa7e03942aee268c719d9d30b8c65b74850509e still is not in the air, is there a quick & dirty way to allow insecure packages using .envrc?

---

UPDATE SOLVED WITH:

impure: true

in devenv.yaml

AND

export NIXPKGS_ALLOW_INSECURE=1
use devenv

in .envrc

Although solution is a dirty fix, while some more intuitive way using permittedInsecurePackages and/or additional stuff in .yaml would be better. Does the above commit will allow for a better way?

[agreif84]

Are there any updates on this topic? @instantepiphany Did you manage to use devenv with node16? It may be EOL but we have legacy projects that cannot be updatet atm so we are still in the urge of using that version.

[instantepiphany]

Are there any updates on this topic? @instantepiphany Did you manage to use devenv with node16? It may be EOL but we have legacy projects that cannot be updatet atm so we are still in the urge of using that version.

I don't recall if I got devenv working. I just checked where we use Node 16 via Nix and all I committed was a shell.nix with no special options, just specifying Node 16 as a package.

So I probably just set the NIXPKGS_ALLOW_INSECURE=1 envvar via an .envrc file on my local machine to get it working.

Maybe try the approach mentioned above: https://github.com/cachix/devenv/issues/792#issuecomment-2043166453

My company has now committed to Nix - we are using it in production and we are already growing the scope of what it handles for us. I've been writing everything in plain flakes so far - I'm quite comfortable with "vanilla" Nix with flakes. But for the internal "customers" of the files I'm writing, I want them to have a more user friendly way of installing packages, hence trying to get devenv working.

We've also upgraded our internal code that used Node 16, so we don't need that to work in Devenv anymore. But I'm still hoping Devenv gains this capability, as I don't want a binary flag that allows all insecure packages to be installed enabled on my colleagues machines.

[agreif84]

Thanks @instantepiphany for your reply and support. I'll see if I can get a workaround.

[domenkozar]

Going to be addressed by #1548