Daily AI Digest — 2026-09-26
Hacker News Signals
Platform-independent SIMD in Go
Go’s standard library and runtime have long relied on hand-written assembly for SIMD-accelerated paths (AES, SHA, CRC, etc.), which means each target architecture (amd64, arm64, s390x, …) requires a separate implementation. The experiment described in this post proposes a portable SIMD abstraction layer that compiles down to architecture-specific vector instructions without per-platform assembly.
The design introduces a simd package with fixed-width vector types (Vector[T, N]) and a set of intrinsic-style operations. The compiler backend lowers these to the appropriate ISA intrinsics at code-generation time — SSE/AVX on x86-64, NEON on arm64, and so on. The key engineering tension is expressiveness vs. portability: the abstraction must be rich enough to avoid leaving performance on the table while not exposing operations that have no reasonable analog on some target.
The post walks through a concrete SHA-256 implementation rewritten with the new API, showing that the portable version matches the hand-tuned assembly throughput on amd64 and arm64. Benchmarks show roughly equivalent MB/s to the existing crypto/sha256 assembly paths.
Open questions include: how to handle width-variable SIMD (AVX-512 vs. 128-bit NEON), whether the abstraction can express horizontal reductions cleanly, and whether the compiler can auto-vectorize loops on top of this rather than requiring explicit vector types. The experiment is not yet merged into the Go toolchain and is explicitly labeled as exploratory.
For systems programmers, the interesting constraint is Go’s no-CGo, no-intrinsics philosophy. The design must live entirely in the type system and compiler IR, not as thin wrappers over <immintrin.h>. Whether the IR is expressive enough for advanced shuffle patterns (VPSHUFB, TBL) without becoming architecture-specific in disguise is the central open problem.
Source: https://go.dev/blog/simd-experiment
Entering and Breaking the Avast Antivirus Sandbox Part 2
This is a detailed exploit chain writeup for CVE-2025-13032 targeting Avast’s user-mode sandbox. Part 1 covered getting code execution inside the sandbox; Part 2 focuses on escaping it.
Avast’s sandbox uses a combination of process isolation and a custom system-call interception layer. The escape technique leverages a TOCTOU race in the sandbox’s file handle validation. When a sandboxed process requests a handle to a resource, the broker validates the path, then hands back the handle — but the canonical path resolution and the actual object open are not atomic. By racing a symlink substitution between validation and use, the attacker can redirect the open to an arbitrary path outside the sandbox boundary.
The second primitive involves the sandbox IPC mechanism. The broker exposes a named pipe for sandboxed processes to request elevated operations. The researchers found that message deserialization did not validate object lifetimes correctly, allowing a use-after-free in the broker process (which runs at higher privilege). Combining the file handle confusion with a controlled allocation into the freed region gives write-what-where in the broker, leading to code execution outside the sandbox.
The writeup is technically precise: it includes the relevant IPC message structures, the race window analysis (measured in microseconds, requiring a spinning thread to reliably hit), and the heap-grooming sequence for the UAF. Exploitation required no kernel bugs — the entire chain stays in user space, which is the more interesting result. Avast’s sandbox model evidently assumes the broker is a hard boundary, but the IPC surface was not audited with the same rigor as the syscall interception layer.
Patch status: fixed in the version cited in the CVE.
OpenAI GPT-6 Astra breaks Enigma message that has resisted solution since 2005
The MVUEH message is a short (about 60-character) Enigma intercept from 1944 that has been listed on the Cipher Mysteries / crypto cellar unsolved list for roughly two decades. The difficulty is the combination of short ciphertext (statistical attacks need length), unknown indicator settings, and ambiguity in the original transcription.
The reported break uses GPT-6 “Astra” in a loop with a classical hillclimbing decryption engine. The LLM’s role is not to directly crack the cipher — Enigma is a deterministic rotor machine and the keyspace search is a combinatorial problem, not a language modeling one. Instead, the LLM is used as a heuristic fitness evaluator and to resolve transcription ambiguities: given candidate plaintexts from the hillclimber, the model scores them for German military plausibility and flags character-level transcription errors that would explain statistical anomalies in the ciphertext.
The claimed plaintext is a short weather observation message. The methodology is worth scrutinizing: the hillclimber uses index-of-coincidence and bigram scoring as the primary fitness function; the LLM is invoked only when the top-N candidates are within a narrow score band. This is a reasonable architecture — the model is used for high-level semantic disambiguation, not low-level search.
The main caveat is verifiability. The plaintext is plausible in format and period-appropriate vocabulary, but independent confirmation requires someone to reproduce the key settings and verify the rotor/reflector combination against the known Enigma variants in service on that network in mid-1944. The cryptanalysis community will likely require that before calling this definitively solved.
Source: https://www.cryptocellar.org/bgac/the-mvueh-break.html
We just shipped support for the ugliest part of HTTP: Vary
The HTTP Vary response header tells caches that the stored response is keyed not just on the URL but also on specific request headers. For example, Vary: Accept-Encoding means a gzip-compressed response and an uncompressed response are distinct cache entries for the same URL. Cloudflare’s cache historically ignored or simplified Vary handling; this post describes shipping correct, general Vary support.
The engineering problem is non-trivial. A cache keyed purely on URL is a simple key-value store. Adding Vary turns it into a multi-dimensional lookup: for each URL, there may be k distinct header combinations, each with its own cached response. Cloudflare’s edge has to store and look up these variants efficiently across their distributed cache infrastructure.
The implementation stores each variant as a separate cache object with a key derived from a normalized hash of the URL plus the values of the headers listed in Vary. Normalization is critical: Accept-Encoding: gzip, br and Accept-Encoding: br, gzip should ideally map to the same key if the origin does not distinguish them, but the spec does not require that, so Cloudflare’s implementation hashes the literal header value after whitespace normalization only.
Edge cases documented in the post include: Vary: * (which means “never cache” — handled by bypassing cache entirely), wildcard-like Vary: Cookie (which would explode the variant space — rate-limited and capped), and interaction with Stale-While-Revalidate. The post also notes that Vary: Accept-Language with poorly-behaved origins that return dozens of language variants creates cache thrash, and they impose a per-URL variant cap.
Source: https://blog.cloudflare.com/vary-support/
Security auditing in the age of (good enough) AI
Trail of Bits takes a calibrated position on where LLM-assisted tooling actually changes the security audit workflow, based on their production experience rather than benchmarks on CVE datasets.
Their core claim: LLMs are useful for the mechanical, surface-area-coverage phase of an audit — enumerating entry points, generating initial taint-flow hypotheses, writing boilerplate proof-of-concept harnesses — but are unreliable for the reasoning steps that require tracking multi-hop state invariants across a large codebase. The failure mode is confident incorrectness: the model produces a plausible-looking vulnerability hypothesis with wrong line numbers, wrong data flow, or a mitigation that already exists and was missed.
The practical workflow they describe uses LLMs in a first-pass triage role: feed the model a file or subsystem, ask it to enumerate suspicious patterns, then have a human auditor validate and chase the real ones. This compresses time-to-first-hypothesis but does not compress the validation step, which remains human-bottlenecked.
They also note an adversarial implication: if defenders use AI-assisted auditing, so do offensive researchers, and the marginal cost of finding a class of bugs drops for both sides simultaneously. The net effect on security posture depends on which side has better automation infrastructure and faster patch-to-deploy cycles.
The post is honest about what they have not measured: they do not publish false-positive rates for their internal tooling, and the claim that “AI finds 30% more bugs” common in vendor marketing is critiqued as selection-biased (easy bugs, known vulnerability classes, curated corpora). Worth reading alongside the SoK papers on automated vulnerability discovery for calibration.
Source: https://blog.trailofbits.com/2026/09/18/auditing-in-the-age-of-good-enough-ai/
Postgres SELECT DISTINCT Does Not Scale
SELECT DISTINCT in PostgreSQL is implemented via a HashAggregate or Sort + Unique plan node. For small result sets both are fine, but the post identifies a specific scaling failure mode: when the number of distinct values is large and the working set does not fit in work_mem, the hash aggregate spills to disk in a way that is O(n \log n) in I/O rather than the O(n) one might expect from a hash-based approach.
The root cause is that PostgreSQL’s hash aggregate uses a single-pass hash table with a fixed memory budget. When the budget is exceeded, it does not gracefully switch to a partitioned hash join strategy (as, e.g., DuckDB does with its radix-partitioned aggregation). Instead it falls back to a sort-based deduplication, which requires a full sort of the input. For a table with 10^8 rows and 10^7 distinct values, this means sorting 100M rows to disk — orders of magnitude more I/O than a two-pass partitioned hash would require.
The post demonstrates this with benchmarks: SELECT DISTINCT on a 50GB table takes ~8 minutes on their hardware, while an equivalent GROUP BY with a streaming aggregation hint (or using UNION over indexed scans) takes under 2 minutes for specific access patterns.
The recommended workarounds are: use GROUP BY instead (same semantics, sometimes better plan), add an index that allows an index-only scan with Unique on already-sorted data, or restructure the query to filter earlier. The underlying Postgres planner limitation is a known issue but fixing it requires the hash aggregate to support multi-pass partitioned execution, which is a non-trivial change to the executor.
Source: https://www.dbos.dev/blog/postgres-select-distinct-does-not-scale
Git-bug: Distributed, offline-first bug tracker embedded in Git
git-bug stores bug tracker data — issues, comments, labels, status transitions — directly in the Git object store under a refs/bugs/ namespace, not in the working tree. Each bug is a DAG of operation objects (create, comment, edit, label, status-change) stored as Git blobs and trees, with the bug identity rooted at the SHA of the initial creation object. This is append-only by construction: operations are committed as immutable objects; “edits” are new operation nodes that supersede earlier ones.
The data model is a CRDT-like operation log. Merging two clones that have diverged (both added comments offline) is a Git fetch followed by a DAG merge — no central server arbitrates. Conflict resolution is deterministic: operations are ordered by timestamp with SHA as a tiebreaker, which is eventually consistent but not strictly causal. The trade-off is accepted explicitly in the design documentation.
The practical workflow: git bug push and git bug pull move bug data alongside code using standard Git remote protocols. No sidecar server, no database, no webhook. This makes it suitable for fully air-gapped repositories or scenarios where the forge (GitHub, GitLab) is the single point of failure.
The implementation is in Go. The CLI is the primary interface; there is also a terminal UI and a GraphQL bridge for tooling integration. Bridges to GitHub and GitLab issues exist for import/export, though bidirectional sync with a centralized tracker introduces the consistency problems the design otherwise avoids.
The main limitation is the absence of rich querying: since bugs are stored as Git objects rather than in a relational store, complex queries (multi-label intersection, full-text search) require walking the ref namespace, which is slow for large repositories. There is no indexing layer beyond what Git provides.
Source: https://github.com/git-bug/git-bug
VSCode’s SSH Agent Is Bananas
This post is a detailed forensic analysis of how VSCode Remote SSH actually works, written after the author debugged anomalous SSH agent behavior on Fly.io infrastructure.
The surprising discovery: VSCode does not use the system SSH binary for its remote sessions in the straightforward way. It ships its own Node.js-based SSH client (@vscode/node-ssh-agent) that communicates with the local SSH agent over the agent socket, then independently establishes the connection to the remote host. This means VSCode’s SSH stack is separate from ~/.ssh/config parsing in non-obvious ways — some config directives are honored, others are silently ignored, and the precedence rules differ from OpenSSH.
The agent forwarding behavior is the crux: VSCode forwards the agent socket to the remote host by injecting its own agent forwarding mechanism rather than delegating to ssh -A. On the remote side, it sets $SSH_AUTH_SOCK to a Unix socket managed by a small helper binary it uploads. This helper proxies agent requests back to the local machine over the VSCode multiplexed channel. The side effect is that the agent socket path on the remote is not the one set by the user’s shell profile, breaking tools that hard-code or cache the path.
The security implication is that VSCode’s agent proxy runs as a persistent background process on the remote host for the duration of the session (and sometimes beyond, due to the server process lifecycle). Agent forwarding scope is broader than a single SSH invocation — it persists as long as the VSCode server is alive.
The post includes packet traces and process tree dumps. The recommended mitigation for environments where agent forwarding scope matters is to disable VSCode’s built-in agent forwarding and manage the socket explicitly.
Noteworthy New Repositories
Nehanth/swarmllm
A peer-to-peer LLM inference system that partitions a model (demonstrated with a 27B-parameter network) across multiple browser tabs or devices in the same local environment. The implementation has two core components: a from-scratch WebGPU compute engine that handles tensor operations and weight loading directly in the browser without any native runtime dependency, and a WebRTC-based communication layer that manages peer discovery, weight shard distribution, and activation passing between nodes. Each participating device holds a slice of the model’s layers; forward passes are pipelined across the mesh so that intermediate activations are streamed peer-to-peer rather than routed through a server. The approach is notable because it sidesteps the usual bottleneck of a single device needing enough VRAM to fit the full model — a 27B model at 16-bit precision requires roughly 54 GB, well beyond any consumer GPU, but that footprint can be split across many WebGPU-capable devices. The main engineering challenges being addressed are synchronization latency over WebRTC data channels and the absence of a mature WebGPU compute shader ecosystem. Practical use cases include ad-hoc collaborative inference on heterogeneous consumer hardware without installing local runtimes or paying for API access. Still early-stage; throughput and fault tolerance under node churn are the obvious open questions.
Source: https://github.com/Nehanth/swarmllm
2akouwu/reverify
A hallucination-mitigation framework structured as an MCP (Model Context Protocol) server plus CLI. The core design principle is a strict separation between generative and verification steps: the LLM proposes claims, and a suite of deterministic tools — web search, regex extractors, knowledge-base lookups — adjudicate each claim against retrievable ground truth before the response is returned. Evidence and verified facts are stored in a persistent context that survives session resets, so the system accumulates a grounded knowledge state rather than starting cold each turn. The primary proving ground in the repo is reverse engineering tasks (binary analysis, protocol reconstruction), which are well-suited to verification because many intermediate claims are checkable — addresses, disassembly outputs, known signatures. The architecture follows a propose-then-verify loop: generate claim, dispatch to the appropriate deterministic tool, attach evidence record, propagate only verified claims into subsequent context. The MCP server interface means it can be wired into any MCP-compatible client without tight coupling. Limitations include the usual coverage gaps in deterministic tooling — claims that cannot be grounded in an available tool fall back to unverified, so the system’s reliability is bounded by the breadth of its tool registry.
Source: https://github.com/2akouwu/reverify
sno-ai/sno-station
A local multi-agent orchestration layer that lets Claude Code and OpenAI Codex operate as a coordinated squad on a single machine, with no cloud dependency and no persistent daemon process. The system provides shared encrypted memory so both agents read and write to a common context store, and an agent-to-agent messaging protocol called Reach that enables explicit handoff and cross-vendor review — e.g., one agent drafts a change, the other reviews it. Coordination primitives are packaged as “squad skills,” reusable task templates that encode handoff logic, review criteria, and escalation paths. A nightly loop re-evaluates and rewrites these skills based on accumulated session history, but all modifications require explicit user approval before they take effect — a design choice that keeps the self-modification loop human-supervised rather than fully autonomous. The absence of a daemon means there is no background process with persistent access to credentials or filesystem; sessions are initiated explicitly. This is relevant for security-conscious local deployments. Being assembled in public means the architecture is evolving, so API stability should be assumed low for now.
Source: https://github.com/sno-ai/sno-station
ollaya-dev/ollaya
Ollaya is essentially the Ollama pattern applied to a specific category: decision models. It provides a local pull-and-serve runtime for models oriented toward structured inference tasks — specifically Laya (a general decision model), Decider (binary/multi-class decision), NLI (natural language inference for textual entailment), and GLiClass (generalized linear classifier). All models are served behind a TypeSafe-compatible API, giving TypeScript consumers end-to-end type safety from request construction through response parsing. The motivation is that decision-oriented models are frequently used as components inside larger pipelines (routing, classification, entailment checks) but are usually accessed via paid APIs or awkward self-hosting setups. Running them locally via a single CLI mirrors the developer ergonomics that made Ollama attractive for generative models. The TypeSafe API layer is the main differentiator over simply running these models through a generic inference server like Ollama itself, since it enforces structured inputs and outputs rather than free-form text. Practical fit: pipelines that need fast, local, typed classification or entailment scoring without an external API call.
Source: https://github.com/ollaya-dev/ollaya
Taiquan-Zhou/RunTheRepo
An AI agent that automates the full lifecycle of running a GitHub repository that ships a Docker Compose configuration: cloning, environment setup, container orchestration, test execution, and basic hardening checks. The agent interprets the repo structure to infer how services should be wired, resolves common configuration issues (missing env vars, port conflicts, volume permissions), and runs whatever test suite is present. The hardening component checks for common Docker Compose security issues — exposed ports, privileged containers, missing resource limits — and proposes or applies fixes. The practical problem being solved is that a large fraction of public repos with Docker Compose files require non-trivial manual effort to stand up locally due to underdocumented dependencies and environment assumptions. Automating this is useful both for security research (quickly spinning up targets for analysis) and for developers evaluating third-party services. Built in Python with an LLM driving the decision loop and subprocess/Docker SDK calls executing actions. The main limitation is robustness: repos with bespoke build pipelines or non-standard Compose structures will likely require manual intervention.
Source: https://github.com/Taiquan-Zhou/RunTheRepo
amitshekhariitbhu/ai-system-design
A structured educational reference covering system design for AI-centric applications, focusing specifically on architectures built around LLMs, RAG pipelines, and autonomous agents. The content is organized as a step-by-step progression: foundational patterns (prompt management, context windows, token budgeting), retrieval-augmented architectures (chunking strategies, embedding choices, index design, reranking), agent architectures (tool use, memory, multi-agent coordination), and production concerns (latency, cost, observability). The emphasis is on design trade-offs rather than tutorial-level how-to instructions, making it more useful to engineers who already understand the individual components and need guidance on composing them into reliable systems. This fills a real gap: most ML educational material focuses on model internals, while system design resources rarely address LLM-specific constraints like non-determinism, context length as a resource, or the cost structure of inference APIs. Suitable as a reference during architecture reviews or interview preparation for ML engineering roles where system design questions have shifted toward AI-native patterns.
Source: https://github.com/amitshekhariitbhu/ai-system-design
Adkid-Zephyr/oral-paper-skill
A distillation of writing and research practices extracted from 883 oral-track paper abstracts drawn from top-tier venues. The methodology is essentially few-shot pattern mining: abstracts from accepted oral papers are analyzed to identify recurring structural and rhetorical patterns — how problems are framed, how contributions are scoped, how results are quantified — and these patterns are packaged as a reusable skill-and-prompt pack in both Chinese and English. The intended use case is two-directional: use the skill pack to audit a draft paper by checking it against the extracted patterns (contribution clarity, problem motivation sharpness, result specificity), or use it for post-hoc learning by comparing a submitted paper’s structure against the oral-paper baseline. The prompt pack format means it integrates directly into LLM-assisted writing workflows. The “distillation” framing is apt — this is not a generative model but a curated prompt library grounded in empirical analysis of successful papers. The main caveat is that oral acceptance is correlated with but not solely determined by abstract quality, so the extracted patterns capture surface regularities in successful abstracts rather than a complete causal account of acceptance.