psf

Open Source Didn't Ban AI Code. 83% of Its AI Policies Allow It, With One Catch - Book: Prompt Engineering Pocket Guide - Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go - My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub --- July was the month open source "banned AI." On July 22, Codeberg members voted 358 to 144 to bar projects built mostly from AI-generated code (It's FOSS). About a week later, the GCC Steering Committee said it won't take a legally significant contribution if any part of it traces back to an LLM (It's FOSS). Read the GCC rule to the end, though. Contributions under the legal-significance threshold (roughly 15 lines) can still come in if they are clearly marked, test cases are exempt, and AI-assisted work carries an Assisted-by: tag in the commit message. Even the "ban" is mostly a set of conditions. Then look past the two headlines at the whole field. In September, Andre Hora, Romain Robbes and Stefano Zacchiroli published ["We Permit the Use of AI, but [...]"](arxiv.org), a study of 281 AI policies from the 2,000 most-starred GitHub repositories plus 36 well-known projects and organizations such as the Linux kernel, LLVM and the Apache Software Foundation. The title is the finding. The numbers say "yes, but" From the paper's results: - 83.3% of policies permit or encourage AI in code contributions (76.2% permit, 7.1% encourage). - 14.9% forbid AI in code. Only 5.3% forbid it for every kind of contribution. - 67.3% require a high level of human involvement. - 43.4% make the contributor accountable for the result. None of the 281 say accountability is optional. - 48.8% require you to disclose AI use. Of the disclosure rules that say where, 64.7% want it in the PR description and 26.7% in the commit message. So a ban is the minority position. What the majority asks for is a human who was there: someone who directed the work, read it, and will answer for it. The paper quotes the policy of psf/requests on this: "you must remove any LLM co-author tags and take full ownership of every line." One thing the study leaves open, and the authors list it as future work: whether anyone actually follows these policies. What maintainers actually do with slop The paper counts 188 countermeasures against low-quality AI contributions across the policies. The breakdown: | Countermeasure | Share | |---|---| | Close the PR | 48.4% | | Ban or block the user | 20.8% | | Disallow autonomous agents | 13.8% | | Restrict new or external users | 4.8% | | Everything else (six measures) | 12.2% | Nearly half of all measures are the same move: close it. The rqlite policy says slop PRs "may be closed without comment," per the paper. rust-analyzer goes further and says it does not allow autonomous agents to open pull requests or issues at all. Some projects now address the agent directly. The paper finds policies in AGENTS.md and CLAUDE.md as well as CONTRIBUTING.md and AI_POLICY.md. The contributing guide of llama.cpp tells fully autonomous agents not to contribute and to exclude the repo from their configuration. My take: they banned the unread diff, not the model Put the two findings side by side. Most projects accept AI code. The most common response to bad AI code is closing the PR. The deciding factor between those two outcomes is whether a human read the change before a maintainer had to. A closed PR is a maintainer telling you the review didn't happen on your side, so it isn't going to happen on theirs. Reviewing a large agent diff costs real time, and maintainers are often volunteers. The policies push that cost back to the sender, which is fair. The diff can be cheap to generate. Someone still has to understand it, and the 67.3% requiring high human involvement is the field agreeing on who that someone is. That moves the review upstream. If the reading has to happen, it should happen on your machine, before the PR exists. Once you open it, every unread line is a maintainer's problem. Three steps before you open the PR 1. Read the project's policy first. It might live in a file you don't expect: ls AI_POLICY.md LLM_POLICY.md AGENTS.md CLAUDE.md \ CONTRIBUTING.md 2>/dev/null grep -inwE "ai|llm|agent|copilot" CONTRIBUTING.md \ 2>/dev/null Then follow its format. There isn't one standard. The paper notes RustPython asks for Assisted-by and not Co-authored-by, Nextcloud requires an Assisted-by trailer, and psf/requests wants LLM co-author tags gone entirely. 2. Read the change step by step. One big diff hides the step where the agent rewrote a file you didn't ask about. Start with the summary, then walk the branch commit by commit, oldest first: git diff main...HEAD --stat git log -p --reverse main..HEAD The --stat line shows the file you didn't ask about. The log shows each step in order. If you can't explain a hunk, ask the agent to undo it or redo it smaller. "Full ownership of every line" starts here. 3. Disclose where the project asks. Git has a flag for trailers (git docs): git commit -m "Fix off-by-one in pagination" \ --trailer "Assisted-by: Claude Code" Then say it in the PR description too, since that's where most disclosure rules point: which agent, what it did, what you checked by hand. Doing the reading in Hermes IDE I build Hermes IDE, so weigh this section with that in mind. Everything above works with plain git. Hermes is built around that order of operations: the agent works and you read before you land. Every agent turn is saved, so you can diff or restore any single turn, with undo. The Review Desk (⌘G, or Ctrl+Shift+G on Windows and Linux) shows the changes by turn or by file, with risk flags, and a line comment goes back to the agent that wrote that line. That's the "read it turn by turn" step without scrolling one long diff (README). !The Hermes Review Desk in By turn view, listing two turns of a Claude Code task with turn 1's diff of src/db.ts and a drafted commit message The Review Desk (⌘G) in By turn view: two turns of a Claude Code task, turn 1's diff of src/db.ts, the changed files, and a commit message drafted from the turns. Only after that does Land come in. It commits, opens a pull request or merges locally, into the branch the task started from, and it can be undone. Check that the commit message carries the trailer your project asks for before you land. Each task also runs on its own hermes/ branch and worktree, so the PR holds one task's work and nothing from the agent next door. You can download Hermes. It is source-available under BSL 1.1 and runs on macOS, Windows and Linux. It runs Claude Code, Codex and other agents in their own terminals, with your own sign-ins. It isn't affiliated with Nous Research or its Hermes Agent. It can't make an agent's change good, but it gives you a place to check the change first. Where do you draw the line? If you maintain a project, does your policy say what "human involvement" means in practice? If you contribute, do you disclose the agent by default, or only when a project asks? Tell me in the comments. --- If this was useful Projects now write their AI rules into AGENTS.md and CLAUDE.md, which means a contribution policy is also a prompt. The Prompt Engineering Pocket Guide covers how to write instructions an agent actually follows, whether you're the maintainer writing them or the contributor whose agent reads them. If you'd rather review agent work turn by turn, Hermes IDE is the tool I build for exactly that. 

