Topics covered in this episode:
Watch on YouTubeAbout the show
Connect with the hosts
Calvin #1: PHP wasn’t the only problem last week
- Three security incidents in one week, each at a different layer: CA trust (eMudhra), the release pipeline (LiteLLM) and a C decoder (Brotli). All three have fixes released.
- eMudhra CA: the keys of a compromised eMudhra intermediate CA are now distrusted by CPython. 3.15.1, 3.14.9 and 3.13.17 shipped Oct 21. 3.15.2, 3.14.10, 3.13.18, 3.12.16 and 3.11.18 followed Oct 26 (CVE-2026-115557) and also fix a tarfile filter bypass. Python's post says pip operations are safe even before pip is upgraded.
- eMudhra, tooling: pip 26.2.2 bundles certifi 2026.10.19, which removes the root. uv 0.13.4 (GHSA-hq85-5cpj-mr62) and 0.13.5 (rustls-webpki 0.103.16) are the uv fixes. After upgrading uv, run uv python upgrade. Existing venvs need pip upgraded by hand, and the 3.9 and 3.10 builds still bundle a pip that trusts the root.
- Anyone holding those intermediate keys can mint certificates for any domain that an unpatched client will accept as valid.
- That enables man-in-the-middle attacks: reading or altering HTTPS traffic without a certificate warning.
- The risk is highest where the attacker can sit on the network path, such as hostile Wi-Fi, a compromised router or ISP, or a cloud network position.
- For Python specifically, the exposed traffic would be package downloads from PyPI, API calls with credentials or tokens, and webhooks. A tampered package download is the worst case.
- Containers and old venvs that nobody rebuilds are where this lingers. uv says its Python 3.9 and 3.10 builds still bundle a pip that trusts the root, and existing venvs don't pick up the fix automatically.
- LiteLLM 1.107.0: malicious wheels hit PyPI on Oct 21. All seven wheels were live from about 11:40 to 13:23 UTC, with roughly 49k downloads. The Docker images were also infected. It's the second LiteLLM compromise this year, after 1.82.7 and 1.82.8 in March.
- LiteLLM payload: cook.pth runs on every Python start, so nothing has to import litellm. It steals SSH, cloud, browser, CI and AI-tool credentials, and an hourly loader runs remote code. The clean pin is litellm==1.106.4. Kill the loader first, rebuild rather than repair, then rotate everything the host could reach.
- LiteLLM root cause: a master key committed to a public repo on May 27 was never revoked. On Oct 10 it yielded an org owner's GitHub CLI token. The attacker then changed the trusted release workflow to build from a lookalike Berri-AI/litellm repo. BerriAI's first explanation (tokens in logs) was wrong, and the Oct 23 report supersedes it.
- Broccoli2Shell: CVE-2026-111497 is an out-of-bounds write in Google's Brotli C decoder. It affects the Python Brotli and brotlicffi packages 1.0.3 through 1.2.0(.x). Upgrade to Brotli 1.2.1 or brotlicffi 1.2.1.0. The CVE was published Oct 22 and rated 9.2 Critical by GitHub.
- Broccoli2Shell workaround: if you can't upgrade, uninstall both packages. urllib3, requests and aiohttp then fall back to gzip and deflate. Also reject Content-Encoding: br request bodies at the proxy or WAF.
Sources - https://blog.python.org/2026/10/python-3152-31410-31318-31216-31118/
- https://www.stepsecurity.io/blog/litellm-1-107-0-compromised-pypi-backdoored-wheels-credential-stealer
- https://broccoli2shell.com/
Michael #2: chameleon-rs
- Chameleon templates, much faster than before (up to 70x faster on start)
- Modernized: A Rust engine that runs your Chameleon templates unchanged with async rendering, partials (think HTMX), Markdown
- Built-in framework support: Flask, Quart, FastAPI, Starlette, Pyramid, Robyn and Litestar integrations.
- A compatibility shim for testing out quickly:
chameleon_rs.compat.install() - AI agent support via docs (every doc page has a .md extension variant, eg FastAPI docs) and the skill is installable or downloadable.
- Byte-for-byte identical on every page for talkpython.fm and training.talkpython.fm
- Passes 100% of the unit tests of the original chameleon project. See compatibility page.
- Natively supports my chameleon-flask, fastapi-chameleon, and chameleon-partials libraries.
- Swapping Talk Python Training to chameleon-rs made it 20% fast (end-to-end, not just template rendering)!
Calvin #3: Bringing uv and ty together
- Status: Astral (Sara Sklenka, Oct 13) announced "an experimental integration between uv and ty, available in preview." They ask for feedback, and say "in parallel, we're continuing toward ty's stable release."
- uv check: a new uv command that prepares the project environment, installs dependencies and runs ty. Flags are --package [HTML_REMOVED], --all-packages and --script example.py. Ruff support is planned, so lint and type check would run in one command.
- Lockfile pinning: uv check uses the ty version recorded in your lockfile. Developers and CI therefore share one ty version without separate pins.
- PEP 723 scripts: ty reads inline script metadata and uses uv to build an environment per script. Each script is checked against its own declared dependencies, even when they differ from the project's. In the editor, saving a script syncs it with uv.
- Enabling it: running uv check turns it on automatically. In VS Code, install the astral-sh.ty extension and set "ty.experimental.useUv": "on". On the command line, run TY_UV=scripts ty check.
- Opt-in: the post says automatic environment setup "is currently opt-in" because installing dependencies can execute third-party code. Astral plans to enable script support by default over time, and automatic setup for standard projects.
- Under the hood: it's powered by uv workspace metadata. uv 0.13.6 (Oct 26) changed that preview output to nest each module's owners in an object, so anything parsing the old flat structure breaks.
- Versions: it needs uv 0.12.3+ and ty 0.0.76+. Current releases are past both (uv 0.13.6, ty 0.0.92 on Oct 26), though I couldn't confirm 0.0.76's exact date.
- Next: Astral says it's working on checks that combine uv's dependency knowledge with ty's code analysis, such as detecting unused dependencies.
- Also credit to listener Sky Kasko. :)
Michael #4: Stlite runs Streamlit apps entirely in the browser
Streamlit is a very unique way to create data-driven dashboards. Stlite is a WebAssembly port of Streamlit built on Pyodide, so a Streamlit app runs completely in the visitor's browser with no Python server behind it. It ships as three packages (@stlite/browser for web pages, @stlite/desktop for offline desktop apps, @stlite/react for embedding in React), plus Stlite Sharing, a hosted editor for trying apps online. The project has been active since 2022 and is now at 0.85.1 with sponsorship from Streamlit/Snowflake and TestMu AI.
- A Streamlit app becomes static files you can host anywhere, the same story JupyterLite tells for notebooks.
- Deployment shrinks to a script tag or a single HTML file; the server only serves static assets and never runs Python.
- It patches requests and urllib through pyodide-http and supports pyfetch, so most existing HTTP code keeps working.
- Real limitations: time.sleep is a no-op in favor of asyncio.sleep, asyncio.run breaks, and packages with unported binary extensions cannot install.
- Files default to ephemeral memory, but IDBFS mountpoints persist data across reloads in the browser's IndexedDB.
- A SharedWorker mode lets multiple apps share one Python runtime to cut memory, at the cost of shared state between apps.
- The @stlite/desktop bundler turns an app into an offline desktop executable, demonstrated converting Streamlit apps to .exe files.
Extras
Calvin:
Joke: captcha: too real!
