nixpkgs: allow packages to be marked insecure (this time with docs)

[grahamc]

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]

@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]

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

[grahamc]

🍾

[basvandijk]

"unfree" should probably be "insecure" here.

[vcunat]

That had been fixed: a50222b

[Profpatsch]

@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]

Profpatsch <notifications@github.com> writes:

``` systemPackages = [ … insecurePackages.somePkg ]; ```

I had considered this, and indeed implemented this method first. However, I couldn't come up with a way to tell the user to install it. Using the name of the package was an easy method. e: did the user use `pkgs.foobar`? `mypkgs.foobar`? `top.level.whatever.myconfig.what.am.i.doing.foobar`? Seemed tricky, but maybe worth doing if we can make the documentation easier to understand.

[Profpatsch]

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]

Profpatsch <notifications@github.com> writes:

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.

It is tough, because the input hash isn't the deciding factor on whether or not it is insecure. It is the source file + the patches applied to it which make it secure or insecure, and I think he name best represents that.. The input dependencies are not relevant. Pinning by hash is ungainly. Another example is the following timeline: * libfoo is marked insecure for reason A * user switches from `pkgs.libfoo` to `insecurePackages.libfoo` because they've decided reason A is an acceptable risk in their environment. * libfoo is marked as secure due to update from v1 to v2 * libfoo is marked as insecure for reason B * user is not aware libfoo v2 is insecure for reason B and hasn't been given an opportunity to evaluate the risk of reason B. * user's environment gets pwnd This is another reason I chose to avoid the `insecurePackages` route, and stuck with a name-based whitelist.

[Profpatsch]

I see, it’s not very sensible then.