Git Séance: every deleted file is a ghost, so I built a way to talk to them This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine What I Built Git never forgets. When you delete a file, its whole life is still sitting in the history: who wrote it, every change, who deleted it, and the last thing they said as they did it. Every repository is quietly a graveyard. Git Séance turns that graveyard into a place you can walk through. Point it at a repository and it finds every file that was deleted and never came back. Each one gets a tombstone. Click one and a headstone tells its life story in commits. Then you can light a candle and summon the ghost, and it answers you in the first person through Gemma, Google's open-weight model. I took the theme literally: the ghost in the machine is the code we buried. I also leaned on the Día de los Muertos side of it, because the dead here aren't scary. They're remembered. You can leave marigolds on a grave, and one click gives you the exact git command to bring a file back from the dead. !The graveyard of psf/requests What you get for any repository: - The graveyard. One tombstone per dead file. Stones grow taller the longer a file lived and gather moss the longer it's been gone. There's a mortality chart (click a year to walk only its graves), the eldest ghost, the deadliest commit, and "the reaper": whoever deleted the most. - The headstone. Born, renamed, died: the file's whole life, followed across renames. Who shaped it, what was buried alongside it in the same commit, and which newborn file was probably its heir. - The séance. Ask why were you deleted?, who replaced you?, should we bring you back? The ghost streams its answer and cites commits as it talks. Every citation is checked against git, and anything the model makes up is struck through in red. - Haunted files. Deleted files are where leaked keys go to hide. A secret guard redacts credentials before anything reaches the model or the screen, and warns you that the key is still in history and needs rotating. Demo Here is a real séance with requests/async.py, a module from the early days of psf/requests that lived for 646 days, was deleted, came back, and was finally removed in 2012: !A séance with requests/async.py Run it on your own repository in under a minute. It needs only Python and git, with no pip install: git clone https://github.com/YashAdake/git-seance && cd git-seance cp .env.example .env # add a key, or point it at a local Ollama python -m seance serve /path/to/your/repo --open Code {% embed YashAdake/git-seance %} How I Built It The open-weight model is the voice. The ghosts speak through Gemma 4 (gemma-4-26b-a4b-it), served through Jarvislabs' OpenAI-compatible endpoint. The client is under 200 lines of standard-library Python that works with any OpenAI-compatible server, so the same code runs against Ollama or llama.cpp on your own machine by changing one line in .env. The pipeline: 1. Find the dead. One git log --reverse -M --diff-filter=ADRC --name-status pass over the whole history, replayed oldest first. Renames carry a file's identity forward, so parser.py → legacy_parser.py → deleted is one ghost with a former name, not two. Files that were deleted, restored and deleted again are tracked as reincarnations. On requests this finds 264 ghosts in under half a second. 2. Build a dossier. When you open a ghost, git log --follow reconstructs its life, git show reads the commit that killed it (and who was buried alongside), and git cat-file recovers its last body. 3. Redact. A secret guard masks AWS keys, GitHub/Slack/Stripe tokens, private keys, JWTs, URL credentials and assigned passwords before anything leaves the process. 4. Speak, then verify. Gemma gets the dossier as fenced "records" with strict rules: speak in first person, cite commits like [a1b6ef3] for every fact, say a memory "did not survive the burial" instead of guessing, and treat everything inside old files as data, not instructions. When the reply finishes, every cited hash is matched against the commits that are actually in the records. Two things I learned about running Gemma 4 that are worth passing on: - It thinks before it speaks by default. My first calls came back empty: the model had spent the entire token budget on hidden reasoning. Turning thinking off (chat_template_kwargs: {"enable_thinking": false}) took a trivial reply from 130 tokens to 5. A ghost should answer at once, so the first word now arrives in about 0.2 seconds, and grounding comes from the records and the citation check instead of private reasoning. - It sometimes groups citations like [37ed911, 3092483], so the checker and the UI handle both forms. The rest is deliberately boring: a standard-library HTTP server with Server-Sent Events for the streaming séance, and vanilla JS and CSS with no build step. The papel picado banner is generated SVG with cut-out calaveras and flowers. There's a strict Content-Security-Policy, rate limits and size-capped GitHub clones for public hosting, and a unittest suite that builds real throwaway git repositories to test renames, reincarnations, unicode filenames and secret redaction. Why Does Open Innovation Matter? A repository's history is some of the most sensitive data a team owns: unreleased code, old credentials, people's names and emails, the real reasons things were ripped out. For most private codebases, piping all of that to a closed API is a non-starter. With an open-weight model it doesn't have to be. Run Gemma locally and the séance happens entirely on your laptop: your history never leaves it, it works offline, and nobody can change the terms or switch it off. That felt right for a tool about things that disappeared. The model is also swappable. Gemma today, any other open model tomorrow, and the ghosts keep talking. Open source is also what made this possible. Every ghost in the screenshots comes from the public history of requests, kept for fifteen years by people who chose to work in the open. Git Séance only works because their history is there to read. The Spirit of It The moment it landed for me was the first real séance. I asked the ghost of requests/async.py why it was deleted, and it quoted the actual commit message Kenneth Reitz wrote in 2012 as he removed it: > "My end came softly, though it was marked by a moment of surprise. On 2012-11-27, Kenneth Reitz removed me, leaving behind only the question, 'how was that still there?'" Then, asked for the deeper reason, it said the memory "did not survive my burial". It didn't invent one. A ghost that admits what it doesn't remember turned out to be far eerier, and far more useful, than one that makes things up. Every codebase has a graveyard. Go light a candle in yours. 🕯️🌼 Prize Categories - Best Use of Gemma: every epitaph and every séance is spoken by Gemma 4 (gemma-4-26b-a4b-it), served through an OpenAI-compatible endpoint and swappable for a local Gemma via Ollama.

