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

How to use "permittedInsecurePackages"? #792

Open
sevillaarvin opened this issue Aug 17, 2023 · 20 comments · Fixed by #1005
Open

How to use "permittedInsecurePackages"? #792

sevillaarvin opened this issue Aug 17, 2023 · 20 comments · Fixed by #1005
Labels
question Further information is requested
Milestone

Comments

@sevillaarvin
Copy link
Contributor

I have a very similar problem with #623. I see that a new key was added to address this #619.

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

devenv.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
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 sevillaarvin added the question Further information is requested label Aug 17, 2023
@sevillaarvin
Copy link
Contributor Author

sevillaarvin commented Aug 17, 2023

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
inputs:
  nixpkgs:
    url: github:NixOS/nixpkgs/nixpkgs-unstable
permittedInsecurePackages:
  - "nodejs-16.20.2"
direnv.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
Copy link
Member

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

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

@bobvanderlinden
Copy link
Contributor

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

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

@bobvanderlinden
Copy link
Contributor

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

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

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
Copy link
Contributor

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

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

Relevent nix issue NixOS/nix#9875

@domenkozar domenkozar mentioned this issue Mar 15, 2024
2 tasks
@domenkozar
Copy link
Member

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

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

domenkozar commented Mar 22, 2024

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.

@domenkozar domenkozar reopened this Mar 22, 2024
@instantepiphany
Copy link

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

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

@lucasvignolireis
Copy link

lucasvignolireis commented Apr 8, 2024

Hey same issue here. While commit 7fa7e03 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
Copy link

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

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: #792 (comment)

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

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

@domenkozar
Copy link
Member

Going to be addressed by #1548

@domenkozar domenkozar modified the milestones: 1.1, tvix Nov 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants