Psychic Signatures in Java • Hacker News Board

Re: Psychic Signatures in Java

#121

Post by vlowrian » Fri, Apr 22, 2022, 10:30 AM UTC

gunnarmorling wrote: post #102

vlowrian wrote: post #86

What puzzles me most is that two days after the announcement of the vulnerability and the release of the patched Oracle JDK, there is still no patched version of OpenJDK for most distributions. We're running some production services on OpenJDK and CentOS and until now there are only two options to be safe: shutdown the services or change the crypto provider to BouncyCastle or something else. The official OpenJDK proj…

For folks on RHEL, the java-17-openjdk package for RHEL 8 has been updated: https://access.redhat.com/errata/RHSA-2022:1445 . > The official OpenJDK project lists the planned release date of 17.0.3 as April 19th, still the latest available GA release is 17.0.2 > ( https://wiki.openjdk.java.net/display/JDKUpdates/JDK+17u ). I don't think there 17.0.3 ever will be available from openjdk.java.net; there's no LTS for ups…

Thanks for the clarification. The site is not clear on that topic and actually suggests otherwise by listing the planned release dates in the timeline.

On the other hand, the problem that many popular server distributions like CentOS and Debian still haven't updated their Java 17 packages remains and I wonder if this is due to their own package build process or because they are waiting for an upstream process to complete.

If they actually rely on the upstream builds from openjdk.java.net that would mean that the fix will not make it to their repositories at all.

Re: Psychic Signatures in Java

#122

Post by vlowrian » Fri, Apr 22, 2022, 10:34 AM UTC

needusername wrote: post #117

gunnarmorling wrote: post #102

Earlier quoted context omitted.

For folks on RHEL, the java-17-openjdk package for RHEL 8 has been updated: https://access.redhat.com/errata/RHSA-2022:1445 . > The official OpenJDK project lists the planned release date of 17.0.3 as April 19th, still the latest available GA release is 17.0.2 > ( https://wiki.openjdk.java.net/display/JDKUpdates/JDK+17u ). I don't think there 17.0.3 ever will be available from openjdk.java.net; there's no LTS for ups…

> I don't think there 17.0.3 ever will be available from openjdk.java.net https://adoptopenjdk.net/upstream.html These are the official upstream builds by the updates project built by Red Hat. Not to be confused by Red Hat Java, not to be confused by the AdoptOpenJDK/Adoptium builds. These can‘t be hosted on openjdk.java.net because they host only builds done by Oracle, not to be confused by Oracle JDK.

This site doesn't provide anything newer than OpenJDK 11 and references the Adoptium projects for July 2021 and future releases. But Adoptium only provide their own Temurin distribution. Looks like a dead end for an OpenJDK 17.0.3 upstream build.

Re: Psychic Signatures in Java

#123

Post by ccbccccbbcccbb » Fri, Apr 22, 2022, 11:08 AM UTC

tedunangst wrote: post #53

ccbccccbbcccbb wrote: post #46

Q: Which type of cryptography is implied to be unsafe in the following sentence?: "Immediately ditch RSA in favor of EC, for it is too hard to implement safely!"

What's java's RSA history look like?

My comment was rather language-agnostic. Are there any fundamental differences in implementation of RSA or EC in various languages?

Re: Psychic Signatures in Java

#124

Post by ragnese » Fri, Apr 22, 2022, 12:26 PM UTC

znep wrote: post #98

ragnese wrote: post #14

Earlier quoted context omitted.

Was Spring4Shell Java's fault, or Spring's fault? Log4Shell was obviously (mostly) log4j's fault. This one, I gather, is actually Java's fault. It sounds like three unrelated security bugs from totally different teams of developers.

Spring4Shell is entirely a flaw in Spring, however is somewhat understandable because it was only exploitable due to a new feature in Java (modules) that added new methods to java.lang.Class, which is a very significant change. You could argue the very existence and nature of Java object serialization deserves blame as well, but that gets nuanced quickly. Modules are also part of the reason why so many folks got "stu…

Agreed. There's definitely space to spread some blame and criticism around, I suppose. And there are plenty of old Java decisions that open the door for these issues.