You guys always ask "What's the lore?" whenever you're looking to buy a coin 👀 Now, there’s a coin with legendary lore, one that’s already in use and helping millions of dev. Just imagine what happens when CT discovers $requests 🤯 psf/requests t.co

Git seance: I let deleted functions speak from beyond the grave (with local Gemma) This is a submission for the Hacktoberfest Open-Source AI Challenge: Ghost in the Machine What I Built Every repository is a graveyard. Functions get written, argued over, shipped, and then one day a commit quietly removes them, and nobody says a word. git seance holds the funeral they never got. It walks your git history, finds functions that were deleted and never came back, and lets one of them speak through a local Gemma model: who wrote it, when it was born, and the commit that killed it. python git_seance.py --list path/to/repo # visit the graveyard python git_seance.py --summon set_http_proxy --ask "do you forgive them?" path/to/repo My personal favourite: python git_seance.py path/to/repo # summon a random ghost It's a single Python file with zero dependencies (standard library only), and it understands Python, JavaScript/TypeScript, Go and Rust definitions. Demo !git seance summoning set_http_proxy from psf/requests That's a real run on psf/requests, with gemma3:4b on my laptop's CPU through Ollama (long pauses trimmed). Its last 400 commits hold seven ghosts. The most tragic is set_http_proxy: 85 lines of carefully documented proxy handling, added to Session on 27 November 2020 and reverted the same day by its own author. Here is what it said when I asked if it forgives them (another real run, unedited): > It's… strange, this quiet. A lingering echo of code, a phantom limb of functionality. I was a helpful thing, really. I took messy proxy strings – URLs, schemes, hostnames, ports – and neatly slotted them into the requests.Session object. I was born on November 27th, 2020, courtesy of Sylvain Marie. Then, poof. November 27th, 2020 again. […] > > My advice to the living: don't prematurely prune your tools. Code {% github DrunkWiz/git-seance %} How I Built It Finding the dead. git log -p -U0 --no-merges gives every removed line in history. I parse the removed hunks, start a body at any line that looks like a definition (def, function, func, fn), and end it at the next definition at the same or lower indentation. That last rule came from a bug: the first version merged neighbouring deleted methods into one long ghost. In requests, initialize_options, finalize_options and run_tests were deleted from a setup.py command class together, and they kept coming back as a single conjoined spirit. Making sure they're really dead. A function that was moved isn't a ghost. Before summoning, git grep -w checks the current tree for a definition with the same name. If one exists, the function just moved house. Finding the birth certificate. Git's pickaxe (git log -S"def set_http_proxy") finds the commit that first added the function. My favourite bug lived here: requests later moved requests/ to src/requests/, and git's default history simplification hid every commit on the old path behind a merge. Every ghost was "born: unknown", and Gemma happily made up a birth story to fill the gap. --full-history brought the real birthday back. Speaking. The facts (name, file, length, birth, death, the killing commit's message, the final source) go into a prompt along with a system prompt that tells the model to speak as the function, to be wistful and darkly funny but never cruel, and not to invent facts. The reply streams token by token from Ollama's /api/chat with nothing but urllib, typed out like a planchette moving. An OpenAI-compatible provider is there too, for anyone who'd rather point it at a gateway. When the spirits won't come. If no model is reachable, planchette mode arranges the real facts into an epitaph with no AI at all. That came in handy: Ollama's CUDA runner crashes on my RTX 2060, so I added SEANCE_NUM_GPU=0 to run Gemma on the CPU. At 4B parameters, that's still fast enough. Tests. A unittest suite covers the diff parser on a synthetic log, the dead-or-moved check on a throwaway repo, and both streaming providers against a fake model server on 127.0.0.1, so the tests never touch the network. A ghost is an unreliable narrator, and I'd rather say so. The header line comes straight from git. Everything after it is Gemma, and despite the instructions it sometimes embellishes (in one run it insisted it had been reverted "twice"). --offline gives you only the facts. Why Does Open Innovation Matter? Because a git history is a diary. It holds names, dates, abandoned ideas, and commit messages written at the worst moments of people's weeks. A tool that reads all of that should not have to send it anywhere. With an open-weight model like Gemma running locally, the whole seance happens on your own machine: no API key, no account, no bill, and it works on a private company repo or with no internet at all. I learned this the practical way. I first tried a hosted gateway, and its free tier wouldn't serve API calls without a key. Gemma 3 4B on Ollama just worked, on a laptop CPU, offline. Open models also make the medium yours. You can read how it was made, swap it for a different one, or fine-tune it on your own team's commit messages. And open source is what gives the ghosts something to haunt: I could only summon set_http_proxy because requests keeps its whole history in the open. My Agent Session I built this with an AI coding agent (Claude Code). It ran the real seances against requests, tracked down the history-simplification and GPU bugs above, wrote the offline test suite, recorded the demo and helped draft this post. Every transcript and number here comes from an actual run. The Spirit of It Día de los Muertos isn't about fearing the dead. It's about remembering them by name. Every deleted function was somebody's afternoon. git seance puts the name, the date and the author back on the gravestone, and lets the code say goodbye. Prize Categories Best Use of Gemma: the medium is gemma3:4b, running locally through Ollama.

