Please review this change to deprecate the OracleUcrypto JCE Provider
for removal. This change is part of JEP 362 (Deprecate the Solaris and
SPARC Ports) [1], which is Targeted to JDK 14.
Since this Enhancement was referenced from the JEP, I wasn't sure if a
CSR was strictly necessary, but I d
On 11/12/2019 13:30, Sean Mullan wrote:
Please review this change to deprecate the OracleUcrypto JCE Provider
for removal. This change is part of JEP 362 (Deprecate the Solaris and
SPARC Ports) [1], which is Targeted to JDK 14.
Since this Enhancement was referenced from the JEP, I wasn't sure
On 12/11/19 8:43 AM, Alan Bateman wrote:
On 11/12/2019 13:30, Sean Mullan wrote:
Please review this change to deprecate the OracleUcrypto JCE Provider
for removal. This change is part of JEP 362 (Deprecate the Solaris and
SPARC Ports) [1], which is Targeted to JDK 14.
Since this Enhancement w
On 11/12/2019 13:57, Sean Mullan wrote:
Good idea. I have added the following:
diff -r 9b513dbd57a3 src/java.base/share/conf/security/java.security
--- a/src/java.base/share/conf/security/java.security Wed Dec 11
14:08:20 2019 +0100
+++ b/src/java.base/share/conf/security/java.security Wed
Looks good.
--Sean
On 12/11/19 12:08 AM, Anthony Scarpino wrote:
Updated webrev:
Includes java.security updates
Max's addition
Sean's comments
http://cr.openjdk.java.net/~ascarpino/8233228/webrev.02/
Tony
Hi Max,
Thanks for reviewing this proposal.
On 12/6/19 5:27 AM, Weijun Wang wrote:
> 1. Can we change the signature of handleS4U2ProxyReferral so that there is
> only one credsInOut?
>
>String handleS4U2ProxyReferral(Credentials asCreds,
> Credentials[] credsInOut, PrincipalName sn
This looks good to me.
There is one confusion. I understand that handleS4U2ProxyReferral needs an
in/out creds argument, but for serviceCredsReferrals the additionalTickets
argument should only be in, right? However in this method you've modified the
content of it after calling handleS4U2ProxyR
Ping again. This is an enhancement.
> On Dec 10, 2019, at 5:45 PM, Weijun Wang wrote:
>
> Please review the code change at
>
> http://cr.openjdk.java.net/~weijun/8234465/webrev.00/
>
> The fix is mostly inside ECPrivateKeyImpl. When an EC keypair is newly
> generated, a copy of the ECPoint
What do you think about the compatibility impact? Minimal?
In the ECPrivateKeyImpl.parseKeyBits() implementation, a while() loop is
used. As make it possible to pass publicKey before parameters. Beside,
I would check if the encoded parameter is valid or not. They're not
new, you can leave
> On Dec 12, 2019, at 9:38 AM, Xuelei Fan wrote:
>
> What do you think about the compatibility impact? Minimal?
I think the major compatibility impact is that ECUtil::decodePoint will throw
an exception if the public ECPoint inside is invalid, but I think we shouldn't
ignore it.
Otherwis
10 matches
Mail list logo
