Hi Max,
Thanks for your review.
I’ve updated webrev with your comment.
Hai-May
> On Apr 7, 2020, at 8:13 PM, Weijun Wang wrote:
>
> Everything looks fine, except a very tiny issue:
>
> 1332 private String verifyWithWeak(PublicKey key) {
> 1333 if (DISABLED_CHECK.permits(SIG_PRIMI
> On Apr 8, 2020, at 11:46 AM, Valerie Peng wrote:
>
> Hi Max,
>
> Not all of the comments are related to the changes in the webrev, just notice
> some PSS related inconsistency and thought I will ask:
>
>
>
> - For RSASSA-PSS keys, existing code in getDefaultAlgorithmParameterSpec(...)
Hi Sean,
On 4/2/20 6:23 PM, Martin Balao wrote:
> Webrev.02:
>
> * http://cr.openjdk.java.net/~mbalao/webrevs/8241888/8241888.webrev.02
>
> On 4/2/20 5:02 PM, Sean Mullan wrote:
>>
>> In the java.security file might add the sentence "The default value of
>> the property is "false"" just to avoi
Hi Max,
Not all of the comments are related to the changes in the webrev, just
notice some PSS related inconsistency and thought I will ask:
- For RSASSA-PSS keys, existing code in
getDefaultAlgorithmParameterSpec(...) (line 1121) decides the default
based on key size. I think we should co
Everything looks fine, except a very tiny issue:
1332 private String verifyWithWeak(PublicKey key) {
1333 if (DISABLED_CHECK.permits(SIG_PRIMITIVE_SET, key)) {
1334 if (LEGACY_CHECK.permits(SIG_PRIMITIVE_SET, key)) {
1335 int kLen = KeyUtil.getKeySize(key);
I'd removed the change on ConfirmationCallback. Will address it in another fix
together with some other similar changes.
Webrev updated in-place. Please take a review.
Thanks,
Max
> On Mar 12, 2020, at 9:21 PM, Weijun Wang wrote:
>
> Please take a review at
>
> http://cr.openjdk.java.net/~
I added my name to the CSR.
> On Apr 7, 2020, at 6:41 PM, Weijun Wang wrote:
>
> Can you please add your name as a CSR reviewer?
>
> Thanks,
> Max
>
>> On Apr 8, 2020, at 9:25 AM, Xuelei Fan wrote:
>>
>> +1.
>>
>> Xuelei
>>
>>> On 4/7/2020 6:18 PM, Hai-May Chao wrote:
>>> Hi Max,
>>> Chang
Can you please add your name as a CSR reviewer?
Thanks,
Max
> On Apr 8, 2020, at 9:25 AM, Xuelei Fan wrote:
>
> +1.
>
> Xuelei
>
> On 4/7/2020 6:18 PM, Hai-May Chao wrote:
>> Hi Max,
>> Changes look good to me.
>> Is there a man page bug being filed for this?
>> Thanks,
>> Hai-May
>>> On Apr
+1.
Xuelei
On 4/7/2020 6:18 PM, Hai-May Chao wrote:
Hi Max,
Changes look good to me.
Is there a man page bug being filed for this?
Thanks,
Hai-May
On Apr 7, 2020, at 1:04 AM, Weijun Wang wrote:
I am thinking about removing the `jarsigner -altsigner -altsignerpath` options
and underlyin
Hi Max,
Changes look good to me.
Is there a man page bug being filed for this?
Thanks,
Hai-May
> On Apr 7, 2020, at 1:04 AM, Weijun Wang wrote:
>
> I am thinking about removing the `jarsigner -altsigner -altsignerpath`
> options and underlying classes:
>
>JBS : https://bugs.ope
+1.
Xuelei
On 4/7/2020 5:46 PM, Hai-May Chao wrote:
Hi Max,
Changes look good to me.
Hai-May
On Apr 6, 2020, at 8:11 PM, Weijun Wang wrote:
Please review the fix at
http://cr.openjdk.java.net/~weijun/8242184/webrev.00/
The major change is inside X509CRLImpl.java to allow params sett
Hi Max,
Changes look good to me.
Hai-May
> On Apr 6, 2020, at 8:11 PM, Weijun Wang wrote:
>
> Please review the fix at
>
> http://cr.openjdk.java.net/~weijun/8242184/webrev.00/
>
> The major change is inside X509CRLImpl.java to allow params setting and
> reading.
>
> I also take this ch
Yes, I think you're right. I'll remove that so it just tests for the
isInputCloseNotified and rerun the tests just to be sure.
Thanks for the feedback,
--Jamil
On 4/7/20 1:44 PM, Xuelei Fan wrote:
The conContext.isBroken condition in line 1124 is duplicated, and
could be safely removed, I th
The conContext.isBroken condition in line 1124 is duplicated, and could
be safely removed, I think. Otherwise, looks good to me. I don't think
there's need for another round of RFR.
Thanks,
Xuelei
On 4/7/2020 12:53 PM, Jamil Nimeh wrote:
Hello all,
This is a fix that brings the JSSE client
Hello all,
This is a fix that brings the JSSE client from JDK 11+ back in line with
the JDK 8 behavior of delivering SSLException on subsequent reads after
a handshake has failed due to an alert condition.
JBS: https://bugs.openjdk.java.net/browse/JDK-8242294
Webrev: https://cr.openjdk.java.
Looks good to me also Prasad. Trivially, I think you can drop the
'object' word in this implNote:
"for a new {@code SSLEngine} object"
Also, don't forget to create the release note sub-task for this change.
regards,
Sean.
On 02/04/2020 16:56, Prasadrao Koppula wrote:
Thanks for review Xuelei
I am thinking about removing the `jarsigner -altsigner -altsignerpath` options
and underlying classes:
JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
Please review everything at:
Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
CSR : https://bug
17 matches
Mail list logo
