RFR 8027781: New jarsigner timestamp warning is grammatically incorrect

Hi Sean Please review a resource string change diff --git a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java b/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java --- a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java +++

Re: [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String)

You used String.valueOf(provider.getVersionStr()) on lines 70 and 861. Why not just provider.getVersionStr()? For parseVersionStr(), where is the spec for "java.specification.version"? Can we just use regex /(^\d+(\.\d+)?)/ to match the substring and turn it into a double? --Max > On Jun 16,

Re: RFR 8157318: ThreadedSeedGenerator uses System.currentTimeMillis and stops generating when time is set back

> On Jun 16, 2016, at 6:37 AM, David M. Lloyd wrote: > > This will not work because System.nanoTime() can be negative and wrap around. > You can't compare one nanoTime to another, only differences are useful. Yes, you are right. How about this then? diff --git

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

> On Jun 16, 2016, at 7:50 AM, Valerie Peng wrote: > > No big difference to me. Good, I'll remove the cast. @security-dev, can someone approve the whole webrev.05? http://cr.openjdk.java.net/~weijun/8130302/webrev.05 Thanks Max > Valerie > > On 6/15/2016 8:40

[9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String)

Any one has cycles to review this? Although the number of updated files are not trivial, but the key changes are in only 2 files, i.e. src/java.base/share/classes/java/security/Provider.java and src/java.base/share/classes/java/security/AuthProvider.java. The rest of files are all very

Re: Issues with ALPN implementation in JDK 9

On 6/15/2016 1:35 AM, Simone Bordet wrote: We have not heard from Oracle yet, but I can prepare a webrev if that helps. Hi all, Nice to see different folks are trying things out. I do appreciate the discussion/feedback. I am on a high-priority project right now, so I haven't had a

Re: RFR 8157318: ThreadedSeedGenerator uses System.currentTimeMillis and stops generating when time is set back

This will not work because System.nanoTime() can be negative and wrap around. You can't compare one nanoTime to another, only differences are useful. On 06/15/2016 05:30 PM, Bradford Wetmore wrote: Looks good, Max, thanks for taking this over. Xuelei, it's a threaded accumulator, which

Re: RFR 8157387: StrongSecureRandom.java timeout after push for JDK-8141039

Ditto. Brad On 6/15/2016 5:00 AM, Xuelei Fan wrote: Looks fine to me. Xuelei On 6/15/2016 10:58 AM, Wang Weijun wrote: The tests on non-native SecureRandom implementations are already covered by other tests and can be removed from this one. Please take a review at

Re: RFR 8157318: ThreadedSeedGenerator uses System.currentTimeMillis and stops generating when time is set back

Looks good, Max, thanks for taking this over. Xuelei, it's a threaded accumulator, which feeds into the seed generator. We wait a certain amount of time before generating the values. Brad On 6/15/2016 5:07 AM, Xuelei Fan wrote: I'm not sure I understand the while loop. But this update

Re: Issues with ALPN implementation in JDK 9

On 15 June 2016 at 21:31, David M. Lloyd wrote: > > >> I am proposing 3 simple changes to be done: >> >> 1) Introduce a TLSProtocolNames class that can convert from TLS >> protocol bytes to TLS protocol names. >> 2) Introduce a TLSCipherSuiteNames class that can convert

Re: Issues with ALPN implementation in JDK 9

Hi, On Wed, Jun 15, 2016 at 8:12 PM, Jason Greene wrote: > Here is an H2 example: > > The ClientHello expressing interest in both h2, and h1, and lists the ciphers: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > > So in this

Re: Issues with ALPN implementation in JDK 9

> On Jun 15, 2016, at 7:07 AM, David M. Lloyd wrote: > > On 06/14/2016 09:28 PM, Greg Wilkins wrote: >> >> >> On 15 June 2016 at 11:40, Jason T. Greene > > wrote: >> >> >>> On Jun 14, 2016, at 7:04 PM,

Re: JDK-8144566

Looks like a good candidate for backporting to jdk8u-dev. A backport record has been opened. Regards, Sean. On 15/06/16 09:50, Jaroslav Kameník wrote: Hi, could you please backport fix for this bug into JDK8? We run into it recently, our use case works well with JDK9, but it is long time to

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

