Re: RFR 8146619: Re-examine supportness of public classes in com.sun.security.auth.**

Looks fine to me. Xuelei On 6/15/2016 11:36 AM, Wang Weijun wrote: > Please take a look at > >http://cr.openjdk.java.net/~weijun/8146619/webrev.00/ > > Basically, the following changes are made to all 7 classes: > > + * This class is subject to removal in a future version of Java SE. >

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

> On Jun 13, 2016, at 8:28 PM, Wang Weijun wrote: > > OK, please take a review at the new version at > > http://cr.openjdk.java.net/~weijun/8130302/webrev.04/ > The new -addProvider option is good. I mostly reviewed KeyStoreUtil.java and skimmed through other

RFR 8146619: Re-examine supportness of public classes in com.sun.security.auth.**

Please take a look at http://cr.openjdk.java.net/~weijun/8146619/webrev.00/ Basically, the following changes are made to all 7 classes: + * This class is subject to removal in a future version of Java SE. */ -@Deprecated +@Deprecated(since="1.4", forRemoval=true) public class Xyz { I

Re: RFR 8158887: sun/security/tools/jarsigner/concise_jarsigner.sh timed out

OK. Xuelei On 6/15/2016 11:13 AM, Wang Weijun wrote: > Let's use 240 for the moment. If it fails again, maybe it's because of a real > bug? > > Thanks > Max > >> On Jun 15, 2016, at 11:10 AM, Xuelei Fan wrote: >> >> Looks fine to me. >> >> Timeout may occurs

Re: RFR 8158887: sun/security/tools/jarsigner/concise_jarsigner.sh timed out

Let's use 240 for the moment. If it fails again, maybe it's because of a real bug? Thanks Max > On Jun 15, 2016, at 11:10 AM, Xuelei Fan wrote: > > Looks fine to me. > > Timeout may occurs intermittent because of the load of the platform. Is > it safer to use a bigger

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

Please take a review on the patch diff --git a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java --- a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java +++

Re: RFR 8158887: sun/security/tools/jarsigner/concise_jarsigner.sh timed out

Looks fine to me. Timeout may occurs intermittent because of the load of the platform. Is it safer to use a bigger timeout value? For example 320 or 480. Thanks, Xuelei On 6/15/2016 10:47 AM, Wang Weijun wrote: > This test runs slow. I've noticed it timeouts several times with exploded > build

Re: Code Review Request 8150966 Typo in javax.net.ssl.SSLEngineResult.HandshakeStatus.NEED_UNWRAP_AGAIN

Looks fine. Thanks Max > On Jun 15, 2016, at 10:58 AM, Xuelei Fan wrote: > > Hi, > > Please review this spec typo fix. There is an additional word 'can' in > the spec "The {@code SSLEngine} needs to unwrap before handshaking can > can continue." > > Here is the update

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

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 that I also remove another line from ProblemTest.txt because that bug is a dup of

Code Review Request 8150966 Typo in javax.net.ssl.SSLEngineResult.HandshakeStatus.NEED_UNWRAP_AGAIN

