Thanks Rajan's comments,
Updated the code here:
http://cr.openjdk.java.net/~tidu/8160337/webrev.01/ ,Please help to
review it again.Thanks.
Regards
Tim
On 2016/7/7 1:22, Rajan Halade wrote:
Hi Tim,
Thanks for taking care of this one. Since the test is still using
random data key "randomness
Looks fine to me. Thanks!
Xuelei
On 7/22/2016 6:08 AM, Vincent Ryan wrote:
> Thanks for the review.
>
> The PKCS11 implementation is a little peculiar in that it is configured
> out-of-the-box only for Solaris
> and that implementation doesn’t support DSA. So I’ve added only the first of
> yo
Thanks for the review.
The PKCS11 implementation is a little peculiar in that it is configured
out-of-the-box only for Solaris
and that implementation doesn’t support DSA. So I’ve added only the first of
your additional lines below.
(NOTE the update to the Ucrypto provider)
Updated webrev at:
Existing regression tests for the java.xml.crypto do test the
getInstance() methods as I observed during my own testing.
Maybe not all of them are covered though. I will double check and add
test if necessary...
Thanks,
Valerie
On 7/21/2016 12:08 PM, Sean Mullan wrote:
On 07/20/2016 07:
On 07/20/2016 07:57 PM, Valerie Peng wrote:
Sean,
I have updated webrev to rid the dependency on sun.security.jca
packages. Also, I found one additional SecurityPermission is needed.
Please find the updated webrev at:
http://cr.openjdk.java.net/~valeriep/8159488/webrev.01/
So, we should close
Looks fine to me.
Just two minor comments. The run tag in the test may be not necessary.
Like EC algorithm, maybe the PKCS11 implementation of RSA and DSA
algorithms can also be checked on some platform if not using provider
option.
+ main0("RSA", 2048, "SHA256withRSA", null);
+ main0(
Hello,
I have a situation here where we run an ldap service with round-robin dns
.. so, we advertise a cname that resolves to multiple actual servers.
Also, this cnam is not setup as a service principal in kerberos.
When I try to connect a java app (tomcat8 container, openjdk-7-jre v 7u101,
debia
Looks fine to me.
Thanks.
> On 21 Jul 2016, at 03:32, Xuelei Fan wrote:
>
> Hi,
>
> javax.security.cert was deprecated and marked with forRemoval=true in
> JDK 9. The use of javax.security.cert APIs should be marked with
> forRemoval=true too.
>
> Please review the update:
>
> http://cr.o
