It's not easy to find out the word difference after a CSR edit. But you changed
everyone (yes, everyone) has been loading cacerts with a null password and they are able to read all certificate inside. to everyone (yes, everyone) who loads cacerts with a null password is able to read all certificates inside. I *did* mean that *everyone* is using the null password. Did you not? --Max > On May 31, 2019, at 4:27 PM, Langer, Christoph <christoph.lan...@sap.com> > wrote: > > Hi Max, > > I've already made some updates to the wording in the CSR. > > In the specification section, it should probably also not mention the source > location src/java.base/share/lib/security/cacerts as it is about to be > eliminated by JDK-8193255. It should rather refer to > <JDK>/lib/security/cacerts, I think. > > Best regards > Christoph > >> -----Original Message----- >> From: security-dev <security-dev-boun...@openjdk.java.net> On Behalf Of >> Weijun Wang >> Sent: Freitag, 31. Mai 2019 05:33 >> To: security-dev@openjdk.java.net >> Subject: RFR CSR for 8162628: Migrating cacerts keystore to password-less >> PKCS12 format >> >> Please review the CSR at >> >> https://bugs.openjdk.java.net/browse/JDK-8224891 >> >> (Oh, I hate the CSR having a different bug id.) >> >> Basically, with this change, the cacerts file can be loaded with >> >> KeyStore.getInstance("JKS" or "PKCS12").load(stream, null or anything) or >> KeyStore.getInstance(new File("cacerts"), null or anything) >> >> so hopefully all your old code should still work. >> >> I've also opened another RFE [1] that intends to find a different way to tag >> jdkCA entries in cacerts other than appending "[jdk]" to the alias. >> >> Thanks, >> Max >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8225099 >
