ApiTest.java:
- Please move line 128-130 (the System.out.println) line before line 127, so
that if getInstance() fails, we can see what parameters are failing.
- Useless line 69.
- Inside verifyAPI(), you call nextBytes(.., DrbgParameters.nextBytes(-1,
false, ..)). Can you also call nextBytes(
Looks good to me. Please create a release-note subtask so that this
change in keytool defaults gets documented in the JDK 9 release notes.
(There should also be one for the jarsigner tool).
Thanks,
Sean
On 05/16/2016 10:06 PM, Wang Weijun wrote:
Please take a look at
http://cr.openjdk.ja
A subtask? So the release-note=yes label is not enough now?
--Max
> 在 2016年5月18日，22:55，Sean Mullan 写道：
>
> Please create a release-note subtask so that this change in keytool defaults
> gets documented in the JDK 9 release notes. (There should also be one for the
> jarsigner tool).
On 05/17/2016 12:12 PM, Xuelei Fan wrote:
JDK still support version 1 cert. Developers may want to test
version 1 support of their applications. I agree that version 1
should be fade out although it is still actively used the practice,
especially as self signed cert.
I agree that we need to c
Hi,
Please review this spec update of the "jdk.tls.legacyAlgorithms"
Security Property:
http://cr.openjdk.java.net/~xuelei/8151856/webrev/
This updated spec clarifies the impact between the
"jdk.tls.legacyAlgorithms" and "jdk.tls.disabledAlgorithms" Security
Properties.
Thanks,
Xuelei
Hi -
To be very specific here - if a certificate has extensions, it MUST be
version 3, otherwise it SHOULD be version 1, but may be version 2 or 3.
(If a certificate has either of the issuer or subject unique ID fields,
it must be at least version 2 - but those fields are deprecated as a
MUS
Please review this small change to remove intermittent key from this
test. JDK-8137231 addressed intermittent failure and we haven't seen
test failure for a long time and with frequent runs.
Bug: https://bugs.openjdk.java.net/browse/JDK-8156035
diff -r 3675fb8573d4 test/sun/security/rsa/SpecTe
Looks fine to me.
--Sean
On 05/18/2016 01:41 PM, Rajan Halade wrote:
Please review this small change to remove intermittent key from this
test. JDK-8137231 addressed intermittent failure and we haven't seen
test failure for a long time and with frequent runs.
Bug: https://bugs.openjdk.java.net
719 # javax.net.ssl.SSLParameters.getAlgorithmConstraints()),
I think it should be setAlgorithmConstraints.
Otherwise, looks fine to me.
--Sean
On 05/18/2016 11:19 AM, Xuelei Fan wrote:
Hi,
Please review this spec update of the "jdk.tls.legacyAlgorithms"
Security Property:
http://cr.ope
Hello,
Please review the following patch for javax/net/ssl/TLS/TestJSSE.java test.
The test fails intermittently with BindException because it can use a
busy port. The test uses jdk.testlibrary.Utils.getFreePort() which
creates a server socket, and returns its local port number. Then this
por
On 5/19/2016 4:39 AM, Sean Mullan wrote:
> 719 # javax.net.ssl.SSLParameters.getAlgorithmConstraints()),
>
> I think it should be setAlgorithmConstraints.
>
Yes.
Thanks,
Xuelei
> Otherwise, looks fine to me.
>
> --Sean
>
> On 05/18/2016 11:19 AM, Xuelei Fan wrote:
>> Hi,
>>
>> Please review t
> On May 18, 2016, at 4:07 PM, Wang Weijun wrote:
>
> - Can you use Supplier instead of creating a new RunnableCode
> type? Same in GetInstanceTest.java.
You're right. We need a new type because of that checkedException.
--Max
Hello,
Please review the following patch for DTLS tests.
A couple of DTLS tests which are based on DTLSOverDatagram.java fail
intermittently. I was not able to reproduce these failures. I am
proposing to update the tests to print more information to logs, so that
more information will be avai
13 matches
Mail list logo
