There are currently a number of compromised Certificate Authority private keys. Apparently one of the private keys was literally "4". Mitigation steps are included in the linked page. https://emudhra.we-have-a-problem.com/
@seancorfield Not sure if we have a better place to surface general tech security announcements. Seems like something folks need to see, though.
There's #C3N85R7QT but that has < 200 members so #C03RZGPG3 has much better visibility and seems a good place to announce stuff like this.
Don't tell me someone mixed 384 bits with a number between 1-384
Hey, 0 is a bit too. No one said how many is too many.
Just a bit
the official openjdk advisory https://openjdk.org/groups/vulnerability/advisories/2026-10-21
I am not a certificate expert. What are the implications of the JVM containing some compromised certificates?
Do we have any tools that bundle ca certificates? JDK bundles trusted certificates in its installation. Is eMudhra intermediate CA part of them?
How about tools that do curl... | sh?
Ah sorry, that's what the openjdk advisory says. I should read first 😑
> What are the implications of the JVM containing some compromised certificates? it means that anyone can use the compromised cert authority's key to sign a cert, and impersonate any host (eg. you try to do a download from maven central and instead you get their MITM, which looks like the real host due to a forged cert)
Does anybody know who manages https://hub.docker.com/_/clojure/ ? I gotta figure out if we are hand building our own clojure docker image to hit our 7 day resolution window or if we have time to wait for folks to do the needful. 🙂
is there a good reason to use a specific clojure docker image rather than jvm plus a manual install of clj? seems like that would ensure you get the fastest updates
I use the official clojure image mostly because I trust they know what they are doing. If there is no expectation of update speed, then we will definitely do our own thing. That's kinda why I was asking who manages it so we could judge whether we need to put effort into building our own.
@quantisan might be the person to ask?
@seancorfield thanks!
Thanks for the heads up! The Clojure image re-build automatically when upstream Temurin make a release. So there's no lag. But Temurin's fix haven't landed to their Docker builds yet.
In the mean time, the workaround posted on the OpenJDK advisory should do: -
I created an Issue on docker-clojure https://github.com/Quantisan/docker-clojure/issues/300 if case anyone's searching.
Thanks!!
Evidently my coworker already knew about the workaround and sent a PR right after I asked my question lol
@quantisan It looks like the alpine images got a rebuild recently: are they now using 27.0.1? Can you confirm what temurin-27-tools-deps is aliased to these days? I couldn't figure it out looking at the Docker Hub pages.
(just verified, the -alpine images are still using 27+35, even tho' Temurin has 27.0.1 available... so I guess they haven't updated their Docker images yet?)
Temurin maintainer on what's the hold up -> https://github.com/adoptium/temurin/issues/317#issuecomment-6445647903
@quantisan Thanks for the update! The updated Temurin JDK 27 is available to yum so we have all our dev, QA & production servers updated, so it's only our CI still on 27+35 right now.