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

[RFC 0149] Cache key rotation #149

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
73 changes: 73 additions & 0 deletions rfcs/0149-cache-key-rotation.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
---
feature: (fill me in with a unique ident, my_awesome_feature)
start-date: (fill me in with today's date, YYYY-MM-DD)
author: (name of the main author)
co-authors: (find a buddy later to help out with the RFC)
shepherd-team: (names, to be nominated and accepted by RFC steering committee)
shepherd-leader: (name to be appointed by RFC steering committee)
related-issues: (will contain links to implementation PRs)
---

# Summary
[summary]: #summary

Rotate cache.nixos.org signing key.

If we tolerate that people using stuff older than *X* could get a validation failure by default, fully rotating the key in 2*X* time seems relatively straightforward.

# Motivation
[motivation]: #motivation

Never rotating a key is bad security practice.
The current one has been in use at least since 2015.

# Detailed design
[design]: #detailed-design

Preliminary action plan:
- generate a new key
- make it trusted by default (nix+nixpkgs, perhaps with backports to some branches)
- wait until enough people trust the new key (at least one year, probably)
- switch to signing with the new key
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we start signing with both keys as soon as it's generated?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had that under preliminary consideration, even with some text. Well, let me really push that text now 🤷🏽

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For me the important milestone isn't signing with the new key but the ability to remove trust for the old key (by default).

- wait - until paths not signed by new key aren't commonly needed anymore
- make Nix not need signatures for fixed-output derivations
(this step could be completed anytime earlier, too)
FIXME: maybe this holds already:
https://nixos.org/manual/nix/unstable/command-ref/conf-file.html#conf-trusted-public-keys
- stop trusting the old key (nix+nixpkgs)



- - -


# Examples and Interactions
[examples-and-interactions]: #examples-and-interactions

This section illustrates the detailed design. This section should clarify all
confusion the reader has from the previous sections. It is especially important
to counterbalance the desired terseness of the detailed design; if you feel
your detailed design is rudely short, consider making this section longer
instead.

# Drawbacks
[drawbacks]: #drawbacks

Why should we *not* do this?

# Alternatives
[alternatives]: #alternatives

What other designs have been considered? What is the impact of not doing this?

# Unresolved questions
[unresolved]: #unresolved-questions

- confirm Nix's (non-)acceptance of FODs without signature
- determine timing (e.g. the *X* above)

# Future work
[future]: #future-work

What future work, if any, would be implied or impacted by this feature
without being directly part of the work?