Hi, Please review this spec typo fix. There is an additional word 'can' in the spec "The {@code SSLEngine} needs to unwrap before handshaking can can continue." Here is the update of jdk/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java: /** * The {@code

RFR 8158887: sun/security/tools/jarsigner/concise_jarsigner.sh timed out

This test runs slow. I've noticed it timeouts several times with exploded build back in the jigsaw forest. Running with an image build should be faster but it's still safe to add some extra time. Please take a review: diff --git a/test/sun/security/tools/jarsigner/concise_jarsigner.sh

Re: Issues with ALPN implementation in JDK 9

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 to allow the negotiated application protocol to > be set up until the time the hello response was wrapped, that

Re: RFR 8157848: Mark deprecated javax.security.auth.Policy API with forRemoval=true

Looks fine to me. Thanks, Xuelei On 6/15/2016 8:42 AM, Wang Weijun wrote: > We intend to remove this API in jdk10. Please take a review on the jdk9/dev > patch below: > > diff --git a/src/java.base/share/classes/javax/security/auth/Policy.java >

RFR 8157848: Mark deprecated javax.security.auth.Policy API with forRemoval=true

We intend to remove this API in jdk10. Please take a review on the jdk9/dev patch below: diff --git a/src/java.base/share/classes/javax/security/auth/Policy.java b/src/java.base/share/classes/javax/security/auth/Policy.java --- a/src/java.base/share/classes/javax/security/auth/Policy.java +++

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

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 On 6/14/2016 2:28 PM, Sean Mullan wrote: I don't think you need

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

That sounds better. I will update the test and re-run it. Thanks, Valerie On 6/14/2016 2:28 PM, Sean Mullan wrote: I don't think you need to make changes to test/javax/smartcardio/policy. Instead you can change the tests that use this policy file to use the new jtreg @run

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

> On Jun 13, 2016, at 5:10 PM, Valerie Peng wrote: > > Sean, > > Can you please review the changes for deprivileging the java.smartcardio > module? > I have to update one makefile in the top-level workspace besides the > java.policy file in the jdk workspace. > One

Re: Issues with ALPN implementation in JDK 9

> On Jun 14, 2016, at 2:52 PM, Simone Bordet wrote: > > Hi, > > On Tue, Jun 14, 2016 at 8:11 PM, Jason Greene wrote: >> If the case is that H3 blacks all RSA, then thats an easy test right? Just >> verify that keystore has an ECDSA key. > >

JDK 9 RFR of JDK-8159502: Mark ShortRSAKey512.java as intermittently failing

The test javax/net/ssl/TLSv12/ShortRSAKey512.java has been seen to intermittently fail (JDK-8159501). The test should be marked accordingly. Please review the patch below which does this. Thanks, -Joe diff -r d6a1ad87842f test/javax/net/ssl/TLSv12/ShortRSAKey512.java ---

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

I don't think you need to make changes to test/javax/smartcardio/policy. Instead you can change the tests that use this policy file to use the new jtreg @run /java.security.policy=policy which extends the default system policy. --Sean On 06/13/2016 08:10 PM, Valerie Peng wrote: Sean, Can

Re: Issues with ALPN implementation in JDK 9

Hi, On Tue, Jun 14, 2016 at 8:11 PM, Jason Greene wrote: > If the case is that H3 blacks all RSA, then thats an easy test right? Just > verify that keystore has an ECDSA key. I don't think it is that easy. The server logic has to mimic exactly what the JDK logic is,

Re: Issues with ALPN implementation in JDK 9

> On Jun 14, 2016, at 10:58 AM, Simone Bordet wrote: > > Hi, > > On Tue, Jun 14, 2016 at 5:26 PM, Jason T. Greene > wrote: >> With H2 all impls are required to support >> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > > Unless it is discovered

Re: Issues with ALPN implementation in JDK 9

Hi, On Tue, Jun 14, 2016 at 5:58 PM, Simone Bordet wrote: > The server could choose an ECDSA cipher for h3, the mandatory cipher > for h2, so the list of cipher is (ECDSA, RSA). If, at this point, the > server chooses the protocol *before* the JDK chooses the cipher, it

Re: Issues with ALPN implementation in JDK 9

Hi, On Tue, Jun 14, 2016 at 5:26 PM, Jason T. Greene wrote: > With H2 all impls are required to support > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Unless it is discovered vulnerable. > so that should be selectable either by your protocol stack or the TLS layer. > If

Re: Issues with ALPN implementation in JDK 9

> On Jun 14, 2016, at 8:58 AM, Simone Bordet wrote: > > During the unwrap(), the JDK implementation picks a cipher based on > the JDK logic. > In particular, in my case, I had a keystore with a certificate that > was *not* ECDSA. > If, in the snippet above, I set more

Re: Issues with ALPN implementation in JDK 9

Hi, On Tue, Jun 14, 2016 at 4:31 PM, David M. Lloyd wrote: >> During the unwrap(), the JDK implementation picks a cipher based on >> the JDK logic. >> In particular, in my case, I had a keystore with a certificate that >> was *not* ECDSA. > > Could you not use the

Re: Issues with ALPN implementation in JDK 9

I have a few questions, inline. On 06/14/2016 08:57 AM, Simone Bordet wrote: Hi, I gave a shot at implementing ALPN in JDK 9 in Jetty. TLDR: I could not find a way to make it work. This email is to discuss whether I am off road or discuss possible solutions. Below my feedback. * Lack of

Issues with ALPN implementation in JDK 9

Hi, I gave a shot at implementing ALPN in JDK 9 in Jetty. TLDR: I could not find a way to make it work. This email is to discuss whether I am off road or discuss possible solutions. Below my feedback. * Lack of facilities to convert TLS protocol bytes to protocol strings. This class already

Re: [9] RFR: 8159038: javax/net/ssl/SSLSession/SessionCacheSizeTests.java failed with java.net.SocketException: Address already in use

Looks fine to me. Thanks, Xuelei On 6/14/2016 6:25 AM, Artem Smotrakov wrote: > Hello, > > Please review this patch for 9. > > javax/net/ssl/SSLSession/SessionCacheSizeTests.java test fails > intermittently with "java.net.SocketException: Address already in use" > exception. This exception

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

On 14/06/2016 04:28, Wang Weijun wrote: OK, please take a review at the new version at http://cr.openjdk.java.net/~weijun/8130302/webrev.04/ Changes from webrev.03: 1. The new option name -addprovider is used, along with the changes in Resources.java. 2. In