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.
> *
> 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 files that I assume the secur
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 stil
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 intermittent because of the load o
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 timeout value? For examp
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
+++ b/src/java.base/share/classes/
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
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 of
> jdk/src/java.base/
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
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 SSLEngine}
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
b/test/su
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 would fix the
> problem. Would it create any o
> 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 would fix the
> problem. Would it create any others?
Well the fundamental issue is that the applica
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
> b/src/java.base/share/classes/javax/security/aut
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
+++ b/
Looks fine to me.
Thanks,
Xuelei
On 6/15/2016 5:37 AM, joe darcy wrote:
> 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,
>
>
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 to
I think this discussion can be simplified to the following points:
- ALPN allows for a negotiated application protocol to be a function of
the cipher negotiated ( h2 vs h1 selection being the prime use-case).
- The cipher is negotiated by SslEngine during the unwrap of the Hello
messag
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
/java.security.policy
> 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 java.smartcardio regression
> 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.
>
> I don't think it is that easy.
Well certificate me
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
--- a/test/javax/net/s
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 y
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, that is
to verify the ciphe
> 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 vulnerable.
Sure, but in that case we have to rev the
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
> may think that h3 is a g
Hi,
i think not only the cipher suite and protocol version. But many other
parts should be also
be public. Like Supported digest, curve types, etc...
And also these information should be available for the keymanger.
So that he is able to select certificate also based on the curve types.
Gruß T
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 you wanted to be especially
> 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 than one cipher on the
> S
Hi,
On Tue, Jun 14, 2016 at 4:53 PM, David M. Lloyd wrote:
> Yes. Basically the server logic always has to be up to date with the latest
> cipher suites and that sort of thing. Our solution to this is to have a
> security framework that is responsible for this (among other things). It's
> not
On 06/14/2016 09:47 AM, Simone Bordet wrote:
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 th
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 available keys as an input into
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 faci
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 exi
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 occu
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 KeyStoreUtil::loadProviderByC
36 matches
Mail list logo