[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
|
What's blocking this RFC from moving forward? Provided somebody put the work into it, would it be possible to generate a new key and start signing NARs generated by the new infra? |
|
It would be trivial to start. Note that signing in this scheme comes much later. (And some people said they prefer a double-signing scheme.) |
|
Are there any downside to start double signing the NARs with the new key and gradually introduce the new signature in the next Nix release? Edit: I'm up to be a shepherd for this RFC. |
|
|
👍 I'll have a look into that.
Users can decide not to trust the old key in a opt-in fashion during the migration. I think it makes sense to double sign the paths. |
|
Maybe, but we could have got rid of the old key by now if we had started this scheme two years ago, as no changes in tooling would be needed at all. Instead we've been waiting for more perfect stuff which hasn't materialized yet, like a "faster" way to rotate (i.e. double signing) and NixOS/infra#272 |
Add a `secretKeyFiles` URI parameter in the store URIs receiving a coma-separated list of Nix signing keyfiles. The keys passed through this new store URI parameter are merged with the key specified in the `secretKeyFile` paramater, if any. We'd like to rotate the signing key for cache.nixos.org. To simplify the transition, we'd like to sign the new paths with two keys: the new one and the current one. Depending on their Nix configuration, users can decide the new key or decide to revoke trust on the old key. See NixOS/rfcs#149 for more informations behind the motivation.
Add a `secretKeyFiles` URI parameter in the store URIs receiving a
coma-separated list of Nix signing keyfiles.
For instance:
nix copy --to "file:///tmp/store?secret-keys=/tmp/key1,/tmp/key2" \
"$(nix build --print-out-paths nixpkgs#hello)"
The keys passed through this new store URI parameter are merged with
the key specified in the `secretKeyFile` parameter, if any.
We'd like to rotate the signing key for cache.nixos.org. To simplify
the transition, we'd like to sign the new paths with two keys: the new
one and the current one. With this, the cache can support nix
configurations only trusting the new key and legacy configurations
only trusting the current key.
See NixOS/rfcs#149 for more informations
behind the motivation.
Add a `secretKeyFiles` URI parameter in the store URIs receiving a
coma-separated list of Nix signing keyfiles.
For instance:
nix copy --to "file:///tmp/store?secret-keys=/tmp/key1,/tmp/key2" \
"$(nix build --print-out-paths nixpkgs#hello)"
The keys passed through this new store URI parameter are merged with
the key specified in the `secretKeyFile` parameter, if any.
We'd like to rotate the signing key for cache.nixos.org. To simplify
the transition, we'd like to sign the new paths with two keys: the new
one and the current one. With this, the cache can support nix
configurations only trusting the new key and legacy configurations
only trusting the current key.
See NixOS/rfcs#149 for more informations
behind the motivation.
Add a `secretKeyFiles` URI parameter in the store URIs receiving a
coma-separated list of Nix signing keyfiles.
For instance:
nix copy --to "file:///tmp/store?secret-keys=/tmp/key1,/tmp/key2" \
"$(nix build --print-out-paths nixpkgs#hello)"
The keys passed through this new store URI parameter are merged with
the key specified in the `secretKeyFile` parameter, if any.
We'd like to rotate the signing key for cache.nixos.org. To simplify
the transition, we'd like to sign the new paths with two keys: the new
one and the current one. With this, the cache can support nix
configurations only trusting the new key and legacy configurations
only trusting the current key.
See NixOS/rfcs#149 for more informations
behind the motivation.
Add a `secretKeyFiles` URI parameter in the store URIs receiving a
coma-separated list of Nix signing keyfiles.
For instance:
nix copy --to "file:///tmp/store?secret-keys=/tmp/key1,/tmp/key2" \
"$(nix build --print-out-paths nixpkgs#hello)"
The keys passed through this new store URI parameter are merged with
the key specified in the `secretKeyFile` parameter, if any.
We'd like to rotate the signing key for cache.nixos.org. To simplify
the transition, we'd like to sign the new paths with two keys: the new
one and the current one. With this, the cache can support nix
configurations only trusting the new key and legacy configurations
only trusting the current key.
See NixOS/rfcs#149 for more informations
behind the motivation.
Add a `secretKeyFiles` URI parameter in the store URIs receiving a
coma-separated list of Nix signing keyfiles.
For instance:
nix copy --to "file:///tmp/store?secret-keys=/tmp/key1,/tmp/key2" \
"$(nix build --print-out-paths nixpkgs#hello)"
The keys passed through this new store URI parameter are merged with
the key specified in the `secretKeyFile` parameter, if any.
We'd like to rotate the signing key for cache.nixos.org. To simplify
the transition, we'd like to sign the new paths with two keys: the new
one and the current one. With this, the cache can support nix
configurations only trusting the new key and legacy configurations
only trusting the current key.
See NixOS/rfcs#149 for more informations
behind the motivation.
Rotate cache.nixos.org signing key.
Rendered