P11Cipher.java
--
line 775 and 850:
The code looks special to me. Is it possible/better to check the range
before the call to PKCS11 decryption function?
Xuelei
On 9/20/2016 5:11 AM, Valerie Peng wrote:
Anyone has time to review this trivial fix? This is a corner case of
decrypt
Safe update to me. Looks fine.
Xuelei
On 9/20/2016 5:06 AM, Valerie Peng wrote:
Can someone help review this fix?
Besides the obvious fixes, I ran into an intermittent
CKR_OPERATION_ACTIVE error which went away with the updated Secmod.java.
Bug: https://bugs.openjdk.java.net/browse/JDK-81498
> On Sep 20, 2016, at 8:58 AM, Xuelei Fan wrote:
>>
>> I this case, a comma appears but then it is escaped. You might say it is
>> unexpected, but at least after escaping, it becomes a legal string.
>>
> I did not get the point. A comma (",") should be escaped and it does get
> escaped and th
On 9/20/2016 5:53 AM, Wang Weijun wrote:
Sorry. Whenever I wrote NFC, I meant NFD. Typo.
在 2016年9月19日，23:16，Xuelei Fan mailto:xuelei@oracle.com>> 写道：
On 9/19/2016 11:03 PM, Wang Weijun wrote:
After some thinking, my current opinion is.
1. Maybe NFC is better than NFKD, but I am not a Uni
Xuelei,
Could you please help reviewing this change?
There are quite a few test failures on Solaris 12 due to the removal of
Solaris PKCS11 SSL3 mechanisms which SunPKCS11 provider assume to be
always present. I updated relevant classes as well as regression tests
to skip SSL3 testing when th
Sorry. Whenever I wrote NFC, I meant NFD. Typo.
> 在 2016年9月19日，23:16，Xuelei Fan 写道：
>
>> On 9/19/2016 11:03 PM, Wang Weijun wrote:
>> After some thinking, my current opinion is.
>>
>> 1. Maybe NFC is better than NFKD, but I am not a Unicode expert.
>>
> It is updated from NFKD to NFD. I did
All,
I apologize if this isn't the right place to post this. Please let me
know if I should post elsewhere and I'll be happy to do so.
For the past few years, I've been maintaining a Java-based TLS server
tester mostly for my own use, but also shared with the Apache Tomcat
user community. It does
Anyone has time to review this trivial fix? This is a corner case of
decrypting with 0-length data. Some provider throws exception but some
just returns (no-op). For less impact, I changed all to match SunJCE
provider's behavior which just returns.
Bug: https://bugs.openjdk.java.net/browse/J
Can someone help review this fix?
Besides the obvious fixes, I ran into an intermittent
CKR_OPERATION_ACTIVE error which went away with the updated Secmod.java.
Bug: https://bugs.openjdk.java.net/browse/JDK-8149802
Webrev: http://cr.openjdk.java.net/~valeriep/8149802/webrev.00/
Thanks,
Valeri
On 9/19/2016 11:03 PM, Wang Weijun wrote:
After some thinking, my current opinion is.
1. Maybe NFC is better than NFKD, but I am not a Unicode expert.
It is updated from NFKD to NFD. I did not get the point. Do you mean
NFC is better than NFD?
2. I think the real bug is the order of escap
After some thinking, my current opinion is.
1. Maybe NFC is better than NFKD, but I am not a Unicode expert.
2. I think the real bug is the order of escaping and normalization. The
normalization (if a must) should be performed earlier right after valStr is
created and only performed on valStr.
On 19/09/16 09:10, John Jiang wrote:
Hi,
Please review this fix for JDK-8165566 on test
sun/security/ssl/SocketCreation/SocketCreation.java.
This test takes multiple servers to use one port in sequence, but the
port may not be released by previous server.
This patch takes every server to be alloc
Hi,
Please review this fix for JDK-8165566 on test
sun/security/ssl/SocketCreation/SocketCreation.java.
This test takes multiple servers to use one port in sequence, but the
port may not be released by previous server.
This patch takes every server to be allocated a free port.
Webrev: http://c
13 matches
Mail list logo
