Hi Xuelei,
I did notice that P11Util has a trimZeroes() function, but I didn't call
it since I didn't want to add a new package dependency. But now that you
mention it, moving it to KeyUtil seems like the best solution.
I have submitted a revised patch to the Bugzilla ticket which does
just this:
Thank you for considering this improvement. I'm planing to integrate
the patch into OpenJDK workspace this week.
Thanks & Regards,
Xuelei
On 5/29/2013 3:33 PM, Pasi Eronen wrote:
> Hi Xuelei,
>
> I did notice that P11Util has a trimZeroes() function, but I didn't call
> it since I didn't want
Changeset: 2b3242a69a44
Author:alanb
Date: 2013-05-29 10:24 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2b3242a69a44
8014928: (fs) Files.readAllBytes() copies content to new array when content
completely read
Reviewed-by: martin
! src/share/classes/java/nio/file/Files.ja
Changeset: 92e420e9807d
Author:vromero
Date: 2013-05-29 10:56 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/92e420e9807d
7053059: VerifyError with double Assignment using a Generic Member of a
Superclass
Reviewed-by: mcimadamore
! src/share/classes/com/sun/tools/java
What's the key usage of the OCSP responder? I think it is more like a
problem of Comodo CA. This fix may loosen the checking of the validity
of the OCSP responder's certificate.
Xuelei
On 5/28/2013 7:30 PM, Vincent Ryan wrote:
> Please review the fix for: http://bugs.sun.com/view_bug.do?bug_id=
On 05/29/2013 07:56 AM, Jeff Nisewanger wrote:
The webrev is: http://cr.openjdk.java.net/~jdn/8014097/webrev.0/
The overloads make it cumbersome to use this feature with lambda
expressions:
http://mail.openjdk.java.net/pipermail/security-dev/2013-May/007434.html
Could you rename the varian
The Comodo cert has the 'keyCertSign' and 'cRLSign' keyUsage bits set.
That's unusual but permitted by RFC 5280.
I could have changed the Signature.initVerify method to also accept that
combination of
keyUsage bits but that would affect all signatures. Sean suggested the approach
where
the OCSP
It's OK to me.
At present. there is no risk I can see to loosen the check. I just
worried that if we want to tighten the check again in the future, we may
run into compatibility issues. But for now, it is fine to me.
Thanks,
Xuelei
On 5/29/2013 8:59 PM, Vincent Ryan wrote:
> The Comodo cert ha
Thanks for your review.
On 29 May 2013, at 14:27, Xuelei Fan wrote:
> It's OK to me.
>
> At present. there is no risk I can see to loosen the check. I just
> worried that if we want to tighten the check again in the future, we may
> run into compatibility issues. But for now, it is fine to me.
You are welcome.
BTW, would you like to add a comment in the update so that we won't
tighten the check in the future unintentionally?
Xuelei
On 5/29/2013 9:52 PM, Vincent Ryan wrote:
> Thanks for your review.
>
> On 29 May 2013, at 14:27, Xuelei Fan wrote:
>
>> It's OK to me.
>>
>> At present.
Changeset: 00ad19610e75
Author:vinnie
Date: 2013-05-29 14:57 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/00ad19610e75
7174966: With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo
certificate
Reviewed-by: xuelei
! src/share/classes/sun/security/provider/ce
Comodo used the root cert to sign the responses, which the RFC allows. I think
Java is getting carried away with strictness on this.
--
Sent from my mobile device.
Xuelei Fan wrote:
>What's the key usage of the OCSP responder? I think it is more like a
>problem of Comodo CA. This fix may loo
Right. The Comodo cert is certainly valid. I've modified the OCSP client to
avoid the strict check.
On 29 May 2013, at 15:55, Matthew Hall wrote:
> Comodo used the root cert to sign the responses, which the RFC allows. I
> think Java is getting carried away with strictness on this.
> --
> Sent
Hi,
This fix is an enhancement to add the ability in JSSE server side to
reject client initialized renegotiation.
webrev: http://cr.openjdk.java.net/~xuelei/7188658/webrev.00/
Thanks,
Xuelei
A new system property, "jsse.rejectClientInitializedRenego", is
introduced to reject client initialized renegotiation in server side.
If the system property is set to "true", server side should not accept
client initialized renegotiation, and is expected to fail with a fatal
handshake_failure alert
Hello Xuelei,
This is nice to hear. BTW: my own Bug in that direction never made it through
review, maybe you want to reference ist a well. Not Public: 2381456
There is a number of Security Advisories for this weakness (generic ones,
mainly mentioning other implementations). It might be worth t
On Wed, May 29, 2013 at 07:06:41PM +0200, Bernd Eckenfels wrote:
> PS: i still would prefer to allow applications deal with this by having a
> syncronous handshake listener (would could then count handshake frequency
> and close the socket).
Expecting applications to do this would not be secure
Changeset: 0bf451c0678d
Author:hannesw
Date: 2013-05-27 12:26 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0bf451c0678d
8015348: RegExp("[") results in StackOverflowError
Reviewed-by: sundar, attila
! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/sc
Hi Xuelei,
I suppose my company had, cos I also work for Oracle. :-)
But I'm not related with openjdk and this issue was discovered outside
my work (I was asked by an ex-colleague about the ocsp responder I
commented previously).
Regards!
On 05/29/2013 03:16 AM, Xuelei Fan wrote:
> Hi Ricardo,
Changeset: bd6d3801347b
Author:sla
Date: 2013-05-29 09:42 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd6d3801347b
8015440: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with
RuntimeException
Summary: Make sure serial gc compacts heap every time
Review
Changeset: d685b12b62a4
Author:jjg
Date: 2013-05-29 15:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d685b12b62a4
8015641: genstubs needs to cope with static interface methods
Reviewed-by: ksrini
! make/tools/genstubs/GenStubs.java
On 5/30/2013 1:06 AM, Bernd Eckenfels wrote:
> Hello Xuelei,
>
> This is nice to hear. BTW: my own Bug in that direction never made it through
> review, maybe you want to reference ist a well. Not Public: 2381456
>
Would you mind send me the link of the bug, or the code review request
mail? I m
Am 30.05.2013, 02:18 Uhr, schrieb Xuelei Fan :
2381456
Would you mind send me the link of the bug, or the code review request
mail? I may miss some mails about this direction.
I am afraid I cant sent the link, the Bug is in review state and therefore
not visible for me. It was acknowledged 20
Got it. Yes, this fix is addressing a different issue from you mentioned
below.
Thanks,
Xuelei
On 5/30/2013 9:53 AM, Bernd Eckenfels wrote:
> Am 30.05.2013, 02:18 Uhr, schrieb Xuelei Fan :
>>> 2381456
>> Would you mind send me the link of the bug, or the code review request
>> mail? I may miss s
Changeset: 90df6756406f
Author:sherman
Date: 2013-05-29 19:50 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90df6756406f
4759491: method ZipEntry.setTime(long) works incorrectly
6303183: Support NTFS and Unix-style timestamps for entries in Zip files
7012856: (zipfs) Newly c
25 matches
Mail list logo
