From: Alyssa Ross <hi@alyssa.is>
To: devel@spectrum-os.org
Subject: Binary cache key rotation
Date: Fri, 16 Aug 2024 21:01:14 +0200 [thread overview]
Message-ID: <87zfpc5m2t.fsf@alyssa.is> (raw)
[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]
Some of you may know that a few months ago, the Spectrum binary cache
builder broke, because a change to the TLS on github.com (where the
builder downloaded NixOS netboot images from) meant that Vultr's iPXE
was no longer able to connect to it, and Vultr told me they couldn't
give a timeline on updating iPXE to include the fix[1].
In the time since then, I've been working on a new binary cache builder
with no need for iPXE — more information in the commit message[2]. One
of the nice things about the new design is that it allows for being a
little bit more careful with the key — it's stored in Scaleway's Secret
Manager[3] (which stores it encrypted), and it's never written to disk
unencrypted by the builder. Given this slightly higher level of
security for the key, it makes sense to transition to a new key that has
never been stored outside of this arrangement. (I generated it from
Tails.)
So, if you have Nix configured to trust the old binary cache key,
spectrum-os.org-1:rnnSumz3+Dbs5uewPlwZSTP0k3g/5SRG4hD7Wbr9YuQ=, you
should replace that in your configuration with the new key,
spectrum-os.org-2:foQk3r7t2VpRx92CaXb5ROyy/NBdRJQG2uX2XJMYZfU=. During
the Tails session where I generated the new key, I also generated and
uploaded signatures for all store paths in the binary cache that had a
valid signature from the old key, so it's possible to distrust the old
key without losing the ability to substitute old paths from the binary
cache. In future, all store paths built by the builder will only be
signed with the new key.
I've updated the binary cache documentation to describe the new binary
cache[4]. The rendered documentation on the website will update once
the new builder has completed its first build.
This is a small evolutionary step for builder security — I'd probably
still want to do more before using it to build non-development images,
for example having the key on an HSM rather than being on the builder's
filesystem.
[1]: https://github.com/ipxe/ipxe/commit/1d1cf74a5e58811822bee4b3da3cff7282fcdfca
[2]: https://spectrum-os.org/git/infra/commit/?id=ef9717440ff4e000cb50009bb68ba3b4c9eb17ef
[3]: https://www.scaleway.com/en/secret-manager/
[4]: https://spectrum-os.org/git/spectrum/commit/?id=f5a75c9739d9ab23323734ccdfda425a9eb65034
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
reply other threads:[~2024-08-16 19:01 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zfpc5m2t.fsf@alyssa.is \
--to=hi@alyssa.is \
--cc=devel@spectrum-os.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://spectrum-os.org/git/crosvm
https://spectrum-os.org/git/doc
https://spectrum-os.org/git/mktuntap
https://spectrum-os.org/git/nixpkgs
https://spectrum-os.org/git/spectrum
https://spectrum-os.org/git/ucspi-vsock
https://spectrum-os.org/git/www
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).