Topics covered in this episode: Lock the Ghost Fence for Sandboxing MALUS: Liberate Open Source Harden your GitHub Actions Workflows with zizmor, dependency pinning, and dependency cooldowns Extras Joke Watch on YouTube About the show Sponsored by us! Support our work through: Our courses at Talk Python Training The Complete pytest Course **Patreon SupportersConnect with the hosts** Michael: @mkennedy@fosstodon.org / @mkennedy.codes (bsky) Brian: @brianokken@fosstodon.org / @brianokken.bsky.social Show: @pythonbytes@fosstodon.org / @pythonbytes.fm (bsky) Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Monday at 11am PT. Older video versions available there too. Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it. Michael #1: Lock the Ghost The five core takeaways: PyPI "removal" doesn't delete distribution files. When a package is removed from PyPI, it disappears from the index and project page, but the actual distribution files remain accessible if you have a direct URL to them. uv.lock uniquely preserves access to ghost packages. Because uv.lock stores direct URLs to distribution files rather than relying on the index API at install time, uv sync can successfully install packages that have already been removed, even with cache disabled. No other Python lock file implementation tested behaved this way. This creates a supply chain attack vector. An attacker could upload a malicious package, immediately remove it to dodge automated security scanning, and still have it installable via a uv.lock file, or combine this with the xz-style strategy of hiding malicious additions in large, auto-generated lock files that nobody reviews. Removed package names can be hijacked with version collisions. When an owner removes a package, the name can be reclaimed by someone else who can upload different distribution types under the same version number, as happened with "umap." Lock files help until you regenerate them, then you're exposed. Your dependency scanning needs to cover lock files, not just manifest files. Scanning only pyproject.toml or requirements.txt misses threats embedded in lock files, which is where the actual resolved URLs and hashes live. Brian #2: Fence for Sandboxing Suggested by Martin Häcker “Some coding platforms have since integrated built-in sandboxing (e.g., Claude Code) to restrict write access to directories and/or network connectivity. However, these safeguards are typically optional and not enabled by default.” “JY Tan (on cc) has extracted the sandboxing logic from Claude Code and repackaged it into a standalone Go binary.” Source code on GitHub: https://github.com/Use-Tusk/fence Related: Simon Willison lethal trifecta for AI agents article from June 2025 Claude Code Sandboxing Michael #3: MALUS: Liberate Open Source via Paul Bauer The service will generate the specs of a library with one AI and build the newly licensed library using the specs with another AI circumventing the licensing and copyright rules. AI that has not been trained on open source reads the docs and API signature, creates a spec. Another AI processes that spec into working software. Is it a real site? Are they accepting real money, or are they just trying to cause a stir around copyright? Brian #4: Harden your GitHub Actions Workflows with zizmor, dependency pinning, and dependency cooldowns Matthias Schoettle Avoid things like this: hackerbot-claw: An AI-Powered Bot Actively Exploiting GitHub Actions - Microsoft, DataDog, and CNCF Projects Hit So Far Extras Brian: GitHub is asking to spy on us, that’s nice Michael: Michael’s new SaaS for podcasters: InterviewCue DigitalOcean’s Spaces cold storage for infrequently accessed data Minor issue about my fire and forget post, was a latent bug? Fire and Forget at Textual follow up article Joke: Can you?
Analysis: done · source seed