Skip to content
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

Download page is missing signatures #9302

Open
KaiHicks opened this issue Nov 6, 2023 · 5 comments
Open

Download page is missing signatures #9302

KaiHicks opened this issue Nov 6, 2023 · 5 comments
Labels
bug security Security-related issues

Comments

@KaiHicks
Copy link

KaiHicks commented Nov 6, 2023

Describe the bug

The download page (https://nixos.org/download) does not contain signature for any downloads.

Expected behavior

Multiple issues exist on this topic which have been closed with a comment suggesting that the download page does contain signatures (#17 #404 #3293). However as of the time of writing, the download page does not contain signatures (https://web.archive.org/web/20230306110939/https://nixos.org/download).

Additional context

The download page does contain SHA-256 digests. But these are distinct from digital signatures because while a digest protects against accidental modification, they do not offer any protection against intentional modification. So without digital signatures, a threat actor could tamper with files at rest or in-flight without the user knowing.

Many companies require all software to be cryptographically signed to prevent supply-chain attacks. So all Nix products are not permitted in such environments.

@KaiHicks KaiHicks added the bug label Nov 6, 2023
@roberth roberth added the security Security-related issues label Nov 6, 2023
@thufschmitt
Copy link
Member

They used to be stored alongside the tarballs on https://releases.nixos.org/. We don't do that (as of 2.12 I think) any more as the signing was a painful manual process and if wasn't clear that anyone was actually looking at the signatures.

Once we have an automated release process, we'd be happy to accept contributions that add it back in a less painful way.

@cole-h
Copy link
Member

cole-h commented Nov 7, 2023

(FYI, here's the commit where it was removed from the release process: 8fc9a4e)

@KaiHicks
Copy link
Author

KaiHicks commented Nov 7, 2023

Thank you for the insights @thufschmitt and thank you for pulling up the commit @cole-h! What does the commit mean by "This makes it easier for others to make releases"? Is it possible for this be re-added and controlled with a flag to give the best of both worlds?

@cole-h
Copy link
Member

cole-h commented Nov 7, 2023

It means releases used to be signed by Eelco's GPG key (or at least a GPG key only Eelco has access to). By removing that as a requirement for release, the release process is less beholden to Eelco's availability.

As Theophane said above, once there is an automated release process, signatures might make a return. I would highly doubt that we would re-add the GPG signing before that (or even after that -- GPG keys are notoriously hard to handle and there may be better solutions by the time this happens).

@KaiHicks
Copy link
Author

KaiHicks commented Nov 9, 2023

If signing all releases is not a possibility, is there some other way I can verify the integrity and authenticity before I install? Would it be possible to bootstrap a secure install starting with an older signed release. Then I could apply updates (which I have heard are signed) and build an iso from the resulting installation?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug security Security-related issues
Projects
None yet
Development

No branches or pull requests

4 participants