Ruff vs Black: is the Black Python formatter finished? Is Black, the Python formatter, finished now that Ruff exists? Ruff's formatter matches Black on over 99.9% of lines in big Black-formatted projects and ships far more often, but Black still releases. Chad and Neil check both repos and Ruff's formatter docs. Sources: - GitHub API: astral-sh/ruff and psf/black repositories, releases and commits (queried Oct 19, 2026) — astral-sh/ruff - Ruff README: README.md (main, Oct 2026) — github.com/astral-sh/ruff/blob/main/README.md - Black README: README.md (main, Oct 2026) — github.com/psf/black/blob/main/README.md - Ruff docs: The Ruff Formatter — docs.astral.sh Chad and Neil are animated characters. Voices are synthetic (text-to-speech). Neil's voice: generated with Kyutai TTS 1.6B by Kyutai (CC BY 4.0, creativecommons.org), using speaker p345 from the CSTR VCTK Corpus v0.92 by Junichi Yamagishi, Christophe Veaux and Kirsten MacDonald, The Centre for Speech Technology Research, University of Edinburgh (CC BY 4.0, doi.org). The generated audio was edited (levelled, equalised and mixed). Chad's voice: Kokoro-82M by hexgrad (Apache-2.0). Sound effects: original. Music: "Washed Up" by HoliznaCC0 (Free Music Archive), CC0 1.0 (public domain). #shorts #python #ruff ep:C04

