> Security notice: Upgrade certifi, pip, and uv in response to CA certificate incident
Blimey PIP is affected? That's bad. I feel like that should have been bigger news?
murderfs · 2026-10-24 11:51:05 UTC
Pretty sure that's the eMudhra "private key is 4" issue.
skeledrew · 2026-10-24 12:34:26 UTC
Because pip uses it's own certificate bundle, so even if you fix the system itself pip still needs its own upgrade to handle the eMudhra episode.
tetha · 2026-10-24 13:56:28 UTC
And strictly speaking you cannot trust the pip upgrade of pip with the vulnerable cert in the trust store due to certifi, which you also cannot upgrade safely with pip for the same reason. All of these are at one out of two compromises from being MITM'd during the upgrade.
So strictly we have to burn everything python to the ground and reinstall entirely.
saltcured · 2026-10-24 16:42:14 UTC
Heh. This is part of why I always preferred getting my python runtime and all these core libs from my linux distro packager. But python die-hards look at me like I'm insane when I suggest this.
Even in today's LLM-addled world, I still think it's a better tradeoff for smaller system/site operators. Get the distro-level testing and regular auto-patching, rather than telling yourself it is a good idea to "freeze" your python world at the pace of your slowest app/system integrator.
It's the same reason I think docker is an anti-pattern for these small groups. You really cannot safely use these strategies to bake an image and divorce yourself from the maintained distro layer unless you are going to adopt CI/CD that does the same thing. Keep tracking all these patches to the entire runtime with all the dependencies, rebuild, re-test, and redeploy.
It's total cargo culting to adopt the freeze/image techniques and just abandon apps in place as if that is robust!
But, it's also more than just automatically updating everything. There is an editorial aspect to distro management to help secure the supply chain to your app. Most smaller orgs cannot feasibly do this as well as the regular linux distro maintainers. Some large orgs can probably do it better, but that doesn't matter if you aren't doing it large org style with dedicated security folks tracking all this against well-developed policies and procedures...
graemep · 2026-10-24 19:41:25 UTC
I agree about getting libs (binaries especially) from my distro, and it generally seems to be regarded as the "wrong thing to do". Freezing anything that might mean you get security updates slower seems to be a mistake to me.
zahlman · 2026-10-25 05:42:46 UTC
> But python die-hards look at me like I'm insane when I suggest this.
They have a point. The distro is only carrying a small fraction of what's available on PyPI, and will have out-of-date versions that may lack security patches (and for projects like yt-dlp, are highly unlikely to work at all). Realistically they aren't applying security backports; there would rarely be a reason not to just use the new version, and the resources just aren't there for that scale of patching anyway.
Further, pip will interfere with your system package manager's tracking of the system environment (PEP 668), and any attempt you make to install from .deb/.rpm/etc. to a virtual environment is a hack at best. Maybe you could symlink individual package folders to the system environment while installing a superset, but ugh. Oh, and if you're a developer (like most "Python die-hards" are) then this isn't very helpful, as you aren't testing the installation of your package the way that your users will do it.
saltcured · 2026-10-25 16:44:40 UTC
The mitigation is to ignore nearly all that stuff in PyPI, realizing it is barely a step up from copy-pasting out of stack overflow. Same goes for, e.g. python-whatever RPMs that look like they were drive-by contributions.
So your trusted base is the Python runtime and maybe a few choice libraries that actually have engaged package management. Sadly, it is a trap to think you can put things on the internet as a small player by leveraging lots of third-party stuff, when you don't have the resources to actually maintain that large dependency base.
This also may mean you want a base OS like Fedora and not some crusty "enterprise" variant that tries to bundle a frozen Python from 15 years ago. This is getting a little better in recent years, with some enterprise platforms having optional package streams for parallel install of newer runtime versions, etc.
Edit to add: on the Fedora-derived platforms, pip doesn't really interfere much anymore. The platform python-* RPMs go into /usr/lib/... while pip installs into /usr/local/lib/... or your ~/.local/lib/... hierarchy. The only mysterious behavior you get is if you manage to install in both places and then you have to understand the path search order. Just like if you do strange things with user and virtual environments.
zbentley · 2026-10-25 16:59:40 UTC
Eh, it's a personal choice and a not unreasonable position to take, but there are a lot of things on PyPi that aren't packaged by e.g. Debian. Database clients, immensely popular frameworks, scientific computing libraries ...
Basically once you leave the realm of the 5-10 most popular building blocks in an area (which OS packagers do distribute), you're still left with plenty of packages that have 10ks+ of users, sane maintainer/security/ownership models, and code that would be very difficult to just copy-paste a la stackoverflow (e.g. native/compiled deps with complex wheel build tooling).
saltcured · 2026-10-25 17:17:03 UTC
Yes, that's why I left wiggle room for a few choice packages you track yourself.
What isn't really tenable for a small team is to drag in scores to hundreds of different third-party packages and rely on them all when you have no staff allocated to really evaluate and monitor so much upstream stuff.
aftbit · 2026-10-24 16:52:42 UTC
Or - you can just upgrade pip with a SHA hash pin, or set the magic env vars to use the system bundle.
You do need to be careful about creating new venvs with the old version of pip bundled in ensurepip in older Python releases. `uv` kindly patches that to newest pip, but not every Python binary does.
Good to know. Does the first invocation recompute and check the hash of the wheel locally afterwards to ensure integrity?
aftbit · 2026-10-24 19:47:29 UTC
Yep! I tested it with my own vibe-coded MITM proxy that hijacks pypi installations, which I created for ~$0.30 spend on DeepSeek API.
$ python -m pip --no-cache install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"
Collecting pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70
Downloading pip-26.2.2-py3-none-any.whl (1.8 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.8/1.8 MB 570.0 MB/s 0:00:00
ERROR: THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE. If you have updated the package versions, please update the hashes. Otherwise, examine the package contents carefully; someone may have tampered with them.
pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70 from https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70:
Expected sha256 fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70
Got 8c448177668e735cdde7d6178694b90c084ba18559348cc394c4b1546eeec89c
The second one works too:
$ PIP_USE_DEPRECATED=legacy-certs PIP_CERT=/etc/ssl/certs/ca-certificates.crt python -m pip install --no-cache --upgrade "pip>=26.2.2"
WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
WARNING: Retrying (Retry(total=3, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
WARNING: Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
Could not fetch URL https://pypi.org/simple/pip/: There was a problem confirming the ssl certificate: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082) - skipping
ERROR: Could not find a version that satisfies the requirement pip>=26.2.2 (from versions: none)
ERROR: No matching distribution found for pip>=26.2.2
As compared with a naive installation through the proxy:
Oh nice. Then I have to thank you for a possible non-horrible upgrade path. If you were close by, I'd invite you for some icecream or a round of pool :)
aftbit · 2026-10-27 01:42:55 UTC
It's safe to upgrade with python 3.12.16 now:
# docker run --rm --net=host --add-host=pypi.org:127.0.0.1 --add-host=files.pythonhosted.org:127.0.0.1 python:3.12.16-slim-trixie pip install six
WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate rejected (_ssl.c:1011)'))': /simple/six/
zahlman · 2026-10-27 06:47:36 UTC
Yep. Per the main thread on the Python forums (https://discuss.python.org/t/information-for-python-users-re...), this now happens even with the outdated pip because the built-in `ssl` module has been patched to reject it. The relevant commit is https://github.com/python/cpython/commit/7dd8b4736a1419750b9... , featuring a rather amusing workaround for security scanners that might mistake the blacklisted certificates (included for testing purposes) for "leaked" certificates accidentally included in a source package.
From code comments, because I found it interesting:
* This is an extraordinary measure and last line of defense. Removing trust is
* primarily the job of the platform root store. This list only blocks keys while
* that update is still propagating to the OS, container images, or root CAs
* bundled in Python packages. The threshold for adding an entry is very high.
*
* See https://github.com/python/cpython/issues/160040 for the eMudhra discussion.
As a Mint 22.x user, I wonder if and when Debian or Ubuntu will pick up the change and release another patch for the system Python (basically, to my understanding, a base of 3.12.3 with security patches from other patch releases backported). Since they've already updated ca-certificates it might not seem necessary, at least as long as the pip package gets updated (although I don't use that anyway).
BTW, I think I saw your comments in other places about the 30-cent vibe-coded MITM demo proxy, unless someone else had the same idea. Thanks for helping educate.
Edit: apparently (https://discuss.python.org/t/avoiding-compromised-certificat...), the relevant Debian and Ubuntu packages already patch the distro-provided pip to enforce using the system certificates. (Indeed, `ca-certificates` is listed as "Depends" for the pip package, rather than "Recommends".) But maybe they'll still be interested in the key blocking, on defense-in-depth principles.
zahlman · 2026-10-25 05:47:13 UTC
I had a pretty fun time with it myself. Rather than a system package for pip, or the `ensurepip`-provided one, I've been using the copy managed by pipx. I had to:
* Update system certificates
* Locate that pip and directly invoke it to self-update with hash pinning, rather than going through pipx
* Fix a few stray venvs that contained their own pip
* Use the fixed pipx to update uv (although I guess the uv self-update should work even for a pipx-installed copy?)
The legacy-certs hint is neat. I did it the first way but would rather not have since I'm on Mint.
zahlman · 2026-10-25 05:32:29 UTC
> All of these are at one out of two compromises from being MITM'd during the upgrade.
This is not true; pip supports hash pinning, so an attacker would have to be able to defeat SHA256 as well (or compromise both the official Python discussion forum and PyPI itself, so as to forged the published hash). Other hashes can also be used. Instructions are provided on the Python discussion forum to self-upgrade pip with hash pinning: https://discuss.python.org/t/information-for-python-users-re...
steve1977 · 2026-10-24 15:43:33 UTC
Python certificate handling is a hot mess, even by Python standards.
zahlman · 2026-10-25 05:48:34 UTC
Commentary like this adds nothing to the discussion and is simply provocative. Please don't.
steve1977 · 2026-10-25 08:38:30 UTC
Provocative of what? Thinking about the issues that Python has? Why would that be a problem?
It IS a mess and it's causing problems again and again in real life. And it is particularly bad with Python. I don't see why this should not be pointed out.
zahlman · 2026-10-25 05:25:45 UTC
~~Recent versions of pip use `truststore` by default to access the system's certificates, only relying on the vendored `certifi` as a fallback or if explicitly directed.~~
Users of uv who have already updated their system certificates can use:
UV_SYSTEM_CERTS=true uv self update
tetha · 2026-10-24 10:55:07 UTC
Well at least we know about it while or before the giant patch effort for everything else goes on. Just put it onto the pile.
Who turned on hard mode this week?
loloquwowndueo · 2026-10-24 11:37:10 UTC
Nah man. We were on casual mode all along. This is the new normal.
netsharc · 2026-10-24 11:13:04 UTC
Well, whoever picked the name HTTP2Shell certainly didn't use any intelligence, artificial or genuine.
It's so meaningless, broad and undescriptive of the actual issue. No it probably doesn't affect an HTTP server with nothing else behind it, so why is HTTP being blasted?
You might as well call it Exploit Pro Max...
CharlieDigital · 2026-10-24 11:17:52 UTC
Feels like the goal was sensationalism.
cromka · 2026-10-24 23:17:06 UTC
Something that OpenAI would coin. Just like Anthropic did with Mythos.
reddozen · 2026-10-24 11:51:08 UTC
The author clearly used super intelligence.
Stitch4223 · 2026-10-25 01:30:33 UTC
You and I, my friend, are the only ones in this thread not being sent to work in the glitter mines of south Arkansas as enemies of God's Country. SI has the best names, other intelligence is vastly inferior, using it is worse than many schisms of -isms combined.
techpression · 2026-10-24 12:00:39 UTC
I immediately thought HTTP/2 was having a bad day somehow. Might I suggest Software2Shell to be less confusing.
CharlieDigital · 2026-10-24 12:14:41 UTC
Specifically Brotli2Shell
photios · 2026-10-24 12:50:09 UTC
google2shell would have been nice :D
anilakar · 2026-10-24 13:23:38 UTC
Alt-tabbing from browser to terminal and back has always felt exhausting. Nice.
devsda · 2026-10-24 14:20:51 UTC
With ad served malware, this wouldn't be the first time though :)
groundzeros2015 · 2026-10-24 14:20:12 UTC
All these names are silly. It's just marketing.
sigmarule · 2026-10-24 14:52:35 UTC
There are levels of silliness, and this has achieved a new one.
cowlevel · 2026-10-24 14:32:42 UTC
Actually it does, if the server is willing to decompress POST bodies.
croes · 2026-10-24 14:43:35 UTC
Brotli bodies, so Brotli2Shell
SkiFire13 · 2026-10-25 07:09:53 UTC
And only those using Google's Brotli implementation.
jwilk · 2026-10-25 09:37:46 UTC
What are the other implementations?
Rapzid · 2026-10-24 14:39:34 UTC
I think we've all seen where an LLM names a session, issue, or PR based on its early understanding and fails update it later.
AI isn't being asked to review the title, and it doesn't have experience or think, so of course it's not going to flag it.
No human reviews anything anymore so of course they aren't going to catch it.
Edit: AI for as good as it is at "writing" is terrible at writing and particularly at naming things. I had an AI name a client OpenAICompatibleEmbeddingClient. "Brooooo.. I think "compatible" is implied, who names stuff like that?!"
rmaxdev · 2026-10-24 17:58:13 UTC
LLM-based AI is a synthesis of human observed behavior
PalmPilotProMax · 2026-10-24 23:58:09 UTC
But does it bring synergy with our current paradigm?
lifeisloving · 2026-10-24 20:01:58 UTC
Descriptive type names are a good thing. Id argue that one isnt that bad, but llms do take it to another level sometimes.
rafram · 2026-10-24 20:41:23 UTC
That means that it supports other services with OpenAI-compatible embeddings APIs (not just OpenAI's own API). Seems reasonable!
Rapzid · 2026-10-25 01:56:11 UTC
Fortunately I didn't ask it for excuses and so it didn't give them like a pedantic junior on the spectrum.
Which they will happily do if you ask them "why" they did something. 100% they will give their best "well actually" impression.
ketzu · 2026-10-25 09:31:12 UTC
`OpenAICompatible` is also a widely used phrasal description of a part/version of the OpenAI API that is supported by quite a lot of endpoints.
I've seen that used as a description for 2years or so.
rererereferred · 2026-10-24 14:45:43 UTC
Just call it CVE-2026-111497. More accurate and much easier to remember and to talk about with your boss.
N19PEDL2 · 2026-10-24 15:16:55 UTC
Or EUVD-2026-108169.
kevincox · 2026-10-24 22:50:07 UTC
I can maybe remember CVE-2026. But there is no way I can remember 6 random digits.
ygjb · 2026-10-24 23:58:11 UTC
Yeah, because the six number chunk is near the limit of recall. Don't remember CVE-2026 since the year and CVE can be reconstructed from time memory. You know it came up this year. Remember that vuln 111-497 (as two chunks) came out this year, and remembering two short chunks is easier.
latexr · 2026-10-25 14:26:22 UTC
I don’t know why you’d want to remember the number, but this one seems easy if you know some memory techniques.
> Remember that vuln 111-497 (as two chunks)
Good first step. Remember it’s two sets of three numbers. The first set is all ones, meaning the first three numbers are 1, then the fourth number is 4, then you add five for the next one (9), then you have to remember to subtract two (7)¹.
May sound silly, but I bet some of you have already memorised it from that alone. Being a slightly convoluted by still logical set-by-step helps with recollection.
¹ Lot of different ways to go about that, like remembering that the first set was three of one so “two was left out”.
vanschelven · 2026-10-25 12:31:33 UTC
Fun fact: not even Google can remember that number on the first try, apparently:
It looks like marketing HTTP2Shell seems to appeal to everyone that uses HTTP, while Brotli2Shell might not wake up people that know what it is.
Now, whether it's warranted or not, that's another matter, but they know how to appeal for maximum awareness/interaction.
hulitu · 2026-10-25 11:01:04 UTC
> while Brotli2Shell might not wake up people that know what it is.
And, most of all, is damaging to Google, which are the master of software engineering. /s
super256 · 2026-10-25 00:40:34 UTC
A better name is Konduktsemmel, which is a bread roll (Semmel) which you eat on a funeral (Kondukt) in Austria. Fits to Brotli, doesn't it?
(Actually you eat cake and drink coffee on a funeral, but it's still called like that in some parts of Austria.)
cowlevel · 2026-10-25 13:55:08 UTC
A better name is Fred, because
vanschelven · 2026-10-25 11:34:48 UTC
Should have definitely been Brotli2Shell, but Google ingeniously managed to dodge that bullet by having NodeJS come out with a fix before they did (others might call that accidental exposure), and then barely communicating about that with the broader community once they finally did. Here's a timeline of events[0] and here's me more broadly complaining about Google's stance[1]
I mean...who cares? It's actually kind of strange that your comment got others talking about AI naming things.
SQL Slammer didn't actually slam anything, and applied to a single vendor among many SQL providers. Heartbleed didn't make anyone's heart bleed...I mean, at least directly. Shellshock only impacted a single shell environment, again among many. Log4Shell impacted a single logging implementation, among many. Spectre and Meltdown...I mean, who would think that related to CPU cache side channels?
These are just dumb names for people to share in referring to something. Seems silly and like a waste of time to spend effort getting upset about them.
davedx · 2026-10-24 11:32:05 UTC
Honestly it's time to get rid of C as a language used where security is a factor. Enough already. Why the hell is a lib like brotli that processes public general internet traffic, and maintained by google, not in rust?
doublerabbit · 2026-10-24 11:34:51 UTC
Because these applications were created long before Rust existed.
There is a cost to conversion.
Gigachad · 2026-10-24 11:36:20 UTC
Brotil was actually created post rust, but before rust took off.
davedx · 2026-10-24 11:41:05 UTC
It's not even an application it's a compression library
Dropbox switched to it a decade ago, so it's probably quite product-ready.
anthk · 2026-10-24 19:25:46 UTC
Check Librsvg, or php-rust. Or tons of gtk4-rs software doing it just fine.
thephyber · 2026-10-24 14:27:21 UTC
Security is a factor everywhere. And C is everywhere. There's not going to be a "rewrite everything in Rust" project until after there is some legit penalty for selling / offering software in C that could be more secure in another language.
I think Mozilla got it right when they abandoned the effort to rewrite the entire browser in Rust and instead focused on analysis of which modules needed priority rewrites. If a module has historically had zero memory-related bugs, then there are other higher priority things to spend time on.
That said, Google Project Zero should have had Brotli on their radar. Hopefully they still have people and resources.
anthk · 2026-10-25 15:43:15 UTC
Asterinax. RustPyhon. PHP 8.5 rewrite in Rust. FFMPEG and Qemu might follow soon.
It's inevitable.
gsnedders · 2026-10-25 16:42:11 UTC
I’ll point out that Servo was always a research project — any thought of it replacing Gecko was an incredibly long-term stretch goal. It was _a lot_ more interested in “can we write a high-performance browser engine in Rust” (there’s a reason why it significantly predates Rust 1.0 — they were very much developed together!) and “can we implement parallelism in places where browsers historically have not” (because you have more guarantees of safety).
Chromium _has_ been replacing certain components with ones in safe languages, and it seems like that will continue slowly (with integrating them into the existing codebase, with web compatibility risk of any changes in behaviour, with the risk of performance and power regressions).
_flux · 2026-10-24 16:55:43 UTC
I can understand why people used a C library for these apps, as when HTTP2 was specified, the C lib was the only game in down.
It's slower, though. Too high a price to pay for safety it seems.
uecker · 2026-10-25 18:56:46 UTC
Sorry, I find the supply chain risks of Rust much more worrying than these memory safety issues. So how about we get rid of Rust? At least cargo is a problem.
nairboon · 2026-10-24 11:39:10 UTC
Brotli2Shell seems to be a more appropriate name for this.
mkl · 2026-10-24 13:19:26 UTC
Not when you're prioritising sensationalism over accuracy. Everyone's heard of HTTP, but hardly anyone's heard of brotli.
Article claims OpenAI found this in February, but I don’t think that’s correct. I think Google made a change to the Brotli source code in February that fixes the issue, but hadn’t realized it was a security issue and therefore hadn’t cut a release.
Rapzid · 2026-10-24 12:38:20 UTC
Yeah that doesn't make a lot of sense that they reported it but also nobody knew it was a security issue..
Maybe an LLM just happened to do one of those "while I'm here" fixes in Feb and because nobody reviews anything anymore..
"Fixed reading too many bytes."
LGTM!
Edit: I was close! "Detect and report invalid stream earlier." Could have been a person.
zahlman · 2026-10-27 06:24:32 UTC
> Could have been a person.
The commit is attributed to "eustas" (Eugene Kliuchnikov) on the Google GitHub repo, who is the primary contributor to the Brotli project by a wide margin going back to 2015; so I think we can reasonably say it was.
serious_angel · 2026-10-25 16:35:15 UTC
Thank you! Of course! I do believe these cases are dreams for LLM vendors to advertize themselves regardless truth, and many believe trends over actual evidence...
Please do consider sharing the actual evidence to keep in the history, and respect actual human authors involved, their effort, time, and humane attitude... for discoveries, competition, actual achievements to learn from and get inspiration...
A few month ago, everyone was advising to use cool-downs in your package upgrades. Now we're constantly overriding those because security incidents will be exploited immediately.
Guess that's just how it's gonna be from now on.
medler · 2026-10-24 12:07:58 UTC
It used to be a flex to say you deploy daily but it’s going to become a necessity just to keep up with the vulns
ManuelKiessling · 2026-10-24 16:51:22 UTC
CI/CD — Continuous Incidents, Continuous Defense.
mort96 · 2026-10-24 18:13:32 UTC
Yeah, obviously? Deploy fixes to security issues which apply to you as soon as possible, deploy random feature additions and non-critical bug fixes after some cooldown.
As always, the easiest way to manage this is to have as few dependencies as possible. If you have a lockfile with thousands of entries, you won't be able to go through them and decide which upgrades are legitimate urgent security updates and which can wait. If you have 10? You'll manage.
da_chicken · 2026-10-25 12:36:31 UTC
Exactly.
Security fixes for actively exploited vulnerabilities demand an emergency response. The risk of introducing new, unknown flaws is less than risk of having an active known exploited vulnerability.
However, absent the risk of a KEV, that changes the equation. Now the risks of code changes causing breaking changes plus the risk of supply chain attacks is greater than the risk of having to put some thought and time in to manage your software library versions.
It's not like AI created this distinction, either. Neither did CI/CD. This is standard systems administration -- literally ISO/IEC 20000 ITSM. It's exactly why, traditionally, new features are often limited to major versions. It's why binary compatibility was a huge issue with RHES 20 years ago, and why distros pin versions and backport security and selective bug fixes. A developer that doesn't know this is telling on themselves why they shouldn't have write access to production. Stability matters a lot because we like to get paychecks.
acdha · 2026-10-25 00:02:25 UTC
That's why it's important to practice your processes for both shipping quickly and overriding cooldowns. There's a baseline of things which are not easy to exploit where you want to patch on a regular cadence and the risk posed by a supply chain attack is greater than the risk of an attacker having enough of a footprint inside your systems to escalate. The fact that sometimes you have a specific situation like this where that's not true doesn't mean that 9 times out of 10 the cooldown was the better risk-reduction strategy.
gsnedders · 2026-10-25 16:33:30 UTC
A cooldown is a coarse way to deal with “supply chain security” — and that’s mostly a question of how much you trust your dependencies.
You may well (and probably should) trust the maintainers and release process of Brotli, Node.js, PHP, etc. security releases more than you trust some-random-JS package deep in your front end dependency graph.
You want to reduce the risk of introducing a compromised dependency into your product, and that’s largely a question of how much you trust upstream.
upofadown · 2026-10-24 11:51:12 UTC
An example of the cost of added complexity I suppose. Brotli is much more complicated than the gzip/deflate it replaces. ... and of course we still have to expose gzip to attack as well.
Every time you add something you lose something...
Comments
> Security notice: Upgrade certifi, pip, and uv in response to CA certificate incident
Blimey PIP is affected? That's bad. I feel like that should have been bigger news?
So strictly we have to burn everything python to the ground and reinstall entirely.
Even in today's LLM-addled world, I still think it's a better tradeoff for smaller system/site operators. Get the distro-level testing and regular auto-patching, rather than telling yourself it is a good idea to "freeze" your python world at the pace of your slowest app/system integrator.
It's the same reason I think docker is an anti-pattern for these small groups. You really cannot safely use these strategies to bake an image and divorce yourself from the maintained distro layer unless you are going to adopt CI/CD that does the same thing. Keep tracking all these patches to the entire runtime with all the dependencies, rebuild, re-test, and redeploy.
It's total cargo culting to adopt the freeze/image techniques and just abandon apps in place as if that is robust!
But, it's also more than just automatically updating everything. There is an editorial aspect to distro management to help secure the supply chain to your app. Most smaller orgs cannot feasibly do this as well as the regular linux distro maintainers. Some large orgs can probably do it better, but that doesn't matter if you aren't doing it large org style with dedicated security folks tracking all this against well-developed policies and procedures...
They have a point. The distro is only carrying a small fraction of what's available on PyPI, and will have out-of-date versions that may lack security patches (and for projects like yt-dlp, are highly unlikely to work at all). Realistically they aren't applying security backports; there would rarely be a reason not to just use the new version, and the resources just aren't there for that scale of patching anyway.
Further, pip will interfere with your system package manager's tracking of the system environment (PEP 668), and any attempt you make to install from .deb/.rpm/etc. to a virtual environment is a hack at best. Maybe you could symlink individual package folders to the system environment while installing a superset, but ugh. Oh, and if you're a developer (like most "Python die-hards" are) then this isn't very helpful, as you aren't testing the installation of your package the way that your users will do it.
So your trusted base is the Python runtime and maybe a few choice libraries that actually have engaged package management. Sadly, it is a trap to think you can put things on the internet as a small player by leveraging lots of third-party stuff, when you don't have the resources to actually maintain that large dependency base.
This also may mean you want a base OS like Fedora and not some crusty "enterprise" variant that tries to bundle a frozen Python from 15 years ago. This is getting a little better in recent years, with some enterprise platforms having optional package streams for parallel install of newer runtime versions, etc.
Edit to add: on the Fedora-derived platforms, pip doesn't really interfere much anymore. The platform python-* RPMs go into /usr/lib/... while pip installs into /usr/local/lib/... or your ~/.local/lib/... hierarchy. The only mysterious behavior you get is if you manage to install in both places and then you have to understand the path search order. Just like if you do strange things with user and virtual environments.
Basically once you leave the realm of the 5-10 most popular building blocks in an area (which OS packagers do distribute), you're still left with plenty of packages that have 10ks+ of users, sane maintainer/security/ownership models, and code that would be very difficult to just copy-paste a la stackoverflow (e.g. native/compiled deps with complex wheel build tooling).
What isn't really tenable for a small team is to drag in scores to hundreds of different third-party packages and rely on them all when you have no staff allocated to really evaluate and monitor so much upstream stuff.
You do need to be careful about creating new venvs with the old version of pip bundled in ensurepip in older Python releases. `uv` kindly patches that to newest pip, but not every Python binary does.
Or alternatively, on Debian with fixed system cert chain: https://discuss.python.org/t/avoiding-compromised-certificat...From code comments, because I found it interesting:
As a Mint 22.x user, I wonder if and when Debian or Ubuntu will pick up the change and release another patch for the system Python (basically, to my understanding, a base of 3.12.3 with security patches from other patch releases backported). Since they've already updated ca-certificates it might not seem necessary, at least as long as the pip package gets updated (although I don't use that anyway).BTW, I think I saw your comments in other places about the 30-cent vibe-coded MITM demo proxy, unless someone else had the same idea. Thanks for helping educate.
Edit: apparently (https://discuss.python.org/t/avoiding-compromised-certificat...), the relevant Debian and Ubuntu packages already patch the distro-provided pip to enforce using the system certificates. (Indeed, `ca-certificates` is listed as "Depends" for the pip package, rather than "Recommends".) But maybe they'll still be interested in the key blocking, on defense-in-depth principles.
* Update system certificates
* Locate that pip and directly invoke it to self-update with hash pinning, rather than going through pipx
* Fix a few stray venvs that contained their own pip
* Use the fixed pipx to update uv (although I guess the uv self-update should work even for a pipx-installed copy?)
The legacy-certs hint is neat. I did it the first way but would rather not have since I'm on Mint.
This is not true; pip supports hash pinning, so an attacker would have to be able to defeat SHA256 as well (or compromise both the official Python discussion forum and PyPI itself, so as to forged the published hash). Other hashes can also be used. Instructions are provided on the Python discussion forum to self-upgrade pip with hash pinning: https://discuss.python.org/t/information-for-python-users-re...
It IS a mess and it's causing problems again and again in real life. And it is particularly bad with Python. I don't see why this should not be pointed out.
The above is incorrect per the Python forum discussion (https://discuss.python.org/t/information-for-python-users-re...). Pip will trust certificates from both sources.
Users of uv who have already updated their system certificates can use:
Who turned on hard mode this week?
It's so meaningless, broad and undescriptive of the actual issue. No it probably doesn't affect an HTTP server with nothing else behind it, so why is HTTP being blasted?
You might as well call it Exploit Pro Max...
AI isn't being asked to review the title, and it doesn't have experience or think, so of course it's not going to flag it.
No human reviews anything anymore so of course they aren't going to catch it.
Edit: AI for as good as it is at "writing" is terrible at writing and particularly at naming things. I had an AI name a client OpenAICompatibleEmbeddingClient. "Brooooo.. I think "compatible" is implied, who names stuff like that?!"
Which they will happily do if you ask them "why" they did something. 100% they will give their best "well actually" impression.
- https://lmstudio.ai/docs/developer/openai-compat
I've seen that used as a description for 2years or so.
> Remember that vuln 111-497 (as two chunks)
Good first step. Remember it’s two sets of three numbers. The first set is all ones, meaning the first three numbers are 1, then the fourth number is 4, then you add five for the next one (9), then you have to remember to subtract two (7)¹.
May sound silly, but I bet some of you have already memorised it from that alone. Being a slightly convoluted by still logical set-by-step helps with recollection.
¹ Lot of different ways to go about that, like remembering that the first set was three of one so “two was left out”.
https://github.com/google/brotli/issues/1597
Now, whether it's warranted or not, that's another matter, but they know how to appeal for maximum awareness/interaction.
And, most of all, is damaging to Google, which are the master of software engineering. /s
(Actually you eat cake and drink coffee on a funeral, but it's still called like that in some parts of Austria.)
[0] https://www.bugsink.com/blog/http2shell-timeline/
[1] https://news.ycombinator.com/item?id=50230362
https://bugzilla.mozilla.org/show_bug.cgi?id=366559#c147
SQL Slammer didn't actually slam anything, and applied to a single vendor among many SQL providers. Heartbleed didn't make anyone's heart bleed...I mean, at least directly. Shellshock only impacted a single shell environment, again among many. Log4Shell impacted a single logging implementation, among many. Spectre and Meltdown...I mean, who would think that related to CPU cache side channels?
These are just dumb names for people to share in referring to something. Seems silly and like a waste of time to spend effort getting upset about them.
There is a cost to conversion.
Dropbox switched to it a decade ago, so it's probably quite product-ready.
I think Mozilla got it right when they abandoned the effort to rewrite the entire browser in Rust and instead focused on analysis of which modules needed priority rewrites. If a module has historically had zero memory-related bugs, then there are other higher priority things to spend time on.
That said, Google Project Zero should have had Brotli on their radar. Hopefully they still have people and resources.
Chromium _has_ been replacing certain components with ones in safe languages, and it seems like that will continue slowly (with integrating them into the existing codebase, with web compatibility risk of any changes in behaviour, with the risk of performance and power regressions).
However, why not switch to the Rust lib when it was available? I suppose people at Dropbox are now pretty happy they did in 2016: https://dropbox.tech/infrastructure/lossless-compression-wit...
It's slower, though. Too high a price to pay for safety it seems.
Maybe an LLM just happened to do one of those "while I'm here" fixes in Feb and because nobody reviews anything anymore..
"Fixed reading too many bytes."
LGTM!
Edit: I was close! "Detect and report invalid stream earlier." Could have been a person.
The commit is attributed to "eustas" (Eugene Kliuchnikov) on the Google GitHub repo, who is the primary contributor to the Brotli project by a wide margin going back to 2015; so I think we can reasonably say it was.
Please do consider sharing the actual evidence to keep in the history, and respect actual human authors involved, their effort, time, and humane attitude... for discoveries, competition, actual achievements to learn from and get inspiration...
https://bugzilla.mozilla.org/show_bug.cgi?id=2029458
As always, the easiest way to manage this is to have as few dependencies as possible. If you have a lockfile with thousands of entries, you won't be able to go through them and decide which upgrades are legitimate urgent security updates and which can wait. If you have 10? You'll manage.
Security fixes for actively exploited vulnerabilities demand an emergency response. The risk of introducing new, unknown flaws is less than risk of having an active known exploited vulnerability.
However, absent the risk of a KEV, that changes the equation. Now the risks of code changes causing breaking changes plus the risk of supply chain attacks is greater than the risk of having to put some thought and time in to manage your software library versions.
It's not like AI created this distinction, either. Neither did CI/CD. This is standard systems administration -- literally ISO/IEC 20000 ITSM. It's exactly why, traditionally, new features are often limited to major versions. It's why binary compatibility was a huge issue with RHES 20 years ago, and why distros pin versions and backport security and selective bug fixes. A developer that doesn't know this is telling on themselves why they shouldn't have write access to production. Stability matters a lot because we like to get paychecks.
You may well (and probably should) trust the maintainers and release process of Brotli, Node.js, PHP, etc. security releases more than you trust some-random-JS package deep in your front end dependency graph.
You want to reduce the risk of introducing a compromised dependency into your product, and that’s largely a question of how much you trust upstream.
Every time you add something you lose something...