://bernd.eckenfels.net
Von: security-dev im Auftrag von Rick Hillegas
Gesendet: Wednesday, November 3, 2021 6:07:00 PM
An: Sean Mullan ; security-dev@openjdk.java.net
Betreff: Re: previously prevented exploit now possible with JDK 18
Thanks for your detailed comments
exploit now possible with JDK 18
Thanks for your detailed comments, Sean. We agree wholeheartedly that
being signed and being trusted/valid are two separate concepts. The JDK
wisely punts the issue of trust to the application developer. As I
understand it, we disagree about the following points:
1) Is
Thanks for your detailed comments, Sean. We agree wholeheartedly that
being signed and being trusted/valid are two separate concepts. The JDK
wisely punts the issue of trust to the application developer. As I
understand it, we disagree about the following points:
1) Is the signedness of a jar
Hello Rick,
It is behaving as expected. Let me explain in more detail.
First, loading a signed JAR off the classpath only verifies the
signature and digests of the JAR file. It does not validate the signer's
certificate chain or determine if the signer is trusted. The JarFile API
class descripti
On 10/29/21 4:58 AM, Alan Bateman wrote:
On 28/10/2021 20:14, Rick Hillegas wrote:
As a canary in the mineshaft, I built and tested Apache Derby with
the recent build 18-ea+20-1248 of Open JDK 18. I tripped across the
following issue when running Derby's regression tests. The problem is
explai
On 28/10/2021 20:14, Rick Hillegas wrote:
As a canary in the mineshaft, I built and tested Apache Derby with the
recent build 18-ea+20-1248 of Open JDK 18. I tripped across the
following issue when running Derby's regression tests. The problem is
explained in more detail at
https://issues.apac
As a canary in the mineshaft, I built and tested Apache Derby with the
recent build 18-ea+20-1248 of Open JDK 18. I tripped across the
following issue when running Derby's regression tests. The problem is
explained in more detail at
https://issues.apache.org/jira/browse/DERBY-7126, where a simp