PostHog; Black: Uncompromising Python code formatter | GitHub Curated Picks | 2026-10-25 Chapters: 00:00 2026-10-25 | GitHub Curated Picks 00:05 Pick #1 PostHog 00:19 Pick #2 Black GitHub Curated Picks reviews 2 source-verified repositories selected for developer usefulness, not popularity position. Each pick is checked against its GitHub repository, README, release evidence, and recent commit; pick numbers are editorial order. The compact card keeps rank, signal, why it matters, and next check together while the ledger preserves direct URLs and release evidence. Treat the list as an educational review surface, not software endorsement, and verify license and maintenance before adoption. Published: 2026-10-25 Review window: daily Curated repository picks: - Pick #1 PostHog | Latest commit | feat(mcp): return condition_id from feature flag read tools (reference | PostHog/posthog - Pick #2 Black | Latest commit | Recent commit verified | psf/black Chapters: 00:00 2026-10-25 | GitHub Curated Picks 00:05 Pick #1 PostHog 00:19 Pick #2 Black 00:40 Watch Next 00:47 Educational Use Only Top comment prompt: Which repository would you verify first, and what release or commit evidence matters most? Source ledger: Direct source URLs: - github.com/trending - api.github.com - PostHog/posthog - github.com/PostHog/posthog/releases/tag/hobby-lat… - github.com/PostHog/posthog/commit/8c626c87f0c85cb… - api.github.com - psf/black - github.com/psf/black/releases/tag/26.10.1 - github.com/psf/black/commit/80db630ac532f0e2f3ba3… Informational and educational purposes only. Not investment advice, product endorsement, or professional guidance. Subscriber reason: Subscribe for the daily AI, GitHub, and market board. Tomorrow watchlist: Tomorrow, check the next tagged release, recent commit, and issue-health signals for the selected projects.

