An update on ecosystem concerns removing javax.security.cert

[Eirik Bjørsnøs]

>
> Given the compatibility risks/impacts with existing providers and JSSE
>> implementations, we've decided to withdraw this CSR for the time being.
>
>
One of the concerns raised by Alan in the CSR was related to SPECjbb2015:

The Grizzly framework is used in SPECjbb2015 for example, will it mean that
> this benchmark will no longer run on JDK main line?


I don't have access to SPECjbb2015, but it seems it is using some version
of Grizzly 2.x. I decided to check out the 2.4.4-RELEASE branch and it
seems the exposure to javax.security.cert is fairly limited and contained
to two method implementations in a single class SSLSupportImpl. This class
uses SSLSession, but does not implement it.

An interesting note is that the implementation methods actually do call
SSLContext.getPeerCertificateChain(), but then goes on to convert the
results to java.security.cert.X509Certificate. This makes no sense, so it
is probably an artifact of history. Anyhow, this actually means that
Grizzly 2 is already broken on mainline JDKs where the
getPeerCertificateChain throws and has no implementation.

This also means that _if_ SPECjbb2015 works on today's mainline, it will
probably continue to do so after the removal, because it's not calling the
affected methods in SSLSupportImpl.

It would be interesting to confirm this by running SPECjbb2015 on a JDK
with these APIs removed, but I'm not a licensee so I cannot explore that.

I'll consider contributing a PR to Grizzly 2.x to replace the
SSLSession.getPeerCertificateChain() with SSLSession.getPeerCertificates()
and drop the conversion. But I'm not so sure there will be interest in
releasing from this branch which seems dormant.

Cheers,
Eirik.



> I reached out to the BouncyCastle project [3] and they are basically OK
> with the OpenJDK project to go ahead and remove the APIs:
>
> It's a just cause, so go ahead and deal with it, I think all we need is
>> someone to let us know when it's done and point us at a JVM so we can
>> start organising the new jar.
>
>
> I have also contributed the following PRs to make Tomcat, Netty, Vert.x
> and Undertow aware of the plans of removal and also to provide the actual
> code changes:
>
> https://github.com/apache/tomcat/pull/608
> https://github.com/netty/netty/pull/13326
> https://github.com/eclipse-vertx/vert.x/pull/4665
> https://github.com/undertow-io/undertow/pull/1468
>
> Implementing these PRs was mostly straightforward, indicating that the
> impact in these projects would be relatively low if these APIs would be
> removed today.
>
> I think we are in a bit of a knotty situation where the ecosystem is now
> basically just waiting for OpenJDK to actually remove these APIs.
>
> Based on my recent interaction with these projects I'm hopeful that the
> ecosystem impact is lower than what has been assessed previously. I believe
> we should go ahead with this removal, sooner rather than later.
>
> Any thoughts?
>
> Kudos for reaching out the BC and for creating PRs to several projects to
> remove their usage, this is a great way to contribute!
>
> Removing anything is hard. The changes in JDK-8241047 were intended to
> allow SSLSession implementations drop their dependence on
> javax.security.cert.X509Certificate but it may take time if implementations
> are still expecting to be able to compile to a wide range of releases that
> include JDK 14 or older. I also be concerned that existing releases of this
> frameworks/libs with dependences on javax.security.cert.X509Certificate
> will be in use for some time. I'll defer to Sean and Brad but it feels like
> it might have to stay around for another few releases at least.
>
> -Alan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230418/9b454c0c/attachment.htm>