Age | Commit message (Collapse) | Author |
|
|
|
|
|
When `NIX_DAEMON_PACKAGE` is set, make all the tests use the Nix daemon.
That way we can test every piece of Nix functionality both with and
without the daemon.
Tests for which using the daemon isn’t possible or doesn’t make sens can
selectively be disabled with `needLocalStore`
|
|
the compressed hash"
|
|
narinfo: Change NAR URLs to be addressed on the NAR hash instead of the compressed hash
|
|
compressed hash
This change is to simplify [Trustix](https://github.com/tweag/trustix) indexing and makes it possible to reconstruct this URL regardless of the compression used.
In particular this means that https://github.com/tweag/trustix/blob/7c2e9ca597de233846e0b265fb081626ca6c59d8/contrib/nix/nar/nar.go#L61-L71 can be removed and only the bits that are required to establish trust needs to be published in the Trustix build logs.
|
|
|
|
|
|
|
|
Trying to make sure it work with obscurers stores.
|
|
|
|
|
|
This was causing a failure on macOS.
https://hydra.nixos.org/build/130354318
|
|
|
|
|
|
These are not supposed to include the 'name' part of the store
path. This was broken by 759947bf72.
|
|
It is in fact more sorted than before, but I don't think we want to
guarantee anything about the ordering.
|
|
|
|
|
|
|
|
|
|
Issue #3373.
|
|
|
|
|
|
|
|
|
|
|
|
Unlike signed-binary-caches (which could only be '*' or ''),
require-sigs is a proper Boolean option. The default is true.
|
|
The name had become a misnomer since it's not only for substitution
from binary caches, but when adding/copying any
(non-content-addressed) path to a store.
|
|
In particular, don't show superfluous "fetching path" and "building
path(s)" messages, and show the current round (with --repeat).
|
|
`nix copy` no longer accepts a `--recursive` argument
|
|
|
|
Rarely used, nix copy replaces it.
|
|
Also, test HttpBinaryCacheStore in addition to LocalBinaryCacheStore.
|
|
|
|
|
|
This is now done in LocalStore::addToStore(), rather than in the
binary cache substituter (which no longer exists).
|
|
|
|
Manifests have been superseded by binary caches for years. This also
gets rid of nix-pull, nix-generate-patches and bsdiff/bspatch.
|
|
This ensures proper permissions for the secret key.
|
|
|
|
Sodium's Ed25519 signatures are much shorter than OpenSSL's RSA
signatures. Public keys are also much shorter, so they're now
specified directly in the nix.conf option ‘binary-cache-public-keys’.
The new command ‘nix-store --generate-binary-cache-key’ generates and
prints a public and secret key.
|
|
|
|
|
|
|
|
|
|
NAR info files in binary caches can now have a cryptographic signature
that Nix will verify before using the corresponding NAR file.
To create a private/public key pair for signing and verifying a binary
cache, do:
$ openssl genrsa -out ./cache-key.sec 2048
$ openssl rsa -in ./cache-key.sec -pubout > ./cache-key.pub
You should also come up with a symbolic name for the key, such as
"cache.example.org-1". This will be used by clients to look up the
public key. (It's a good idea to number keys, in case you ever need
to revoke/replace one.)
To create a binary cache signed with the private key:
$ nix-push --dest /path/to/binary-cache --key ./cache-key.sec --key-name cache.example.org-1
The public key (cache-key.pub) should be distributed to the clients.
They should have a nix.conf should contain something like:
signed-binary-caches = *
binary-cache-public-key-cache.example.org-1 = /path/to/cache-key.pub
If all works well, then if Nix fetches something from the signed
binary cache, you will see a message like:
*** Downloading ‘http://cache.example.org/nar/7dppcj5sc1nda7l54rjc0g5l1hamj09j-subversion-1.7.11’ (signed by ‘cache.example.org-1’) to ‘/nix/store/7dppcj5sc1nda7l54rjc0g5l1hamj09j-subversion-1.7.11’...
On the other hand, if the signature is wrong, you get a message like
NAR info file `http://cache.example.org/7dppcj5sc1nda7l54rjc0g5l1hamj09j.narinfo' has an invalid signature; ignoring
Signatures are implemented as a single line appended to the NAR info
file, which looks like this:
Signature: 1;cache.example.org-1;HQ9Xzyanq9iV...muQ==
Thus the signature has 3 fields: a version (currently "1"), the ID of
key, and the base64-encoded signature of the SHA-256 hash of the
contents of the NAR info file up to but not including the Signature
line.
Issue #75.
|
|
Issue NixOS/hydra#102.
|
|
|
|
|