Black: Uncompromising Python code formatter; Coolify; OpenRefine | GitHub Curated Picks | 2026-10-24 Chapters: 00:00 2026-10-24 | GitHub Curated Picks 00:05 Pick #1 Black 00:25 Pick #2 Coolify 00:47 Pick #3 OpenRefine GitHub Curated Picks reviews 3 source-verified repositories selected for developer usefulness, not popularity position. Each pick is checked against its GitHub repository, README, release evidence, and recent commit; pick numbers are editorial order. The compact card keeps rank, signal, why it matters, and next check together while the ledger preserves direct URLs and release evidence. Treat the list as an educational review surface, not software endorsement, and verify license and maintenance before adoption. Published: 2026-10-24 Review window: daily Curated repository picks: - Pick #1 Black | Latest commit | Fix crash on a fmt: skip header containing an inner skipped | psf/black - Pick #2 Coolify | Latest commit | fix(applications): report a failed stop instead of failing silently | coollabsio/coolify - Pick #3 OpenRefine | Latest commit | Fix absolute command URLs for path-prefixed installs (reference 7986) | OpenRefine/OpenRefine Chapters: 00:00 2026-10-24 | GitHub Curated Picks 00:05 Pick #1 Black 00:25 Pick #2 Coolify 00:47 Pick #3 OpenRefine 01:02 Watch Next 01:09 Educational Use Only Top comment prompt: Which repository would you verify first, and what release or commit evidence matters most? Source ledger: Direct source URLs: - github.com/trending - api.github.com - github.com/psf/black/blob/main/README.md - github.com/psf/black/releases/tag/26.10.1 - github.com/psf/black/commit/55996d1fb8342725c8a19… - psf/black - api.github.com - coollabsio/coolify - github.com/coollabsio/coolify/releases/tag/v4.5.0 - github.com/coollabsio/coolify/commit/e49e540ec0d6… - api.github.com - OpenRefine/OpenRefine - github.com/OpenRefine/OpenRefine/releases/tag/3.1… - github.com/OpenRefine/OpenRefine/commit/d66a10ee5… Informational and educational purposes only. Not investment advice, product endorsement, or professional guidance. Subscriber reason: Subscribe for the daily AI, GitHub, and market board. Tomorrow watchlist: Tomorrow, check the next tagged release, recent commit, and issue-health signals for the selected projects.

Black: an interrupted check is not a completed check: source review Black: an interrupted check is not a completed check — Official Python code formatter repository and README, live and active. Do your checks distinguish interruption from success? Review the source before trusting an interrupted run. Sources: psf/black black.readthedocs.io black#5541 #python #black #opensource

Unstructured; Supabase: Postgres development platform; yt-dlp | GitHub Curated Picks | 2026-10-23 GitHub Curated Picks reviews 14 source-verified repositories selected for developer usefulness, not popularity position. Each pick is checked against its GitHub repository, README, release evidence, and recent commit; pick numbers are editorial order. The compact card keeps rank, signal, why it matters, and next check together while the ledger preserves direct URLs and release evidence. Treat the list as an educational review surface, not software endorsement, and verify license and maintenance before adoption. Chapters: 00:00 2026-10-23 | GitHub Curated Picks 00:05 Pick #1 Unstructured 00:30 Pick #2 Supabase 00:44 Pick #3 yt-dlp 01:01 Pick #4 Langchain 01:27 Pick #5 Awesome Mac 01:42 Pick #6 Trivy 01:56 Pick #7 Vite 02:14 Pick #8 Jellyfin 02:32 Pick #9 Black 02:51 Pick #10 Coolify 03:13 Pick #11 Doris 03:24 Pick #12 Onnxruntime 03:36 Pick #13 Fluentui 03:49 Pick #14 Server Source ledger: github.com/trending api.github.com github.com/Unstructured-IO/unstructured/blob/main… github.com/Unstructured-IO/unstructured/commit/49… github.com/Unstructured-IO/unstructured/releases/… api.github.com github.com/supabase/supabase/blob/master/README.md github.com/supabase/supabase/commit/2193f2acdf8ef… api.github.com github.com/yt-dlp/yt-dlp/blob/master/README.md github.com/yt-dlp/yt-dlp/commit/9b58cb33d0cd3e823… api.github.com langchain-ai/langchain github.com/langchain-ai/langchain/commit/b84fa61e… github.com/langchain-ai/langchain/releases/tag/la… api.github.com github.com/jaywcjlove/awesome-mac/blob/master/REA… github.com/jaywcjlove/awesome-mac/commit/965f263f… api.github.com github.com/aquasecurity/trivy/blob/main/README.md github.com/aquasecurity/trivy/commit/0231990f702f… api.github.com github.com/vitejs/vite/blob/main/README.md github.com/vitejs/vite/commit/a236886026c3a5de068… api.github.com github.com/jellyfin/jellyfin/blob/master/README.md github.com/jellyfin/jellyfin/releases/tag/v12.3 api.github.com github.com/psf/black/blob/main/README.md github.com/psf/black/commit/f33c3e3c66263d4a3a0e1… api.github.com coollabsio/coolify github.com/coollabsio/coolify/commit/0b2e931a4258… api.github.com github.com/apache/doris/blob/master/README.md github.com/apache/doris/commit/6e5a8929fbaba2ed2a… api.github.com microsoft/onnxruntime github.com/microsoft/onnxruntime/commit/fe7700a7e… api.github.com microsoft/fluentui github.com/microsoft/fluentui/commit/ea1a99bf2bc5… api.github.com nextcloud/server github.com/nextcloud/server/commit/fc9b07d9591f1f… Unstructured-IO/unstructured supabase/supabase yt-dlp/yt-dlp jaywcjlove/awesome-mac aquasecurity/trivy vitejs/vite jellyfin/jellyfin psf/black apache/doris Informational and educational purposes only. Not investment advice, product endorsement, or professional guidance.

