I tried.
It's quite easy to move the new X509CertificateBuilder class into
java.security.cert.X509Certificate as an inner class, but I still want to make
Extension and CertificateRequest better.
Extension
-
Turns out java.security.cert.Extension is already defined for X.509, and there
+1 :)
On Thu, Dec 3, 2015 at 3:31 AM, Wang Weijun wrote:
> I tried.
>
> It's quite easy to move the new X509CertificateBuilder class into
> java.security.cert.X509Certificate as an inner class, but I still want to
> make Extension and CertificateRequest better.
>
> Extension
> -
>
> Turn
Hello,
Please review this small fix which updates XMLDSigWithSecMgr.java test
to extend the default security policy instead of override. Please see
details here:
https://bugs.openjdk.java.net/browse/JDK-8140470?focusedCommentId=13873347&page=com.atlassian.jira.plugin.system.issuetabpanels:com
I sent a wrong version of webrev, please use the following one
http://cr.openjdk.java.net/~asmotrak/8140470/webrev.01/
Artem
On 12/03/2015 05:10 PM, Artem Smotrakov wrote:
Hello,
Please review this small fix which updates XMLDSigWithSecMgr.java test
to extend the default security policy inst
Hey Tony,
looks like a fix that could come back to jdk8u-dev at some stage. Thanks
for taking this one on.
Adding SecureRandom to the sunpkcs11-solaris.cfg file is a nice move.
Would you agree that JDK-8058455 could be closed out as a duplicate ?
Regards,
Sean.
On 01/12/2015 23:44, Anthony
Hi Sean,
Yes on both counts. There should be no problem backporting and 8058455 can be a
duplicate.
Tony
> On Dec 3, 2015, at 10:38 AM, Seán Coffey wrote:
>
> Hey Tony,
>
> looks like a fix that could come back to jdk8u-dev at some stage. Thanks for
> taking this one on.
>
> Adding Secure
The more I look at this the less I'm comfortable with the change to
non-synchronized.
In general, there shouldn't be a need for a large amount of random data,
especially not between multiple threads, so I'm not too sure the
performance argument holds.
What I do worry about is a provider that
Hello,
That buffer sizing/expiring is a bit strange (the dynmic version stranger than
the old one), I do not understand the need for it. The requests should not
varry so much in size. Just reading something like 64bytes at a time (possibly
nonblocking) should be fine. No need to look at the age
Or if this is too much, we can at least do the X509Extension part. If
CertificateRequest is needed one day, we can create a new method
Builder.certificateRequest() that returns it and deprecate the current
request() method.
Or use certificateRequest() to return byte[] and save request() for the
