Re: Serialzation PREVIOUSLY: RFR: 8229773: Resolve permissions for code source URLs lazily

Thanks Sean, No I hadn't seen it, I've just read it, will probably need to read it again to appreciate it fully... It certainly identifies all the issues I'm aware of, as well as being respectful of the original implementors (many of whom participated in Apache River when Jini was donated to

Re: Serialzation PREVIOUSLY: RFR: 8229773: Resolve permissions for code source URLs lazily

Brian Goetz (copied) has done a lot of thinking in the serialization area, so I have copied him. Not sure if you have seen it but he recently posted a document about some of his ideas and possible future directions for serialization: http://cr.openjdk.java.net/~briangoetz/amber/serialization.ht

Re: [RFR] JDK-8225436 : Stapled OCSPResponses should be added to PKIXRevocationChecker irrespective of revocationEnabled flag

Looks good. There is one case where an unnecessary ArrayList is created (on line 406-7) if revocation is disabled AND we don't find a RevocationChecker -- it would be useful if you could avoid that by iterating over the checkers before creating the array list, since it is probably the more comm

Serialzation PREVIOUSLY: RFR: 8229773: Resolve permissions for code source URLs lazily

Thanks Sean, You've gone to some trouble to answer my question, which demonstrates you have considered it. I donate some time to help maintain Apache River, derived from Sun's Jini. Once Jini depended on RMI, today, not so much, it still has some dependencies on some RMI interfaces, but doe

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

Thanks Claes, I'll run some tests :) Cheers, Peter. On 16/08/2019 9:14 PM, Claes Redestad wrote: Hi Peter, by explicitly ensuring the file system has been initialized before installing a SecurityManager using a hook in System.setSecurityManager, the patch at hand takes step to ensure things

Re: Code Review Request, JDK-8228757 : Fail fast if the handshake type is unknown

Looks good to me. --Jamil On 8/19/19 9:02 AM, Xuelei Fan wrote: Hi, Could I have the following code cleanup reviewed?    http://cr.openjdk.java.net/~xuelei/8228757/webrev.00/ It is trying to fail fast if unknown handshake type get requested. Simple fix and hard to capture the fail point, no

Code Review Request, JDK-8228757 : Fail fast if the handshake type is unknown

Hi, Could I have the following code cleanup reviewed? http://cr.openjdk.java.net/~xuelei/8228757/webrev.00/ It is trying to fail fast if unknown handshake type get requested. Simple fix and hard to capture the fail point, no new regression test. Thanks, Xuelei

Re: Allow to define the list of enabled named curves for EC cipher suites as Security Property

On 8/19/19 10:10 AM, Christian Schaefer wrote: Hi Sean, -Original Message- Subject: Re: Allow to define the list of enabled named curves for EC cipher suites as Security Property On 8/19/19 7:33 AM, Christian Schaefer wrote: Hi all, Today, the list of enabled named curves for EC ciph

Re: [14] RFR 8228659: Record which Java methods are called by native codes in JGSS and JAAS

Ping again. > On Jul 26, 2019, at 11:24 PM, Weijun Wang wrote: > > Please review the change at > > http://cr.openjdk.java.net/~weijun/8228659/webrev.00/ > > Most of the change is new comments on internal Java methods called by native > code. I also take this chance to simply Ticket creation

RE: Allow to define the list of enabled named curves for EC cipher suites as Security Property

Hi Sean, > -Original Message- > Subject: Re: Allow to define the list of enabled named curves for EC cipher > suites as Security Property > > On 8/19/19 7:33 AM, Christian Schaefer wrote: > > Hi all, > > > > Today, the list of enabled named curves for EC cipher suites can be > > specified

Re: Allow to define the list of enabled named curves for EC cipher suites as Security Property

On 8/19/19 7:33 AM, Christian Schaefer wrote: Hi all, Today, the list of enabled named curves for EC cipher suites can be specified as “System Property” (name of the system property is jdk.tls.namedGroups) in JDK 8 and later. It seems like it cannot be specified as “Security Property”. So unl

Re: Is Digicert's continued use of the "Distrusted" certificates for code signing still valid?

Bert, Thanks for reaching out. A few of your questions should be addressed by DigiCert but I’ll try to address the one about the root CAs included in the JDK. On Tue, 25 Jun 2019 at 19:08, Bert Eisen > wrote: Hello, I’m trying to understand why Di

Allow to define the list of enabled named curves for EC cipher suites as Security Property

Hi all, Today, the list of enabled named curves for EC cipher suites can be specified as "System Property" (name of the system property is jdk.tls.namedGroups) in JDK 8 and later. It seems like it cannot be specified as "Security Property". So unlike jdk.tls.disabledAlgorithms and jdk.certpath.

Re: FRF[14] JDK-8228967: Trust/Key store and SSL context utilities for tests

Could this patch be reviewed? Best regards, John On 2019/8/4 07:32, sha.ji...@oracle.com wrote: Hi Sean, I moved test/jdk/java/security/testlibrary/CertUtils.java  to test/lib/jdk/test/lib/security/CertUtils.java, and added the new methods to this class. The affected existing tests are also