On Fri, Oct 23, 2026 at 03:51:28PM +0000, Kurt Miller wrote: > On Oct 23, 2026, at 11:48 AM, Kurt Miller <[email protected]> wrote: > > > > The recent eMudhra compromised certificates issue spurred some > > discussion regarding if the jdk's could share a common cacerts > > file that was built from our /usr/src/lib/libcrypto/cert.pem. > > > > The attached port implements that idea. So that the src tree > > is not required to build this, a copy of > > /usr/src/lib/libcrypto/cert.pem is kept in the files dir and > > requires updating when the file changes in the src tree. > > > > The jdk's then make use of /etc/ssl/jdk-cacerts by symlinking > > to it and having security/jdk-ca-certs as a RUN_DEPEND. > > > > Using /etc/ssl/jdk-cacerts is sufficient to block the use of the > > eMudhra certificates. However, consider the below changes to the > > jdks as WIP. I would combine the use of the common jdk-cacerts with > > the forthcoming updates to the jdk's which include the eMudhra > > certificates in the blocked.certs file. For now I'm looking for > > discussion/review on the approach and if good ok on the > > jdk-ca-certs port. > > And the attachment. >
This works for me as expected. I removed the contents of blocked.certs Your test program managed to reach all test sites, so all tests failed. I then applied your patch and built jdk-cacerts and all tests passed. With an outdated cert.pem with the eMudhra G3 Root 6 tests failed and 6 tests passed. Could you please 'chmod 644 files/cert.pem' 444 permissions in a dev tree are a pain. Relatedly, I'm unsure if we want to install jdk-cacerts as 444 to match cert.pem or whether we're happy with 644. Either is fine with me. I think we want this. ok tb I can live with the weird eopenssl40 incantation (which is a slightly annoying dep for me). I guess using java itself would create a loop which would be annoying to break. I'll look into how hard it is to implement this to get rid of eopenssl40.
