[RFC 0149] Cache key rotation #149
Conversation
|
This is very preliminary for now, but let me open it as a PR already. |
| - 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 |
There was a problem hiding this comment.
Can we start signing with both keys as soon as it's generated?
There was a problem hiding this comment.
I had that under preliminary consideration, even with some text. Well, let me really push that text now 🤷🏽
There was a problem hiding this comment.
For me the important milestone isn't signing with the new key but the ability to remove trust for the old key (by default).
|
It would be wise to attach keys to releases. This way there will be no need track key start/expiration dates separately, the release number will tell. If a key is compromised, a new release can be published with an incremented minor number. It may be the case where the key is required be published/in place before the release. |
|
I wouldn't do that. Our infrastructure is concurrently building various stuff: multiple NixOS/NixPkgs release branches and also some that are not tied to such a number at all. Similarly from the other side – when Nix looks for some store path in a binary cache, it doesn't care about release numbers. |
|
If that's the case, then there should be mechanism to track key start/expiration dates since the keys are bare not certs. I would be glad to help you in the matter but no free time Im afraid. Even if I have the time, I can't get past the marketing team, they say they have rules. Good luck, hope this problem is gone forever without much trouble ;) |
|
Once a workflow for regular key rotation is finalized, I suppose it might still be useful to tie its schedule to the schedule of NixOS releases. |
infinisil
changed the title
Rotate cache.nixos.org signing key.
Rendered