Greetings,
Xuelei wrote:
I think Brad would consider our information for his design.
I did, and thanks for the all of the detailed discussion,
Simone/Michael/Xuelei. I've taken into account the feedback from the
previous discussion back in June. Here is v3 of the public ALPN API.
=
String getCipherSuite()
---
Pretty hard to use this method with the new specification. It's not a
necessary update, see #C9.
I'll come back to this as per above.
Brad
Hope it helps!
Xuelei
On 6/3/2015 8:56 AM, Bradford Wetmore wrote:
Hi,
I have just posted the second
Or I think you could also just remove the args, since there is only one
compareUnsigned currently. Probably safer to use long, long.
Brad
On 6/3/2015 4:06 PM, Joseph D. Darcy wrote:
Hello,
Please review the patch below to address a recently introduced doclint
regression.
Thanks,
-Joe
Hi,
I have just posted the second iteration of the ALPN proposal which
hopefully addresses all of the comments raised here. It is in javadoc
format, but things can certainly be adjusted:
http://cr.openjdk.java.net/~wetmore/8051498/webrev.00/
Please see the archive [1] for previous
inline.
On 5/27/2015 4:47 AM, Simone Bordet wrote:
Hi,
On Tue, May 26, 2015 at 8:46 PM, Bradford Wetmore
bradford.wetm...@oracle.com wrote:
I am not sure I follow this. Can you please sketch the steps/algorithm
that will be done in your proposed solution ?
I'm assuming you are talking about
On 5/26/2015 1:00 AM, Simone Bordet wrote:
Hi,
On Tue, May 26, 2015 at 2:30 AM, Bradford Wetmore
bradford.wetm...@oracle.com wrote:
Darn those Chicken/Eggs [1]!
Yes, you are correct. The steps for the current server code:
1. The ClientHello is parsed, and the SNI matcher callback is called
On 5/22/2015 8:28 PM, Weijun Wang wrote:
On 5/23/2015 9:13 AM, Bradford Wetmore wrote:
Weijun wrote:
But in the RFC the name is in uppercase and chars in string are all
lowercases.
...deleted...
- Compare with equalsIgnoreCase()
Not following here, the spec is specific about
Darn those Chicken/Eggs [1]!
Yes, you are correct. The steps for the current server code:
1. The ClientHello is parsed, and the SNI matcher callback is called.
It does not return which value was matched in the ServerHello, just
whether a SNI name was matched or not:
The extension_data
Thanks for the thorough reviews and comments, I really appreciate it and
always learn something. FunctionalInterface (@since 1.8) is something I
haven't really explored yet, so off to the books.
I'm glad this ALPN approach seems worth pursing. I have several
different comments I'll combine
Hi Thomas,
After reviewing a lot of the back mail and the desires expressed, I have
two orthogonal proposals to make.
The first (next email) is an ALPN-specific API using a simple callback
selector which I think addresses most of the protocol selection concerns.
The second (below) is a
This is a fork of the previous thread:
Subject: TLS Handshake Message Proposal
(Was: Re: JEP 244: TLS Application-Layer Protocol
Negotiation Extension)
I broke this thread off to keep this proposal discussion together, but
if you're interested in the history,
Hi Simone/Thomas/David/others,
Thomas wrote:
would it not be an great idea to combine all these new extensions to
an generic way how to handle the SSL Protocol Handshake ?
I've finally been able to deep dive back into ALPN, specifically looking
at the ideas of a general Hello extension
The draft JEP “TLS Application-Layer Protocol Negotiation Extension” is
now available for community review:
https://bugs.openjdk.java.net/browse/JDK-8051498
This JEP is to add support for the Application Layer Protocol
Negotiation (ALPN) TLS Hello extension [1] in JSSE. ALPN provides a
Looks ok to me too.
Brad
On 1/30/2015 9:10 AM, Mandy Chung wrote:
On 1/30/15 12:50 AM, Alan Bateman wrote:
On 29/01/2015 20:58, Mandy Chung wrote:
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8069551/webrev.00
java.security.acl is superceded by java.security package since
This is a P2 test bug impacting continuous integration:
http://cr.openjdk.java.net/~wetmore/8069038/webrev.00
A recent change missed updating one of the tests.
Pretty straight forward, also corrected one typo.
I don't see this test in the JDK 8 workspace, it's apparently only a 9
thing.
Xuelei/Sean looked at this already (below).
Brad
On 1/23/2015 5:04 AM, Sean Mullan wrote:
On 01/23/2015 02:21 AM, Bradford Wetmore wrote:
JPRT passed. Off to bed.
The fix looks fine to me.
--Sean
On 1/22/2015 10:02 PM, Xuelei Fan wrote:
Looks fine to me.
Thanks,
Xuelei
On 1/23
Jamil,
MAX_LENGTH probably could have been private, but not a big deal.
Nice that it was only SessionID. I did a spot check on the TLS
Extensions and TLS1.0-1.2, do you check on other related TLS RFCs?
Brad
On 1/22/2015 6:27 PM, Xuelei Fan wrote:
Looks fine to me. Thanks!
Xuelei
On
field.
--Jamil
On 01/22/2015 09:57 PM, Bradford Wetmore wrote:
Jamil,
MAX_LENGTH probably could have been private, but not a big deal.
Nice that it was only SessionID. I did a spot check on the TLS
Extensions and TLS1.0-1.2, do you check on other related TLS RFCs?
Brad
On 1/22/2015 6:27
Looks good, thanks for fixing this!
Brad
On 1/15/2015 3:05 AM, Erik Joelsson wrote:
Hello,
Please review the open part of this patch, which changes the building of
policy jars to happen even if BUILD_CRYPTO is false. Previously these
weren't built as there were signed versions of these
Looks good. Thanks.
Brad
On 1/15/2015 4:39 PM, joe darcy wrote:
Hello,
Please review these simple changes to address a few stray deprecation
warnings in the jdk.deploy.osx module:
JDK-8069127: Suppress deprecation warnings in jdk.deploy.osx module
/2015 11:58 PM, Bradford Wetmore wrote:
On 1/1/2015 12:22 PM, Peter Levart wrote:
Hi Brad,
Here's next webrev which tries to cover all your comments:
http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.04/
I downloaded the webrev.05 (Chris' later followup email
On 1/1/2015 12:22 PM, Peter Levart wrote:
Hi Brad,
Here's next webrev which tries to cover all your comments:
http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.04/
I downloaded the webrev.05 (Chris' later followup email) and ran it
through JPRT. The only
Just to followup, I've analyzed the whole PIT run. The second one's
call stack is identical to:
JDK-8067344: Adjust
java/lang/invoke/LFCaching/LFGarbageCollectedTest.java for recent
changes in java.lang.invoke
So, really the only problem is the use of Asserts in your test case.
Brad
I'm looking at this version of the webrev.
http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.03/
I just assigned 8047769 to you. My username is wetmore, Alan is alanb.
On 12/24/2014 3:37 AM, Peter Levart wrote:
Looks like you have a committer status, will
Hi Peter,
Looks like you have a committer status, will you be pushing this?
On 12/18/2014 5:23 AM, Peter Levart wrote:
Hi,
I propose a patch for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8047769
Here's the webrev:
Peter,
Thanks for looking into this.
I'll in the middle of reviewing your change (and TLR/SplittableRandom
reply), but have several appointments over the next few days.
But did want to respond to:
sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.java:
Make sure that when no
I think this is ok.
I have a recollection our Cipher.getInstance() provider selection
mechanism (getTransforms()) allows for missing options:
AES//NoPadding AES/ECB/ But it's been a while since I've looked at
this. These ucrypto values look like they must be completely specified.
Is that
On 12/11/2014 8:02 PM, Weijun Wang wrote:
I'd like to check if SHA-256 is supported without calling
MessageDigest.getInstance(SHA-256). Does such a method exist?
Not that I'm aware of.
Brad
My case is a multi-thread digestor like this:
class Digestor {
Digestor(String alg) throws
Joe,
This looks good to me, but Valerie (PKCS11 owner) and Xuelei (TLS owner)
should also have a look at this.
Brad
On 12/4/2014 3:41 PM, joe darcy wrote:
Hello,
Please review my changes to fix
JDK-8066638: Suppress deprecation warnings in jdk.crypto module
Simone,
Your note was good timing. ALPN and HTTP/2 is on our radar for 9, and
we're starting to look at options now, maybe even using some type of
general extension API. ALPN is pretty straightforward and can be done
easily, but there are advantages to having a full extensions API.
We're
Vote: Yes
Brad
On 11/3/2014 9:28 AM, Sean Mullan wrote:
I hereby nominate Anthony Scarpino to Membership in the Security Group.
Anthony is a member of the Java Security Libraries team at Oracle and
has been an active contributor to the OpenJDK Security Group for
approximately two years.
Worth looking into, but no plans at the moment.
Do you have a link?
Brad
On 10/5/2014 7:44 PM, Bernd wrote:
Hello,
Is there already support for the upcoming getrandom() syscall in Linux
3.17 kernel planned? I guess this would be a good feature for SSL and
the strong SecureRandom variant
javax/crypto/JceSecurity.java
line 79: this could be (PrivilegedExceptionActionVoid) as the
return value is ignored
Good catch.
It may be better to rename URLVerifier to ProviderVerifier as it verifies
the security provider of the given codebase. URLVerifier might give
an
Hi Sean/Mandy/Erik/Magnus/Alan/David/others,
Please review:
JDK-8058845 : Update JCE environment for build improvements
http://cr.openjdk.java.net/~wetmore/8058845/
This change is to alleviate some of the overly-complicated steps we
(Oracle) have in building and maintaining the JCE
I'm not an expert in the JPRT/makefiles for test, but looks good.
Brad
On 9/9/2014 11:45 AM, Sean Mullan wrote:
This seems like a good idea to me. Looks ok to me.
--Sean
On 09/09/2014 01:10 PM, Seán Coffey wrote:
On some recent JPRT test jobs, I've noticed that the jdk_security3 test
On 8/7/2014 3:59 PM, Sean Mullan wrote:
On 08/07/2014 05:03 PM, Jamil Nimeh wrote:
Hello all,
This is just a quick broken-link fix for SecureRandom's javadoc.
http://cr.openjdk.java.net/~ascarpino/8054366/webrev.01
The fix for the broken link looks fine. I think you should double-check
BTW, if you feel like it in any backports, the casts to
SSLHandshakeException weren't needed.
Brad
On 8/1/2014 11:46 AM, Rob McKenna wrote:
Thanks Brad, patch updated, built tested.
-Rob
On 01/08/14 01:39, Bradford Wetmore wrote:
Rob,
Looks ok to me too. There are probably other
Rob,
Looks ok to me too. There are probably other places with RTE's we could
fix, but this will solve the immediate problem.
Two comments to consider:
1. Use a Multi-catch exception. JDK7+.
2. DHCrypt throws IOException. ECDHCrypt throws SSLException (which is
an IOException). Since
On 6/26/2014 4:10 PM, Doug Lea wrote:
This seems to be the best idea yet, assuming that people are OK
with the changes to sun.security.provider.SeedGenerator and
NativeSeedGenerator.java
I've been meaning to review this thread, but have been chasing several
urgent escalations.
Brad
I would prefer that JCE1.2 be pulled out completely in the Cipher*
classes. I will be sending you a separate note about JCE logistics.
Thanks for doing this cleanup.
Brad
On 6/20/2014 11:46 AM, Henry Jen wrote:
Hi,
Please review a trivial webrev to add JDK version to @since in a format
as
Martin,
Thanks for filing. I was positive there was already a bug for this, but
for the life of me I can't find it now. There's some other more minor
cleanup that needs to take place, but seems like I've been in
escalation/firefighting mode for more than a year now and it hasn't
bubbled to
://cr.openjdk.java.net/~henryjen/jdk9/8047721/2/webrev/
Cheers,
Henry
On 06/23/2014 10:04 AM, Bradford Wetmore wrote:
I would prefer that JCE1.2 be pulled out completely in the Cipher*
classes. I will be sending you a separate note about JCE logistics.
Thanks for doing this cleanup.
Brad
/8047721/2/__webrev/
http://cr.openjdk.java.net/~henryjen/jdk9/8047721/2/webrev/
Cheers,
Henry
On 06/23/2014 10:04 AM, Bradford Wetmore wrote:
I would prefer that JCE1.2 be pulled out completely in the Cipher*
classes. I will be sending you a separate note about
On 6/4/2014 2:38 AM, Xuelei Fan wrote:
Webrev toolkit ignore space update so the webrev above looks strange.
The major update is cleanup the indentation. For example, 4 leading
space are removed at line 250 of PKIXValidator.java.
Use the -b option in webrev to force whitespace changes to
Looks ok to me.
Brad
On 6/2/2014 11:15 AM, Sean Mullan wrote:
This is a fix to avoid creating multiple no-perms ACC objects for access
control checks. Since this is required in an uncommon scenario, I used
the Initialization on demand holder pattern to only create it under
those
No additional code review necessary, this is just an FYI.
For internal reasons (i.e. we have to sign our JCE jar files), we have
separated the JCE portion for:
8041679: Replace uses of StringBuffer with StringBuilder within the JDK
into:
8043342: Replace uses of StringBuffer with
Whoo Hoo. :)
Looks good.
Brad
On 5/15/2014 4:11 PM, Valerie (Yu-Ching) Peng wrote:
Tony,
Can you please help reviewing this PKCS11 provider configuration file
change?
This is for removing the digest related mechs from the disabledMechanism
section now that relevant native bugs have been
I still need an official reviewer.
Thanks for looking into this, I was going check into it today if you
didn't. I figured it must be something in byte comparison. Sure enough.
Good catches! :) That code's been in there a long time!
Only nit is Copyright Dates if you choose to update.
We usually update the copyright dates:
* Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights
reserved.
javax/security/auth/kerberos/package-info.java
==
yes, or no, case-insensitive.
-
yes, or no, and values are case-insensitive.
I
Thanks Weijun,
The main class is fine.
In the test case, I would suggest adding a comment before the
InvalidAlgorithmParameterException that some engines require certain
parameters to be be present on creation, and a newInstance(null) will
trigger that exception.
HTH,
Brad
On 4/15/2014
We generally update the copyright dates to 2014.
Since you are changing line numbers, please work with the JCE team to
get the JCE provider rebuilt/signed/integrated.
make/closed/tools/crypto/jce/jce.jar
I wasn't aware of the trade;, nice to know! ;)
Thanks,
Brad
On 4/15/2014 5:24
There is a similar one for HttpsURLConnection, as we had problems in the
past where the networking changes didn't update the SSL code.
jdk/sun/net/www/protocol/https/HttpsURLConnection/CheckMethods.java
Just a reminder to please include the JSSE reg tests when making
sides if someone has a
strong case.
Brad
On 04/04/2014 22:23, Bradford Wetmore wrote:
With the current and proposed code, you are effectively requiring the
MAC come from JCE, as all the algorithms exist in SunJCE.
IIRC, when we discussed the previous change in this area, the idea
With the current and proposed code, you are effectively requiring the
MAC come from JCE, as all the algorithms exist in SunJCE.
IIRC, when we discussed the previous change in this area, the idea was
that the MAC would follow the standard JCA provider priority ordering.
Brad
On 4/4/2014
On 3/19/2014 5:50 PM, Xuelei Fan wrote:
I was wondering to expose this
application layer as a configurable parameter.
Just to make sure we're talking about the same thing, you're pointing out:
1. The need for determining the PMTU for the various protocol types.
(UDP/DCCP/TCP/SCTP/etc)
Rajan,
All of the tests I looked at have incorrectly modified copyright
information. Please fix and then I can push.
Copyright (c) 2005, 2006, Oracle and/or its affiliates. All rights reserved.
should be:
Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved.
Not:
*
bug, how can one add comments and updates? I have bugs
submitted 4 years ago (e.g. http://bugs.java.com/view_bug.do?bug_id=8014369)
that are still listed as In progress and I don't see any way to add a
comment.
Bradford Wetmore wrote:
I've added the stack trace to the report.
I've added the stack trace to the report.
Thanks!
Brad
On 2/19/2014 9:59 PM, Stefan Liebig wrote:
Hi,
I would like to add a comment to an existing bug:
- http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8028627
- https://bugs.openjdk.java.net/browse/JDK-8028627
The problem described in
Looks ok to me, with the exception as you pointed out that this doesn't
follow section 4 of RFC 6460. Why was this done, and how did you
originally determine the original ciphersuite ordering for GCMs?
Brad
On 12/29/2013 7:56 PM, Xuelei Fan wrote:
Hi,
Please review this small update.
On 1/3/2014 6:19 PM, Xuelei Fan wrote:
On 1/4/2014 6:41 AM, Bradford Wetmore wrote:
Looks ok to me, with the exception as you pointed out that this doesn't
follow section 4 of RFC 6460.
Sorry, I did not get it. Would you mind point out the line number of
the concern?
This section in RFC
Looks good.
As I mentioned in another thread, you'll need to wait for Joe's change
(JDK-8000962) which I just also reviewed, otherwise when you run the
regression tests for the closed, newly built signed jar files, one will
fail due to baked-in spec/impl version being off.
brad
On
I really don't think formatting changes as part of other approved
changes would be taboo. Joe Darcy has the same opinion. I would
restore, but too late now. I knew I should have got to this email
earlier. :)
One question, I haven't tried this out, but will the simple @since 8
additions
Roger,
Jon is correct, we had several options for test stabilization, including
fixing several dozen tests that were written a decade before -agentvm
came into being. See the bug and this external link for more details:
jtreg team? I am not aware of one. Jon Gibbons works on this in his
spare time.
I would call him the JTREG team.
Was there an ETA for this? Balancing recent test stabilization efforts
with this, you may consider consider adding othervm and then back it out
when the JTREG fix is made.
lines! ;)
Brad
On 11/27/2013 12:46 PM, Anthony Scarpino wrote:
On Nov 27, 2013, at 10:12 AM, Sean Mullan sean.mul...@oracle.com wrote:
On 11/26/2013 08:20 PM, Bradford Wetmore wrote:
Tony,
I note the @since's are missing for the new methods, both in the
generated output in the overridden
Where did this workaround suggestion come from?
Please link these two issues (JDK-6978415) together.
Have you talked to the network team about this?
brad
On 11/26/2013 6:09 PM, Xuelei Fan wrote:
This change looks fine.
JSSE regression tests use a lot of code as new ServerSocket(0), we
Tony,
I note the @since's are missing for the new methods, both in the
generated output in the overridden methods (i.e. no javadoc), and the
methods in which you've changed the behavior (i.e. new javadoc).
I'm not sure what you can do about the previous behavior (cc'ing
Mike/Sowmya, maybe
On 11/19/2013 4:19 PM, Rajan Halade wrote:
I am working towards fixing JDK-8027598
https://bugs.openjdk.java.net/browse/JDK-8027598, there are multiple
options available here and would appreciate your thoughts on this. It
was filed to address the issue at large reported inJDK-8027526
On 11/19/2013 5:07 PM, Xuelei Fan wrote:
On 11/20/2013 8:19 AM, Rajan Halade wrote:
I am working towards fixing JDK-8027598
https://bugs.openjdk.java.net/browse/JDK-8027598, there are multiple
options available here and would appreciate your thoughts on this. It
was filed to address the issue
Looks good, thanks for looking at this, Dan!
Brad
On 10/31/2013 3:05 PM, Dan Xu wrote:
Hi All,
Please help review a simple change towards the testcase,
TestProviderLeak.java.
In the call of SecretKeyFactory.getInstance(), it will try to access
files under temporary directory by calling
https://bugs.openjdk.java.net/browse/JDK-8027526
http://cr.openjdk.java.net/~wetmore/8027526/webrev/
Alan was getting some test failures, I'm 95% sure it's due to a provider
being inserted one of two tests and being run with agentvm.
According to Jon Gibbons, agentvm does not reset the
*facepalm*
CR withdrawn...it must be the one in the closed repo then. Thanks Mandy.
Brad
On 10/30/2013 2:37 PM, Mandy Chung wrote:
On 10/30/2013 2:25 PM, Bradford Wetmore wrote:
https://bugs.openjdk.java.net/browse/JDK-8027526
http://cr.openjdk.java.net/~wetmore/8027526/webrev/
32
I'm still going to change the name of the provider, the name test was
resulting in failure mode:
test failed: some condition
which of course wasn't obvious where test was coming from.
Brad
On 10/30/2013 2:45 PM, Bradford Wetmore wrote:
*facepalm*
CR withdrawn...it must be the one
Changeset: f731d096530f
Author:wetmore
Date: 2013-10-30 16:49 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f731d096530f
8027526: CheckTipsAndVersions.java failing occasionally
Reviewed-by: mullan, mchung
! test/java/security/Signature/SignatureGetAlgorithm.java
Changeset: a45acc8de0f3
Author:wetmore
Date: 2013-10-16 23:32 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a45acc8de0f3
8026762: jdk8-tl builds windows builds failing in corba - javac: no source files
Reviewed-by: katleman, dholmes
! makefiles/GenerateClasses.gmk
Changeset: 1a71d800b032
Author:wetmore
Date: 2013-10-16 23:31 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/1a71d800b032
8026762: jdk8-tl builds windows builds failing in corba - javac: no source files
Reviewed-by: katleman, dholmes
! makefiles/BuildCorba.gmk
Looks ok to me.
Brad
On 10/11/2013 12:10 PM, Sean Mullan wrote:
Looks good, just add a noreg-trivial tag to the bug.
--Sean
On 10/11/2013 02:41 PM, Vincent Ryan wrote:
Please review this fix to close output stream in DomainKeyStore:
Bug: https://bugs.openjdk.java.net/browse/JDK-8026301
On 9/27/2013 4:49 PM, Valerie (Yu-Ching) Peng wrote:
Xuelei,
Since the source for OracleUcrypto provider isn't included in OpenJDK,
it probably makes more sense to have its regression tests off OpenJDK as
well. Please find the changes for the test relocation under 8014374:
Webrev:
This minor suggestion came up in May from our JCK team:
https://bugs.openjdk.java.net/browse/JDK-8014838
http://cr.openjdk.java.net/~wetmore/8014838/webrev.00/
JCK suggested all implementations should have at least one strong random
implementation.
I've also changed the error case
Same.
Brad
On 9/1/2013 7:45 PM, Weijun Wang wrote:
Code change looks fine.
--Max
On 9/2/13 10:41 AM, Xuelei Fan wrote:
On 9/2/2013 10:38 AM, Xuelei Fan wrote:
Hi Weijun,
Please review this simple test fix. There is a typo in the test. The
issue is exposed after the fix of JDK-8023881.
Looks good to me, but Xuelei (owner) might want to have a quick look.
Brad
On 8/23/2013 2:34 PM, Joe Darcy wrote:
Hello,
Please review the patch below which resolves several doclint issues in
javax.net.ssl.
Thanks,
-Joe
diff -r 4ef82445ea20
Martin,
Your fix looks good to me, just need a test case to putback. Should be
pretty straightforward to create a custom SecurityManager that throws a
ACE instead of a SE during a checkRead(), and then link together.
Brad
On 8/21/2013 3:51 PM, Martin Buchholz wrote:
Adding Alexey Utkin,
Ditto.
brad
On 8/19/2013 12:08 PM, Sean Mullan wrote:
Looks fine.
--Sean
On 08/19/2013 02:52 PM, Anthony Scarpino wrote:
Hi,
I need a very simple review on enabling a test
http://cr.openjdk.java.net/~ascarpino/8022896/webrev.00/
thanks
Tony
Changeset: 11c15607e43f
Author:wetmore
Date: 2013-07-05 18:22 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11c15607e43f
8019341: Update CookieHttpsClientTest to use the newer framework.
Reviewed-by: xuelei, smarks, michaelm
!
Changeset: 116050227ee9
Author:youdwei
Date: 2013-06-17 17:36 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/116050227ee9
8014620: Signature.getAlgorithm return null in special case
Reviewed-by: wetmore
! src/share/classes/java/security/Signature.java
+
Changeset: b600d637ef77
Author:wetmore
Date: 2013-04-25 17:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b600d637ef77
8012530: test/sun/security/provider/SecureRandom/StrongSeedReader.java failing
Reviewed-by: wetmore
Contributed-by: alan.bate...@oracle.com
!
Changeset: 6379415d8fca
Author:wetmore
Date: 2013-03-12 15:31 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6379415d8fca
8009925: Back out AEAD CipherSuites temporarily
Reviewed-by: valeriep
! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java
!
EngineOutputRecord.java
===
294/296: Another great comment. I might suggest reversing the
comments so that the comment about AEAD is in the AEAD arm, and CBC is
outside.
I'm not sure I catch your ideas. ;-) Would you please show me the code?
Just a simple reversal of
Changeset: 940c8cc5a5c4
Author:wetmore
Date: 2012-10-23 12:36 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/940c8cc5a5c4
7197071: Makefiles for various security providers aren't including the default
manifest
Reviewed-by: valeriep, mullan, katleman
!
Changeset: 13b46e8eda33
Author:ohrstrom
Date: 2012-10-23 15:51 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13b46e8eda33
8001419: Build the JCE portion of JDK-8000970
Summary: Original code done by Fredrik Ohrstrom, separated/pushed by wetmore
Reviewed-by: wetmore
!
Yes, that's what I meant. Just that none of the other functions alloc'd
memory internally that you had to manually free.
Thanks for checking.
Brad
On 10/19/2012 5:54 PM, John Zavgren wrote:
Brad:
I'm not sure that I completely understand your question, because this is C code
and there are
On 10/10/2012 7:54 PM, Xuelei Fan wrote:
No new webrev. I need a review of how to use SNIMatcher. See bellow
inline comments.
On 10/11/2012 7:38 AM, Brad Wetmore wrote:
On 10/10/2012 5:47 AM, Xuelei Fan wrote:
new webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev.13/
I guess
On 8/14/2012 7:45 PM, Xuelei Fan wrote:
197: You're not planning to process (e.g.
ServerHandshaker/ClientHandshaker.process_message) the consumed
handshaking bytes immediately during the createSocket call, are you? You
still need to allow the user time to set the socket
How would the ServerHello be generated until you call this method and
then start the handshaking on the returned SSLSocket?
One can use SSLEngine.wrap()/unwrap() to generate handshaking messages
from socket I/O stream.
// accept a socket
// read/write the I/O with SSLEngine
//
Looks good to me also.
Brad
On 5/17/2012 6:24 AM, Vincent Ryan wrote:
Your fix looks fine. However you don't need to modify the file-separator
on Windows - both forms are supported in pathnames.
On 05/17/12 01:54 PM, Xuelei Fan wrote:
Hi,
Please review the fix of test cases in Windows.
Changeset: 6438f1277df6
Author:wetmore
Date: 2012-05-09 16:33 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6438f1277df6
7167362: SecureRandom.init should be converted, amendment to 7084245
Reviewed-by: sherman
! src/share/classes/sun/security/provider/SecureRandom.java
Hi Xuelei,
Can you put these CR requests on cr.openjdk.java.net? I can't see them
from home.
Brad
On 5/5/2012 8:06 AM, Xuelei Fan wrote:
The webrev URL should be:
http://javaweb.us.oracle.com/~xufan/bugbios/7166570/webrev.00/
Xuelei
On 5/5/2012 9:38 PM, Xuelei Fan wrote:
Hi,
Please
Changeset: 10480cf00dcd
Author:wetmore
Date: 2012-04-11 17:12 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/10480cf00dcd
7157903: JSSE client sockets are very slow
Reviewed-by: xuelei
! src/share/classes/sun/security/ssl/AppOutputStream.java
!
Changeset: 7a7dcbbd610f
Author:wetmore
Date: 2012-03-30 15:43 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a7dcbbd610f
7142172: Custom TrustManagers that return null for getAcceptedIssuers will NPE
Reviewed-by: xuelei
!
Changeset: b16cbeb0d213
Author:wetmore
Date: 2012-02-10 19:07 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b16cbeb0d213
7142509: Cipher.doFinal(ByteBuffer,ByteBuffer) fails to process when
in.remaining() == 0
Reviewed-by: valeriep
!
401 - 500 of 560 matches
Mail list logo
