> On Jun 23, 2018, at 8:35 AM, Valerie Peng wrote:
>
> On 6/22/2018 3:23 PM, Weijun Wang wrote:
>>> On Jun 23, 2018, at 2:30 AM, Valerie Peng wrote:
>>>
>>> Max,
>>>
>>> Good catch on the SunRsaSign provider bug.
>>>
>>> Looking at the changes, I think we may have to fine-grain the check
On 6/22/2018 3:23 PM, Weijun Wang wrote:
On Jun 23, 2018, at 2:30 AM, Valerie Peng wrote:
Max,
Good catch on the SunRsaSign provider bug.
Looking at the changes, I think we may have to fine-grain the check on the
ensureInit() call, i.e.
use ensureInit(boolean sign) instead of
Update: http://hg.openjdk.java.net/jdk/sandbox/rev/63ab0dfe3dbb
Except the issues in this thread, this update also include changes to
set signature parameters after key initialization, so that the provider
of Signature instance is the same as its key provider if needed.
We have fixed the
Updated webrev at
http://cr.openjdk.java.net/~weijun/8201815/webrev.02
The only change is in SocketPermission.java.
Thanks
Max
> On Jun 21, 2018, at 10:31 PM, Weijun Wang wrote:
>
> Ping again.
>
> I still need code review for the other changes. The latest webrev is at
>
>
> On Jun 23, 2018, at 2:30 AM, Valerie Peng wrote:
>
> Max,
>
> Good catch on the SunRsaSign provider bug.
>
> Looking at the changes, I think we may have to fine-grain the check on the
> ensureInit() call, i.e.
>
> use ensureInit(boolean sign) instead of ensureInit(), as the current
All good catches! I will push the changeset soon after the testing.
On 6/22/2018 11:18 AM, Jamil Nimeh wrote:
* DHKeyExchange.java
o 177-192: Am I missing something or does isRecovering get defined
as false and never gets set to true within the lifetime of the
variable?
Max,
Good catch on the SunRsaSign provider bug.
Looking at the changes, I think we may have to fine-grain the check on
the ensureInit() call, i.e.
use ensureInit(boolean sign) instead of ensureInit(), as the current
method only ensures that at least one of the privKey, pubKey or
* DHKeyExchange.java
o 177-192: Am I missing something or does isRecovering get defined
as false and never gets set to true within the lifetime of the
variable? Do we still need this?
o 178: Nit/typo: "recove" --> "recover"
o 207-210: Catching Exception seems really
Hi Dora,
You could move those two lines that sets the locale to en-US before the
for-loop, so that if "args" contains -J-Duser.language/country then it
can override the default en-US.
The JIRA issue needs noreg-self label.
Naoto
On 6/22/18 1:26 AM, Dora Zhou wrote:
Hello,
Please help
Following on from the recent JDK-8203629 code review, I'd like to
propose enhancements on how we can record events in security libs. The
introduction of the JFR libraries can give us much better ways of
examining JDK actions. For the initial phase, I'm looking to enhance
some key security
Looks fine to me.
Thanks,
Xuelei
On 6/21/2018 10:39 PM, Weijun Wang wrote:
Webrev updated at
http://cr.openjdk.java.net/~weijun/8205445/webrev.01
I think I found a bug in SunRsaSign of the RSASSA-PSS signature. Fixed and
added a test.
BTW, I commented out the debug code in security.cpp.
Hello,
Please help review the fix for JDK-8194152. Thank you.
The test compares output with expected error messages in English, set
locale to en-US so that the output are not translated into other languages.
Bug: https://bugs.openjdk.java.net/browse/JDK-8194152
Webrev:
12 matches
Mail list logo
