remote machine via the same protocol used by `nix-daemon`.

  - Security has been improved in various ways:

      - Nix now stores signatures for local store paths. When paths are
        copied between stores (e.g., copied from a binary cache to a
        local store), signatures are propagated.

        Locally-built paths are signed automatically using the secret
        keys specified by the `secret-key-files` store option.
        Secret/public key pairs can be generated using `nix-store
                                                                        --generate-binary-cache-key`.

        In addition, locally-built store paths are marked as “ultimately
        trusted”, but this bit is not propagated when paths are copied
        between stores.

      - Content-addressable store paths no longer require signatures —
        they can be imported into a store by unprivileged users even if
        they lack signatures.

      - The command `nix verify` checks whether the specified paths are
        trusted, i.e., have a certain number of trusted signatures, are
        ultimately trusted, or are content-addressed.

      - Substitutions from binary caches
        [now](https://github.com/NixOS/nix/commit/ecbc3fedd3d5bdc5a0e1a0a51b29062f2874ac8b)
        require signatures by default. This was already the case on
        NixOS.

      - In Linux sandbox builds, we
        [now](https://github.com/NixOS/nix/commit/eba840c8a13b465ace90172ff76a0db2899ab11b)
        use `/build` instead of `/tmp` as the temporary build directory.
        This fixes potential security problems when a build accidentally
        stores its `TMPDIR` in some security-sensitive place, such as an
        RPATH.

  - *Pure evaluation mode*. With the `--pure-eval` flag, Nix enables a
    variant of the existing restricted evaluation mode that forbids
    access to anything that could cause different evaluations of the
    same command line arguments to produce a different result. This
    includes builtin functions such as `builtins.getEnv`, but more
    importantly, *all* filesystem or network access unless a content
    hash or commit hash is specified. For example, calls to
    `builtins.fetchGit` are only allowed if a `rev` attribute is
    specified.

    The goal of this feature is to enable true reproducibility and
    traceability of builds (including NixOS system configurations) at
    the evaluation level. For example, in the future, `nixos-rebuild`
    might build configurations from a Nix expression in a Git repository
    in pure mode. That expression might fetch other repositories such as
    Nixpkgs via `builtins.fetchGit`. The commit hash of the top-level
    repository then uniquely identifies a running system, and, in
    conjunction with that repository, allows it to be reproduced or
    modified.

  - There are several new features to support binary reproducibility
    (i.e. to help ensure that multiple builds of the same derivation
    produce exactly the same output). When `enforce-determinism` is set
    to `false`, it’s [no
    longer](https://github.com/NixOS/nix/commit/8bdf83f936adae6f2c907a6d2541e80d4120f051)
    a fatal error if build rounds produce different output. Also, a hook
    named `diff-hook` is
    [provided](https://github.com/NixOS/nix/commit/9a313469a4bdea2d1e8df24d16289dc2a172a169)
    to allow you to run tools such as `diffoscope` when build rounds
    produce different output.

  - Configuring remote builds is a lot easier now. Provided you are not
    using the Nix daemon, you can now just specify a remote build
    machine on the command line, e.g. `--option builders
                    'ssh://my-mac x86_64-darwin'`. The environment variable
    `NIX_BUILD_HOOK` has been removed and is no longer needed. The
    environment variable `NIX_REMOTE_SYSTEMS` is still supported for
    compatibility, but it is also possible to specify builders in
    `nix.conf` by setting the option `builders =
                    @path`.