On Oct 23, 2026, at 2:20 PM, Theo Buehler <[email protected]> wrote: > > 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.
Good catch. I fixed the permissions on files/cert.pem and jdk-cacerts as You suggested and imported it. > 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.
