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 (this time with docs) #23130

Merged
merged 2 commits into from Feb 24, 2017

Conversation

Projects
None yet
6 participants
@grahamc
Member

grahamc commented Feb 24, 2017

Motivation for this change

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.

Things done
  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • Linux
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

Previously merged, but needed docs. So I added docs. see: https://github.com/NixOS/nixpkgs/pull/22890/files

cc @FRidh, @danbst, @jgeerds, @globin, @vcunat (I'm not even asking you to convert my docs to docbook this time :) ), @fpletz, @domenkozar, @7c6f434c.

@mention-bot

This comment has been minimized.

Show comment
Hide comment
@mention-bot

mention-bot Feb 24, 2017

@grahamc, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @matthiasbeyer and @seppeljordan to be potential reviewers.

@grahamc, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @matthiasbeyer and @seppeljordan to be potential reviewers.

@grahamc grahamc changed the title from nixpkgs: allow packages to be marked insecure to nixpkgs: allow packages to be marked insecure (this time with docs) Feb 24, 2017

@grahamc

This comment has been minimized.

Show comment
Hide comment
Member

grahamc commented Feb 24, 2017

You can see the docs rendered here: http://gsc.io/nixpkgs/manual.html#chap-packageconfig

grahamc added some commits Feb 17, 2017

nixpkgs: allow packages to be marked insecure
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.
libplist: mark as insecure
Patches currently available don't seem to apply.

@globin globin merged commit 8f60b43 into NixOS:master Feb 24, 2017

1 check was pending

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details

@grahamc grahamc deleted the grahamc:insecure-packages-with-docs branch Feb 24, 2017

@grahamc grahamc referenced this pull request Feb 24, 2017

Merged

04 weekly news #26

4 of 4 tasks complete
@grahamc

This comment has been minimized.

Show comment
Hide comment
@grahamc

grahamc Feb 24, 2017

Member

🍾

Member

grahamc commented Feb 24, 2017

🍾

vcunat added a commit that referenced this pull request Feb 26, 2017

<para>There are several ways to tweak how Nix handles a package
which has been marked as unfree.</para>

This comment has been minimized.

@basvandijk

basvandijk Feb 28, 2017

Member

"unfree" should probably be "insecure" here.

@basvandijk

basvandijk Feb 28, 2017

Member

"unfree" should probably be "insecure" here.

This comment has been minimized.

@vcunat

vcunat Feb 28, 2017

Member

That had been fixed: a50222b

@vcunat

vcunat Feb 28, 2017

Member

That had been fixed: a50222b

@Profpatsch

This comment has been minimized.

Show comment
Hide comment
@Profpatsch

Profpatsch Mar 3, 2017

Member

@aszlig has found a more “functional” way to enable certain packages:
https://github.com/openlab-aux/vuizvui/blob/350b13fdbb02916aebceed6f115e0b0c38672d3d/modules/core/licensing.nix

It should be possible to adapt that to insecure packages, then they could be marked like this:

systemPackages = [
  …
  insecurePackages.somePkg
  ];

having the semantics of “build, even if the package is marked as insecure”.

Member

Profpatsch commented Mar 3, 2017

@aszlig has found a more “functional” way to enable certain packages:
https://github.com/openlab-aux/vuizvui/blob/350b13fdbb02916aebceed6f115e0b0c38672d3d/modules/core/licensing.nix

It should be possible to adapt that to insecure packages, then they could be marked like this:

systemPackages = [
  …
  insecurePackages.somePkg
  ];

having the semantics of “build, even if the package is marked as insecure”.

@grahamc

This comment has been minimized.

Show comment
Hide comment
@grahamc

grahamc Mar 5, 2017

Member
Member

grahamc commented Mar 5, 2017

@Profpatsch

This comment has been minimized.

Show comment
Hide comment
@Profpatsch

Profpatsch Mar 5, 2017

Member

e: did the user use pkgs.foobar? mypkgs.foobar?

I see. But it should be ok to reference the derivation name and tell the user in a general way I think. Package names are inherently not very nice to have as references because it corrupts the idea of the input hash as authority of version, instead of the arbitrary package name.

Member

Profpatsch commented Mar 5, 2017

e: did the user use pkgs.foobar? mypkgs.foobar?

I see. But it should be ok to reference the derivation name and tell the user in a general way I think. Package names are inherently not very nice to have as references because it corrupts the idea of the input hash as authority of version, instead of the arbitrary package name.

@grahamc

This comment has been minimized.

Show comment
Hide comment
@grahamc

grahamc Mar 5, 2017

Member
Member

grahamc commented Mar 5, 2017

@Profpatsch

This comment has been minimized.

Show comment
Hide comment
@Profpatsch

Profpatsch Mar 5, 2017

Member

I see, it’s not very sensible then.

Member

Profpatsch commented Mar 5, 2017

I see, it’s not very sensible then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment