>
> 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
@openjdk.org
Subject: Re: [EXTERNAL] Re: An update on ecosystem concerns removing
javax.security.cert
Hi John, thanks for reaching out!
I just happened to notice this on the list this morning. We have a 20+ year
old commercial Java cryptographic toolkit at Entrust that we maintain and
implement security
On Sat, 15 Apr 2023 at 11:16, Eirik Bjørsnøs wrote:
> Hi,
>
> JDK-8227024 [1] and the associated CSR JDK-8227395 [2] suggests removing
> the deprecated classes in javax.security.cert.
>
> The CSR was withdrawn last year following ecosystem compatibility concerns:
>
> Given the compatibility risks
>
> Ideally javax.security.cert would have been removed a long time ago but
> the references from classes in javax.net.ssl make it difficult for both
> implementers and users of the API. So I think we are forced to kick it down
> the road for now.
>
I think we may disagree a bit on the assessment
On 17/04/2023 10:03, Eirik Bjørsnøs wrote:
Sure we can delay this a few releases, but I honestly don't see
how that will materially change the situation.
Rethinking this, perhaps there are some benefits to not introducing
this in an LTS release. Doing it in a release immediately follo
Hi John, thanks for reaching out!
I just happened to notice this on the list this morning. We have a 20+
> year old commercial Java cryptographic toolkit at Entrust that we maintain
> and implement security protocols and algorithms which makes use of API’s in
> the javax.security.cert package. I
] Re: An update on ecosystem concerns removing
javax.security.cert
WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the
content is safe.
I reached out to the BouncyCastle project [3] and they
>
> Sure we can delay this a few releases, but I honestly don't see how that
> will materially change the situation.
>
Rethinking this, perhaps there are some benefits to not introducing this in
an LTS release. Doing it in a release immediately following an LTS would
allow the wider ecosystem maxi
>
> 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.
>
Based on my interaction with ecosystem projects so far, the prevalent
sentiment seems to be "we plan to deal with this once OpenJDK rem
>
> I reached out to the BouncyCastle project [3] and they are basically OK
> with the OpenJDK project to go ahead and remove the APIs:
>
> I reached out to the Conscrypt team with a PR. While the PR cannot be
integrated in its current form, the ensuing discussion was instructive:
https://github.c
>
> 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.
JDK-824
On 15/04/2023 10:15, Eirik Bjørsnøs wrote:
Hi,
JDK-8227024 [1] and the associated CSR JDK-8227395 [2] suggests
removing the deprecated classes in javax.security.cert.
The CSR was withdrawn last year following ecosystem compatibility
concerns:
Given the compatibility risks/impacts with
On Sat, Apr 15, 2023 at 11:15 AM Eirik Bjørsnøs wrote:
> Based on my recent interaction with these projects I'm hopeful that the
> ecosystem impact is lower than what has been assessed previously.
>
Neither Jetty nor Grizzly have dependencies on javax.servlet.cert in their
mainline code bases.
Hi,
JDK-8227024 [1] and the associated CSR JDK-8227395 [2] suggests removing
the deprecated classes in javax.security.cert.
The CSR was withdrawn last year following ecosystem compatibility concerns:
Given the compatibility risks/impacts with existing providers and JSSE
> implementations, we've
14 matches
Mail list logo
