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.
CVE-2026-85706 | GitLab CE/EE Repository Commits API Path Traversal Vulnerability
GitLab patches CVSS 10.0 path traversal CVE-2026-85706 letting unauthenticated attackers read arbitrary files on self-managed CE/EE servers.
GitLab disclosed CVE-2026-85706, a CVSS 3.1 10.0 path traversal flaw in the repository commits API of self-managed GitLab CE/EE (18.7 before 19.1.8, 19.2 before 19.2.6, 19.3 before 19.3.2), exploitable without authentication to read arbitrary server files. Successful exploitation can expose credentials, tokens, SSH keys, and database credentials accessible to the GitLab process. Fixed versions 19.1.8, 19.2.6, and 19.3.2 were released September 10, 2026; GitLab.com and Dedicated were already patched and no workaround is provided. Horizon3 released a NodeZero Rapid Response test to validate exposure and advises credential rotation for internet-facing instances.
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.