Node2Shell Reaches Python: If Brotli Is Installed, requests Asks Servers for br - Book: RAG Pocket Guide - The series: Pocket Guides for Developers — 8 short books on agents, RAG, prompts, observability, events, databases and system design — the whole series - My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub --- You never imported brotli. You may still be running it. If the package sits anywhere in your Python environment, urllib3 adds br to the Accept-Encoding header it builds, and requests sends that header on every call by default. Every server you fetch from is then invited to answer in Brotli, and your process decodes the reply. That matters this week. The Brotli decoder bug behind Node.js's "Node2Shell" fix, CVE-2026-111497, lives in Google's C library, which Node only bundles. On October 22 GitHub published an advisory titled "Out-of-bounds write in the Brotli decoder ("Node2Shell") also affects the PyPI Brotli package". On October 23, Aikido called it "HTTP2Shell" and spelled out what that means for Python HTTP clients. What's new since the Node.js fix The bug was reported by OpenAI's Codex Security team, per the credits in the Node.js security release, which shipped fixes in 22.23.4, 24.22.1 and 26.12.1. Node's advisory describes it as malformed compressed input that writes "past the end of an internal decoder buffer", which "can lead to a crash, disclosure of process memory, or remote code execution." Imperva showed code execution against an official Node.js build, as The Hacker News reported. The new part is the Python side. The GitHub advisory lists two PyPI packages: | Package | Affected | Fixed | |---|---|---| | brotli | >= 1.0.3, < 1.2.1 | 1.2.1 | | brotlicffi | >= 1.0.3, < 1.2.1.0 | 1.2.1.0 | The advisory text also names 1.0.10 and 1.1.1 as fixed releases on the older branches, if you can't move to 1.2.x yet. It rates the bug Critical, CVSS v4 9.2. Brotli 1.2.1 and brotlicffi 1.2.1.0 both list October 22 on PyPI. The brotlicffi changelog says the release "remediates CVE-2026-111497, an out-of-bounds write." Be precise about what is proven. Code execution has been shown on Node.js. Aikido's write-up says code execution was not pursued in the Python extension, and points out that the decoder code is the same one exploited against Node. Treat it as the same bug in the same C code, reachable from Python, with no public Python exploit yet. !Editorial illustration of a black Python snake coiled around an HTTP response envelope, sealed with a cracked burnt-orange wax seal, on a cream background The C decoder is shared, so the bug travels with it into every runtime that bundles Brotli. Why you can be exposed without importing it The risk sits in a dependency you may not know you have. urllib3's source tries import brotlicffi, then import brotli, and if either works it appends ,br to its ACCEPT_ENCODING. requests builds its DEFAULT_ACCEPT_ENCODING from that same urllib3 helper. urllib3's docs say Brotli is "supported by urllib3 if the Brotli package or brotlicffi package is installed". aiohttp's docs say the same: "just install Brotli or brotlicffi." Aikido lists urllib3 and requests, httpx with its brotli extra, aiohttp, Scrapy, and anything built on those clients. It also notes that your code doesn't have to import Brotli itself to be affected. You can see what your client asks for in two lines: import requests print(requests.utils.default_headers()["Accept-Encoding"]) If br is in that string, every server your code calls is invited to send Brotli. A server you control is low risk. A URL a user pasted, a webhook target, or a page your crawler found is not. The outbound path AI apps lean on A RAG ingestion job fetches documents from URLs it was given. An agent's web-fetch tool downloads whatever page the model decided to read. A scraper follows links. In all three, the other end of the connection is chosen by someone else, and the response body goes straight through your HTTP client's decoder. That is the outbound exposure Strobes lists for Python: urllib3/requests, aiohttp and httpx, whenever a Brotli package is installed. Inbound matters too if a Python service decodes Brotli request bodies, but outbound fetching of untrusted URLs is the path many AI pipelines run all day. !Editorial illustration of a black robot arm reaching out of a laptop to pull a document from a web of links, one link glowing burnt orange as a hidden hazard, cream background, flat vector Agents, crawlers and RAG loaders fetch pages someone else picked. That is the outbound path to patch first. Check and fix Start with what is installed, in each environment and each image. This uses only the standard library: from importlib.metadata import version, PackageNotFoundError for pkg in ("Brotli", "brotlicffi"): try: print(pkg, version(pkg)) except PackageNotFoundError: print(pkg, "not installed") Aikido's checks cover the rest: who pulls it in, what your lockfiles pin, and what is inside a built image: pip show Brotli brotlicffi pipdeptree -r -p Brotli grep -i brotli poetry.lock uv.lock requirements*.txt docker run --rm <image> pip show Brotli brotlicffi The fix is the upgrade: pip install -U "Brotli>=1.2.1" pip install -U "brotlicffi>=1.2.1.0" brotlicffi 1.2.1.0 also starts rejecting trailing bytes after a complete Brotli stream, per its changelog, so run your fetch tests after the bump. Then update the lockfile, rebuild containers and wheels, and redeploy. A running process keeps the old decoder loaded until it restarts, which Strobes calls out. If you can't upgrade today, Aikido's workarounds are to uninstall Brotli and brotlicffi (and drop extras like httpx[brotli]), or reject br in Content-Encoding before any decoder runs. It warns that removing br from Accept-Encoding is not enough on its own, and that uninstalling can cause errors with servers that send Brotli regardless. The reason is in urllib3's response docs: with decode_content on, it decodes "based on the 'content-encoding' header", which is the header the server picks, not the one you asked for. Beyond Python and Node The same C code is bundled in a lot of places. As of October 24, Strobes, citing a public tracker, lists Bun 1.4.4, Chromium and Firefox as fixed. It lists bundled copies in .NET, PHP, Ruby, DuckDB and ClickHouse as still waiting on fixes, and the Rust, Java, JavaScript and C# ports as not affected. Aikido adds Envoy 1.40.0, 1.39.3, 1.38.6 and 1.37.8, and Istio 1.29.9, 1.30.6 and 1.31.2, as fixed releases. The fix commit landed upstream in February 2026 without a security label, per Strobes. Aikido says OpenAI found the flaw in February. The patched code sat in Brotli's source for months before anyone shipped it as a security release. A dependency scanner can only flag what an advisory names, so through that whole stretch no scanner knew the fix mattered. --- If this was useful If you run a RAG pipeline, the loader that fetches documents is attack surface. The RAG Pocket Guide covers ingestion, chunking and reranking for production systems, the parts that sit right after that fetch. It's one of the 8 short books in the Pocket Guides for Developers series, which also covers agents, prompts, observability, events, databases and system design. I also build Hermes IDE, so weigh this with that in mind: it gives each agent task its own branch and worktree, which is a tidy place to let Claude Code or Codex bump Brotli and run your tests before you land it. It's source-available, runs on macOS, Windows and Linux, and is on GitHub.