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

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:
1. 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.
2. 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.
3. 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.
4. 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.
5. 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?