I was hunting around for something like this but couldn’t find anything.
All things in binary cache are signed, so if you do e.g.
nix-store --realize -Q /nix/store/gidg2ppiyavn49vl7zhykmi8argbs83f-nixos-minimal-23.05pre450349.4d7c2644dba-x86_64-linux.iso
signatures will get verified, but it’s not really meant for a human to run the verification explicitly and AFAIK there’s no web of trust. (BTW, how would you get the corresponding GPG key? Downloaded from our web?)
I’m by no means a PKI expert.
At the very least, if the key is distributed on different infrastructure than the webserver which hosts the artifacts (ISOs e.g.) with their signed checksums, it would increase the effort required on the part of an attacker.
At least that is how I understand it, because I am not a security expert.
in addition to @vcunat reply, you can also find checksums of each ISO somewhere on hydra.
Sorry if I wasn’t more clear, but I was thinking about my experience as a new user who wants to verify that my ISO file downloaded without corruption or tampering. To have that experience, I would need these things to be provided in an accessible manner. I think.
Or maybe the NixOS installation instructions provide those guarantees in a way I am not able to understand.
Corruption: there’s sha256 even linked next to download buttons.
Tampering: well, you have at least https:// i.e. web certificates for
*.nixos.org. Even if there was a PGP signature (though there is something in my previous comment), I can’t see an easy way to get a better chain of trust than through similar web certs again (though probably some that are tamperable by fewer machines/people).
As I understand it, this page provided by Ubuntu (Ubuntu 22.10 (Kinetic Kudu)) provides an extra bit of protection by means of the signatures. An attacker would not be able to compromise the webserver and provide an alternate ISO that would pass gpg verification, since the PKI used to distribute the key is separate from the host that serves the ISOs.
If I can be permitted to use a pedestrian analogy, think of how 2FA authentication is more secure because of the extra factor required for authentication.
The attacker has to compromise two targets; compromising one is no longer sufficient.
I should add that distributions like Ubuntu and Debian have tools built to handle the case of distributing build artifacts by means of 3rd party mirrors. It is clear that since they do not operate the mirror anyone with perms on the mirror could change the ISOs and the checksums.
However it still seems to me that NixOS users’ security could be improved by means of such signatures.
Edit: As I understand it,
https i.e. TLS will only guarantee that I am talking to a particular server, not that the server wasn’t compromised.
The signature that I mentioned in my first reply is done by the process which creates packages (and ISOs) and uploads them to the CDN. I expect it will be rather hard for us to improve that, except for visibility of the signature, etc.
Checking the hashes on hydra functions as a second factor to some degree, since it’s a totally separate server.
The problem is that if I, the end user, depend on your binary, but don’t have the means to check the signature, anything could be in there. You can sign it with a thousand signatures without improving my security. This question is, am I able to verify that the software came from you?
Signatory — Build Control Plane, i.e. CI
Verifier — Signatory’s Public Key is trusted in
nix.conf by the user
Signature Holder — Binary Cache (has no agency in this other than persisting data)
The trust goes from the Verifier to the Signatory by trusting his Public Key.
Essentially, we would need a Hydra (or a special worker for Hydra) with access to a secret key to sign the ISOs.
Then, assuming you trust Hydra to only sign valid ISOs, you would be able to verify the ISOs. Minisign (as it uses deterministic signatures) would be a user friendly option.
Maybe this can be bolted on in a way similar to signing of the narinfo files provides similar security but is less user friendly than using minisign.