Has anybody seen my keys? A key-hierarchy strategy for rack-level security
Oxide's RFD 0301 proposes a rack-level key hierarchy using Shamir secret sharing and a trust quorum to protect data-at-rest keys.
Oxide's request for discussion (RFD 0301) lays out a key-hierarchy strategy for rack-level security, deriving keys from a rack secret protected by Shamir secret sharing across a trust quorum of sleds, with keys exchanged over authenticated sprockets sessions. The document maps which keys protect control-plane data, metrics, Crucible extents, and authentication tokens, and defines open questions on key lifecycle, locality, and compromise handling. Future work includes sealing shares with the root of trust so an attacker would need to steal K whole sleds to reconstruct the rack secret.
commit-rewriter 0.1
Simon Willison released commit-rewriter 0.1, a tool that rewrites git commit messages from the first edited commit, with a timestamped revert branch.
Simon Willison built commit-rewriter 0.1, a small web app for editing git commit messages, motivated by cleaning up Datasette security release commits that contained coding agent cruft and private issue IDs. It runs via 'uvx commit-rewriter path/to/repo' and creates a timestamped branch of the repo state before rewriting every commit from the first edited one to the most recent, allowing easy reversion.
Guppy: Efficient Light Clients via Recursive Zero-Knowledge Proofs
Guppy lets blockchain light clients verify full state via recursive zero-knowledge proofs without validators maintaining state commitments, processing thousands of updates per second.
Guppy is a light-client protocol in which validators commit only to state updates while an off-chain, untrusted service secured by recursive zero-knowledge proofs maintains a verifiable Merkle tree over the full state. A hash-chain commitment moves validator signature verification out of the proving circuit, and a parallel recursive proving pipeline keeps latency growth logarithmic with throughput. A Plonky2-based implementation maintains a tree of size 2^30 while processing thousands of updates per second, adding only 2-4 seconds of latency without increasing block-construction complexity.