> On Jun 15, 2016, at 10:57 PM, Mandy Chung wrote: > >>> 241 throw (InvalidParameterException) >>> >>> This cast should not be needed? >>> >> >> } catch (UcryptoException ue) { >> throw (InvalidParameterException) >> new

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

> On Jun 15, 2016, at 1:27 AM, Wang Weijun wrote: > > All suggestions accepted. Webrev updated at > > http://cr.openjdk.java.net/~weijun/8130302/webrev.05 > >> 241 throw (InvalidParameterException) >> >> This cast should not be needed? >> > > } catch

Re: Issues with ALPN implementation in JDK 9

On 06/15/2016 07:36 AM, Simone Bordet wrote: Hi, On Wed, Jun 15, 2016 at 1:31 PM, David M. Lloyd wrote: The problem is that this is quite subjective. In my opinion the current solution is both clean and precise: 1) Read the hello packet 2) Examine the protocols, host

Re: Issues with ALPN implementation in JDK 9

Hi, On Wed, Jun 15, 2016 at 1:31 PM, David M. Lloyd wrote: > The problem is that this is quite subjective. In my opinion the current > solution is both clean and precise: > > 1) Read the hello packet > 2) Examine the protocols, host names, and cipher suites > 3) Apply

Re: Issues with ALPN implementation in JDK 9

On 06/14/2016 09:28 PM, Greg Wilkins wrote: On 15 June 2016 at 11:40, Jason T. Greene > wrote: > On Jun 14, 2016, at 7:04 PM, Greg Wilkins > wrote: > > If SslEngine is changed

Re: RFR 8157387: StrongSecureRandom.java timeout after push for JDK-8141039

Looks fine to me. Xuelei On 6/15/2016 10:58 AM, Wang Weijun wrote: > The tests on non-native SecureRandom implementations are already covered by > other tests and can be removed from this one. Please take a review at > > http://cr.openjdk.java.net/~weijun/8157387/webrev.00 > > Please note

Re: [9] RFR 8154191: Deprivilege java.smartcardio module

Looks fine. --Sean On 06/14/2016 08:12 PM, Valerie Peng wrote: Re-ran passed. Webrev updated at: http://cr.openjdk.java.net/~valeriep/8154191/jdk/webrev.01/ Regards, Valerie On 6/14/2016 4:05 PM, Valerie Peng wrote: That sounds better. I will update the test and re-run it. Thanks, Valerie

Re: Issues with ALPN implementation in JDK 9

On 06/15/2016 03:35 AM, Simone Bordet wrote: Hi, On Wed, Jun 15, 2016 at 10:15 AM, Andrew Haley wrote: The problem I have with reading posts about JDK9 problems is that I can't tell the *severity* of the problems. I don't know if something is a total blocker or an

JDK-8144566

Hi, could you please backport fix for this bug into JDK8? We run into it recently, our use case works well with JDK9, but it is long time to official release.. Thanx:). Jaroslav

Re: Issues with ALPN implementation in JDK 9

Hi, On Wed, Jun 15, 2016 at 10:15 AM, Andrew Haley wrote: > The problem I have with reading posts about JDK9 problems is that I > can't tell the *severity* of the problems. I don't know if something > is a total blocker or an inconvenience. When someone uses an internal >

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

All suggestions accepted. Webrev updated at http://cr.openjdk.java.net/~weijun/8130302/webrev.05 > 241 throw (InvalidParameterException) > > This cast should not be needed? > } catch (UcryptoException ue) { throw (InvalidParameterException) new

Re: Issues with ALPN implementation in JDK 9

On 15/06/16 09:11, Simone Bordet wrote: > Sure, but then every ALPN implementer out there will have their own, > they will need to be kept up to date when a new TLS protocol or a new > cipher is introduced in the JDK, etc. etc. OK, I get that. The problem I have with reading posts about JDK9

Re: Issues with ALPN implementation in JDK 9

Hi, On Wed, Jun 15, 2016 at 10:03 AM, Andrew Haley wrote: > On 14/06/16 14:57, Simone Bordet wrote: >> * Lack of facilities to convert TLS protocol bytes to protocol strings. >> This class already exist in JDK, sun.security.ssl.ProtocolVersion, it >> would just need to be

Re: Issues with ALPN implementation in JDK 9

On 14/06/16 14:57, Simone Bordet wrote: > * Lack of facilities to convert TLS protocol bytes to protocol strings. > This class already exist in JDK, sun.security.ssl.ProtocolVersion, it > would just need to be exposed in javax.net.ssl. > > * Lack of facilities to convert TLS cipher bytes to