curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.
> Failure to do so could result in monster-in-the-middle (MITM) attacks against TLS clients, including python.org and pypi.org .
Monster?
jl6 7 minutes ago [-]
Gender-neutral variant of man-in-the-middle. They should have just used something less controversial like master-in-the-middle.
rolosa 1 hours ago [-]
This is such a clusterfuck. I use so many containers in my home lab and various local installations and stuff. Honestly, I have no idea what I'm even supposed to do at this point because I'm not a full time developer.
ahartmetz 16 minutes ago [-]
Well, that is what people who have been around the block a few times have been saying about containers since just about forever. "I don't want to be an admin for my n software packages, I'll use containers!" - now you are the admin of n containers, except with worse tools than your distro and no upstream support.
le-mark 10 minutes ago [-]
One could say comeuppance is a dish best served cold. So cold people don’t even know it’s been served. All the old sys admins remember!
ransom1538 49 minutes ago [-]
"Hey claude this is the cve I need you to fix [link]"
Takes about 20 seconds. Depending if you need to hit enter.
bigfishrunning 21 minutes ago [-]
cool cool cool. Don't understand what you're doing, and keep not understanding what you're doing. the agents are infallible after all, and who cares about properly verifying certs anyway? that's nerd shit.
iririririr 33 minutes ago [-]
don't worry. if you're in this situation with this attitude, you're likely running out of date container base images and whatnot.
i highly suggest you forget about containers, learn about systemd unit file hardening, and then you only have to play sysadmin to your base os and the binary for the program you want to run.
tesnorindian 55 minutes ago [-]
uv should be your friend.
insanitybit 26 minutes ago [-]
uv defaults to its own trust store afaik lol
vanschelven 23 minutes ago [-]
maybe they meant it "should" be your friend but actually isn't in this case :-)
1gargoyle 59 minutes ago [-]
Welcome to corporate
darkwater 3 hours ago [-]
This is news for NIST but old news generally speaking, being the eMudhra debacle. Or am I missing something?
ale42 3 hours ago [-]
It's the Go version of it, I think.
colinmarc 3 hours ago [-]
Go is not vulnerable in the same way software using webpki is, because it generally uses the system trust store. However, this change is about golang proactively blocking the certs, so that even if your OS doesn't update, it still won't trust them.
But the Go version is as well old news, actually it was one of the first stories about eMudhra appearing on the HN homepage yesterday.
pelzatessa 37 minutes ago [-]
Worth noting that people on RedHat still haven't received proper updates, only a workaround that disables two Comodo root certificates that were used to sign the emudhra certificates.
I chose AlmaLinux last time I needed to, and it's been a great way to access the ecosystem — I heartily recommend it as a free RHEL! — but these past few days have me looking in envy at Debian. Corporate stability hasn't been what I expected.
This seems to be about ‘go’ proactively blocking emudhra certs even though the system trust store is out of date? https://pkg.go.dev/vuln/GO-2026-6809
philipwhiuk 3 hours ago [-]
"proactively" doing some work.
The problem is Golang has it's own trust store. So you don't benefit from OS patching.
sspiff 2 hours ago [-]
That's not the case, Go uses the system store with an additional revoke/deny list in crypto/x509 because it allows updating a deployed application on an out of date or slow moving platform or OS.
This CVE is literally just "versions of the Go deny list don't contain the eMuhdra revokation yet". Older versions of Go will still deny certs signed through the compromised certificate if the system store already has the update.
Great. The technology has progressed enough to kill the existing technologies. It's like the fish in a pool creating a shark that eats away all the fish while the fish proudly announce that their great creation (shark) as the frontier progress for their fish race.
cedilla 3 hours ago [-]
Here a CA derived a secret key from the number 4.
If you think "that's weird to see such a small number in key generation" than you're one step ahead of whoever generated that key.
Unfortunately, unlike with RSA, small primes are not apparent in elliptic cryptography.
The eMudhra CA compromises had nothing to do with LLMs? But I love the vibes.
prodigycorp 2 hours ago [-]
Agents have dramatically increased the ability to poke at every single surface out there. I would be surprised if the researcher who found this wasn't assisted by a llm.
renhanxue 1 hours ago [-]
The researcher in question has publicly stated[0] that he wanted to try Google's paranoid_crypto tool[1], so he ran it on some roots as a quick proof-of-concept, and the first thing that happened was that it detected these intermediates. He also states he's been running a lot of certificate linters so this was just the next logical step I guess.
That was an enlightening read. I find it incredible that apparently Google themselves don't use the existing corpus of certificates as a test for paranoid_crypto.
palata 3 hours ago [-]
> It's like the fish in a pool creating a shark
What a weird comparison...
RazorX 3 hours ago [-]
This is basically the whole idea of the novel War with the Newts
it's been slow for me since yesterday, i chalked it up to PHP CVEs + throttling a VPN user
charlieyu1 2 hours ago [-]
We are in the era of 6 digit CVE now
xacky 2 hours ago [-]
A lot of software is going to be forced to update or retire soon, all unpatched software should be retired off the internet immediately because AI agents are in waiting.
Im guessing this only affects Go? But I am guessing that from the nist page as none of the headlines mention it at all.
grey-area 3 hours ago [-]
No it affects everybody, but most browsers/OSs etc have updated already. This is just a workaround Go put in case the underlying OS has not been updated. Not sure why this link is on the front page as it duplicates previous posts and confuses people, I think it should be merged.
In other words, that software bundled the compromised certs into the binary, so upgrading it is the only way to remove them.
This is about Go proactively blocking intermediates. Which shouldn't strictly be necessary as long as your OS has removed or distrusted the CAs (on my laptop, macOS has done that, although it seems like it did so in a way not all tools have access to; for example, rustls-platform-verifier respects it, but rustls-webpki still loads the bad CAs from the system trust store).
edit: forgot I can't use code blocks on HN
t_mahmood 4 hours ago [-]
> edit: forgot I can't use code blocks on HN
You can, two space at the start of each line
fabioborellini 3 hours ago [-]
I wonder if they made this change with an assumption that the root CAs wouldn't be distrusted later same day, too.
speedgoose 3 hours ago [-]
Cock-up or conspiracy?
dspillett 2 hours ago [-]
Any sufficiently advanced stupidity is indistinguishable from malice.
charlieyu1 60 minutes ago [-]
I have seen way more malice pretending to be just stupid than the actual stupidity
* GLSA 202610-01: https://security.gentoo.org/glsa/202610-01
* https://emudhra.we-have-a-problem.com/
https://discuss.python.org/t/information-for-python-users-re...
Monster?
Takes about 20 seconds. Depending if you need to hit enter.
i highly suggest you forget about containers, learn about systemd unit file hardening, and then you only have to play sysadmin to your base os and the binary for the program you want to run.
https://github.com/golang/go/issues/82345
https://access.redhat.com/security/vulnerabilities/RHSB-2026... - "Ongoing"
I chose AlmaLinux last time I needed to, and it's been a great way to access the ecosystem — I heartily recommend it as a free RHEL! — but these past few days have me looking in envy at Debian. Corporate stability hasn't been what I expected.
The problem is Golang has it's own trust store. So you don't benefit from OS patching.
This CVE is literally just "versions of the Go deny list don't contain the eMuhdra revokation yet". Older versions of Go will still deny certs signed through the compromised certificate if the system store already has the update.
It's an or situation, not and.
If you think "that's weird to see such a small number in key generation" than you're one step ahead of whoever generated that key.
Unfortunately, unlike with RSA, small primes are not apparent in elliptic cryptography.
https://xkcd.com/221/
[0]: https://groups.google.com/a/mozilla.org/g/dev-security-polic...
[1]: https://github.com/google/paranoid_crypto
What a weird comparison...
Here is the original story: https://news.ycombinator.com/item?id=50166579
https://news.ycombinator.com/item?id=50166579
The very urgent uv/certifi/etc releases (and yet-to-be-done bun release) are about removing the compromised CAs as described here:
https://emudhra.we-have-a-problem.com/
In other words, that software bundled the compromised certs into the binary, so upgrading it is the only way to remove them.
This is about Go proactively blocking intermediates. Which shouldn't strictly be necessary as long as your OS has removed or distrusted the CAs (on my laptop, macOS has done that, although it seems like it did so in a way not all tools have access to; for example, rustls-platform-verifier respects it, but rustls-webpki still loads the bad CAs from the system trust store).
edit: forgot I can't use code blocks on HN