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. It is in used by many customers. It looks like you are planning to remove that entire package now? We still compile with Java 8 (because we have customers that still need Java 8 support), but we need to support later Java runtime versions. I guess we would have eventually noticed this when we upped our base compiler to 11 which probably won’t happen until 8 no longer has extended support (which is 2030 according to this?) https://www.oracle.com/java/technologies/java-se-support-roadmap.html). Though.. I would hope everyone would be off 8 in the next few years… 😊
I guess we will have to make a number of changes to our toolkit because this change will break things in a number of areas in Java 19. I guess we have until the next LTS to do all this work… ☹ John Gray Entrust From: security-dev <security-dev-r...@openjdk.org> On Behalf Of Eirik Bjørsnøs Sent: Monday, April 17, 2023 4:00 AM To: security-dev@openjdk.org Subject: [EXTERNAL] 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 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.com/google/conscrypt/pull/1128<https://urldefense.com/v3/__https:/github.com/google/conscrypt/pull/1128__;!!FJ-Y8qCqXTj2!ar5kpb1r1i5Xsn4u_CR5zwdcmGLyTQNySwfvEMWPMEjNW17SrO-GOrkWEQGnrbFi3MfR3pKBr-yZvfDVFa_8$> Pete provides a neat explanation of how Conscrypt is packaged and used in the wider Opecosystem. I think the key takeaway for OpenJDK seems to be: I think for OpenJDK and standalone Android builds, it's probably fine to simply drop support for the getPeerCertificateChain() API at a release boundary. Caveat emptor etc. TBH we've never assumed that upstream OpenJDK would worry about us when making breaking changes. :) I don't mean that in a negative way, just that your priorities are not the same as ours and so it's up to us to react as needed. Pete then goes on to explain that javax.security.cert currently isn't formally marked as deprecated in Android Platform, so they are lagging behind aim to align with OpenJDK in this respect. The rest of his comments are mainly focused on the Android parts, it's a good read for anyone interested in that. Thanks, Eirik. Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
