Looks fine to me too.
Brad
On 3/6/2012 6:28 AM, Sean Mullan wrote:
Please review the following fix to correct an issue in 7u4 with the
system-specific java.security files being out-of-sync.
webrev: http://cr.openjdk.java.net/~mullan/webrevs/7146431/webrev.00/
Thanks,
Sean
there has been some inconsistency in
different vendors implementation since people interpret what they read
differently.
Valerie
On 02/29/12 23:00, Brad Wetmore wrote:
On 2/21/2012 5:33 PM, Valerie (Yu-Ching) Peng wrote:
Brad,
Can you please review the fixes for the following 2 bugs:
* 7146728
On 2/21/2012 5:33 PM, Valerie (Yu-Ching) Peng wrote:
Brad,
Can you please review the fixes for the following 2 bugs:
* 7146728: Inconsistent length for the generated secret using DH key
agreement impl from SunJCE and PKCS11
o
.
Mike
At 02:00 AM 3/1/2012, Brad Wetmore wrote:
On 2/21/2012 5:33 PM, Valerie (Yu-Ching) Peng wrote:
Brad,
Can you please review the fixes for the following 2 bugs:
* 7146728: Inconsistent length for the generated secret using DH key
agreement impl from SunJCE and PKCS11
Looks ok to me too, but it seems a shame to keep this SecureRandom
instance for a single test (AES_256) during cipher initialization. Once
the condition is test, and the result is added to the cache, the
SecureRandom instance is never used again.
Brad
On 2/15/2012 8:03 AM, Chris Hegarty
Have you done a full pubs/javadoc target to make sure the path will
resolve correctly? The location seems to be ok.
Brad
On 2/10/2012 6:50 PM, Xuelei Fan wrote:
webrev: http://cr.openjdk.java.net/~xuelei/7144781/webrev.00/
In javax.net.ssl java doc, the URL for the Java Cryptography
Two line code fix, but an important couple of lines. :)
The underlying cipher still had buffered data when using Direct
ByteBuffers. This changes makes sure that data is read out.
7142509: Cipher.doFinal(ByteBuffer,ByteBuffer) fails to process
when in.remaining() == 0
Description:
Still looks good, thanks for making the minor style corrections. :)
Cheers,
Brad
On 2/8/2012 1:18 AM, Vincent Ryan wrote:
Please review the following change:
http://cr.openjdk.java.net/~vinnie/7142339/webrev.00/
for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142339
It employs
7141910: Incorrect copyright dates on new test cases.
http://cr.openjdk.java.net/~wetmore/7141910/
Big sigh,
Brad
.
This is a minor change, so I'll probably just check in following JPRT.
If you're interested, the update is in the same location:
http://cr.openjdk.java.net/~wetmore/7126889
but iteration *.01.
Brad
Thanks,
Xuelei
On 1/26/2012 1:15 PM, Brad Wetmore wrote:
Xuelei (or anyone else
Xuelei (or anyone else available to review this 1-line change),
7126889: Incorrect SSLEngine debug output
The JSSE debug information is currently reporting one extra byte being
written out, but is not actually doing that. This is just a simple
adjustment to correct that error.
Looks good also...
Brad
On 1/23/2012 4:27 AM, Xuelei Fan wrote:
Remove the serviceabilty-dev.
Thanks for the quick code review.
Xuelei
On 1/23/2012 8:25 PM, Alan Bateman wrote:
On 23/01/2012 12:21, Xuelei Fan wrote:
Webrev: http://cr.openjdk.java.net/~xuelei/7132248/webrev.00/
In JDK
I'm just one person, but I'm completely open to discussing on
security-dev potential names/values to add. I do have strong
hesitations about just opening it up to anyone to add something (i.e. a
wiki), allowing them to reserve names with no discussion. (I'm thinking
what a mess it could be
Not a big deal here, but Weijun was CR'er but you listed me in
changeset. FYI, I also approve.
Brad
On 11/14/2011 12:52 AM, Weijun Wang wrote:
Looks fine.
-Max
On 11/14/2011 04:45 PM, Xuelei Fan wrote:
webrev: http://cr.openjdk.java.net/~xuelei/7111548/webrev.00/
Simple fix, cleanup,
SSLSocketSSLEngineTemplate
*
* SunJSSE does not support dynamic system properties, no way to
* re-use system properties in samevm/agentvm mode.
+* @run main/othervm SSLSocketSSLEngineTemplate
*/
Thanks,
Xuelei
On 10/29/2011 8:48 AM, Brad Wetmore wrote:
Hi Andrew,
Wrapping up some loose
Hi Valerie,
http://cr.openjdk.java.net/~wetmore/7053252/
Review 7053252: New regression test does not compile on windows-amd64
As you know, there is a broken JDK test on windows-x64 under the
jdk_security3 target (no pkcs11 library, thus the import fails on
compile). Someone has to
Hi Andrew,
Wrapping up some loose ends. I was thinking it would be a good idea to
put the test case for the recent Bad MAC error into the JSSE test
template directory. It might be useful to have a SSLSocket client that
can easily talk to a SSLEngine server. If we keep this test buried down
Hi Valerie,
http://cr.openjdk.java.net/~wetmore/7105792/
7105792: Remove sun/security/pkcs11/Provider/Absolute.java from JPRT
testing. No windows-x64 impl.
As you know, there is a broken JDK test on windows-x64 under the
jdk_security3 target. It doesn't compile due to a missing library
On 10/15/2011 8:52 AM, Brad Wetmore wrote:
Hi Xuelei,
I need code reviews for the bug I mentioned to you earlier.
7031830: bad_record_mac failure on TLSv1.2 enabled connection with
SSLEngine
The MAC calculation was summing the wrong data range when using
non-direct byte buffers and TLS1.1/1.2
IV field isn't
being properly handled.
Brad
-Max
On 10/15/2011 08:59 AM, Brad Wetmore wrote:
I'll need a second codereviewer for the 7u2 change. Valerie/Sean/Max?
Brad
On 10/14/2011 5:52 PM, Brad Wetmore wrote:
Hi Xuelei,
I need code reviews for the bug I mentioned to you earlier
Hi Xuelei,
I need code reviews for the bug I mentioned to you earlier.
7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine
The MAC calculation was summing the wrong data range when using
non-direct byte buffers and TLS1.1/1.2.
The new regression test will now
I'll need a second codereviewer for the 7u2 change. Valerie/Sean/Max?
Brad
On 10/14/2011 5:52 PM, Brad Wetmore wrote:
Hi Xuelei,
I need code reviews for the bug I mentioned to you earlier.
7031830: bad_record_mac failure on TLSv1.2 enabled connection with
SSLEngine
The MAC calculation
implementation.
Thanks,
Sasha
On 7/18/2011 5:33 PM, Brad Wetmore wrote:
(Apologies to folks without access to the older sources.)
On 07/18/11 15:00, Sean Mullan wrote:
On 7/18/11 5:35 PM, Alexandre Boulgakov wrote:
Is there an easy way to see when a class was added to the JDK?
For standard
SOFTTOKEN_DIR is used to override the default token directory location.
(Usually $HOME).
Brad
On 8/13/2011 9:42 AM, Alan Bateman wrote:
Weijun Wang wrote:
CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7078816
webrev: http://cr.openjdk.java.net/~weijun/7078816/webrev.00/
Why do you need the syncronchized (credentialsMap) at line 344?
Aren't all writes done during the constructor init?
Otherwise, looks ok.
Brad
On 8/7/2011 8:43 PM, Xuelei Fan wrote:
webrev: http://cr.openjdk.java.net/~xuelei/7063647/webrev.00/
SunX509KeyManagerImpl should be multiple thread
(Apologies to folks without access to the older sources.)
On 07/18/11 15:00, Sean Mullan wrote:
On 7/18/11 5:35 PM, Alexandre Boulgakov wrote:
Is there an easy way to see when a class was added to the JDK?
For standard API classes, you can use the @since javadoc tag which will indicate
the
Sean/Valerie/Max/Xuelei,
Hello Brad,
Could you please review these changes?
I'm swamped again, can one of you take a look at Sasha's changes?
Brad
On 7/11/2011 1:56 PM, Alexandre Boulgakov wrote:
Hello Brad,
Could you please review these changes?
Bug detail:
A little late, but Ditto.
Brad
On 7/6/2011 8:00 AM, Vincent Ryan wrote:
All looks good.
On 07/05/11 21:58, Sean Mullan wrote:
Hi Vinnie,
Can you review this one:
http://cr.openjdk.java.net/~mullan/webrevs/7054969/webrev.00/
--Sean
While I was thinking the same thing as Sean/Stuart, it's not clear how
much risk you would be refactoring a lot of code just to use this
language feature.
It's pretty clear (to me anyway) what you were intending here.
Brad
On 6/28/2011 1:31 PM, Stuart Marks wrote:
On 6/28/11 11:46 AM,
Ditto.
brad
On 6/23/2011 6:03 AM, Sean Mullan wrote:
Looks good.
--Sean
On 6/22/11 11:51 PM, Xuelei Fan wrote:
bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057022
webrev: http://cr.openjdk.java.net/~xuelei/7057022/webrev.00/
Thanks,
Xuelei
On 5/12/2011 10:49 AM, Omair Majid wrote:
Hi,
Deepak Bhole posted this bug on the openjdk bugzilla a little while ago,
but it seems to have fallen through the cracks:
https://bugs.openjdk.java.net/show_bug.cgi?id=100142
Yes it did. That was about a year ago.
as to not mess up review threads).
Just a question weather this NSA Suite B effort will mean that some
attention will be given to ECC ciphers and PKCS#11 in JDK 7?
We have a few fix requests submitted in this area.
Regards,
Tomas
On 04/07/2011 06:46 AM, Brad Wetmore wrote:
Hi Xuelei/Valerie
Hi Xuelei/Valerie,
Our JDK 7 freeze window is fast closing and I'd like to get this in for
b140, so will need a quick turnaround to make this happen.
7031343: Provide API changes to support future GCM AEAD ciphers
As we talked about, as part of the National Security Agency's Suite B
effort
/solaris/native/sun/security/pkcs11
./share/classes/sun/security/pkcs11
./share/native/sun/security/pkcs11
./windows/native/sun/security/pkcs11
Brad
On 4/13/2011 7:59 AM, Albert Ciffone wrote:
Hi,
Finally I can compile security.cpp and gets a sunmscapi.dll for 64bits.
I use this dll with
On 3/24/2011 6:49 AM, Sean Mullan wrote:
Max, Freda,
Could you please review this webrev for a batch of translatability bugs:
http://cr.openjdk.java.net/~mullan/webrevs/7019937_et_al/webrev.00/
KeyTool.java:
=
Looks good. Only minor comments about line length, which is kind of
To use those EC curves in TLS, IANA need to register these curves[*].
Do you know any effort to use these curves in TLS?
Xuelei was primarily asking about this from the TLS perspective. RFC
5639 just claims its use would be consistent with the existing TLS ECC
approaches, but I don't know
On 12/23/2010 11:42 AM, Stuart Marks wrote:
On 12/22/10 6:19 PM, Brad Wetmore wrote:
Using the diamond operator definitely makes the code *shorter*. Whether
it's *better* doesn't necessarily follow from that. In most cases,
though, using diamond is better, I think.
I'd be curious if you
Minor nit, can you add a space in line 221 between
BigInteger,BlindingParameters
[and Max replied]
I thought the formal style is no-space. At least in Map.java it's
public interface MapK,V.
I'm not familiar with any formal style. The original Java code
conventions doc [1] hasn't been
HomerSimpson
If people update it themselves, manually, then they avoid an additional
changeset modifying
their files. So it's still ok for people to manually update the second
year.
But it can be considered optional again.
Whoo hoo!
And SunJDK 6/5/1.4.2? (Sorry, OpenJDK folks, but had to
On 12/23/2010 7:21 AM, martin.c...@bt.com wrote:
Brad,
Has there been any move to support TLS in oracle JRE?
I'm a little confused by the question, or maybe the confusion lies in
how the OpenJDK 7 is part of OracleJDK. We take the OpenJDK 7 source
and make some modificiations (adding in
You need to update the Copyright updates on these files to include 2010.
Not having a lot of experience yet with , the only ones I wasn't sure
about were the ones in X509Factor.parseX509orPKCS7Cert. (line 415
425) I assume it just picks up the outer return type?
Minor nit, can you add a
For the TBD tests, we sort of just let them run, i.e. through the
getInstance(), init(..), generateKey(), and don't enforce the actual
result to match the expected result.
Hm...that's unfortunate. I guess I don't see a better way to do it either.
I've been so focused on getting TLS 1.2 done, this has been really low
priority.
6687725: Internal PKCS5Padding impl should throw
IllegalBlockSizeException and not BadPaddingException
Webrev - http://cr.openjdk.java.net/~valeriep/6687725
Should you continuing to check for negative
Offhand, they look pretty straight forward. I'd like to look closer,
but can't right away. Need to stay focused on something else the rest
of the week.
Brad
On 8/31/2010 5:20 PM, Valerie (Yu-Ching) Peng wrote:
Hi, Brad,
Do you have time to review these two PKCS11 fixes? They are
As we discussed here, this looks fine.
Brad
On 6/8/2010 8:31 AM, Joe Darcy wrote:
Thanks Martin and Rémi for the quick reviews!
Upon further consideration, before doing the push I decided to look for
instances in the jdk repo where this new constructor could be used and I
found one in
I have a couple important tasks to finish ASAP, so if there is more
discussion, I'll have to jump in sometime next week, but wanted to add
one thing before anything was done:
Pavel wrote:
And we can use other URL if verisign.com is problematic.
We've tried to limit the reliance on servers
You missed my point. I was saying that you could make the Command and
Options enums (line 152/234) private. Should have been more explicit.
Brad
Max (Weijun) Wang wrote:
On Feb 3, 2010, at 2:04 PM, Brad Wetmore wrote:
Enum could be private? Otherwise, looks fine.
The program compiles
Looking for opinions as to whether the current subject line format of
the security-...@o.j.n emails is useful:
Subject: [security-dev 01800]: The Real subject.
I note a lot of the client (e.g. sounds, swing) lists have just the list
name, and a lot of the server lists (e.g. tl, hotspot)
Looks good. You could mention that class in a comment to make it clear
what might show up here.
} catch (IOException ioe) {
// e.g. sun.security.pkcs.ParsingException
if (debug != null) debug.println(processEntry caught:
Brad
Alan Bateman wrote:
I need a reviewer for
Vincent Ryan wrote:
I'm proposing a change that enables JSSE to work when Kerberos is not present
at runtime:
http://cr.openjdk.java.net/~vinnie/6885204/webrev.00/webrev/
DelegateHttpsURLConnection.java/HttpsClient.java
Can you put in a
(I sent to the wrong alias, resending to open list-darn Thunderbird
auto-completion has struck again. I will forward Mark's reply in a minute.)
Hi Mark,
On Thu, 2008-11-20 at 18:54 +0100, Mark Wielaard wrote:
Mark Wielaard wrote:
It seems this is working out good for the GNU/Linux distros
Yes, core owns BigInteger (specifically Joe Darcy).
brad
Christian Thalinger wrote:
On Mon, 2009-04-20 at 21:03 +0800, Max (Weijun) Wang wrote:
Hi Christian
The patch is very good, and much clearer than the previous
implementation. I will include it in the fix.
Are you also responsible
Thanks, Tom, I was going to mention that.
The question comes up every now and then, but hasn't been generally
applied to the general Java community because of the lack of wide-spread
underlying OS support. Generally the approach taken by most folks is to
run JVM's at different levels, or
If you want to see the source change now, check out the changeset:
http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b89ba9a6d9a6
This change will not be seen immediately in the JDK7 snapshot source and
binaries. As you may know, we use a series of subgates to make
development and testing easier,
Thanks! Glancing at the changes, they look good.
One comment tho, this probably should have been grouped together with
Valerie's fix. jcheck only allows for one putback per bug id, so we may
need to file a separate bug for her part.
Brad
xuelei@sun.com wrote:
Changeset: 85fe3cd9d6f9
// Create and initialize a SSLContext, from which you obtain a
// SSLSocketFactory, sslssf
ServerSocket ss = new ServerSocket(port);
Socket s = ss.accept();
SSLSocket sslSocket = slssf.createSocket(s,
s.getInetAddress().getHostName(), s.getPort(), false);
Kanatoko,
I'm trying to get caught up on much back email. Sorry for the delay.
Earlier you wrote:
This SSLSocketImpl instance 'tmp' does not handle any TCP( or SSL )
connections, so sockOutput is always null.
This method 'checkEnabledSuites()' is called only once for each
SSLServerSocket
I got brought into a high priority escalation for the last couple weeks,
I'm think I'm finally coming to the end and will respond then. I owe
several responses.
This really has been an insane couple of months.
Brad
Mark Wielaard wrote:
Hi,
On Thu, 2008-10-02 at 11:49 +0200, Mark
could do to help.
I have now also tested the nCipher HSM. To get their p11 working my patch had
to be applied.
Do you have any idea when we the fix could be released?
Are you looking for JDK7, or 6?
Brad
Best Regards
Brad Wetmore wrote:
Lars Silvén wrote:
Hi Brad,
I have written a simple
parameters and then you get a description
of needed parameters.
Lars
Brad Wetmore wrote:
Great, thanks for doing so.
I'll be working on this fairly soon, so I'll get a bug filed. Do you
have a standalone test case for this already? See step 3 of the
contribute page. If you do but you don't have
Only had two minor putbacks this time around, we'll give our SQE team a
break. :)
Brad
The current policy is still one putback per bugid. There have been
other really good reasons to allow more than one (pre-built JCE
binaries), but so far no change in the policy. I still do wish it were
changed, as filing a separate bug just to do a JCE build is wasted work,
IMHO.
Although
Last night there was a changeset introduced to the JSN gate that
contained an incorrect changeset comment. Rather than pollute the
changeset history for everyone, we're going to rollback this changeset,
and have the author redo his changeset and push.
Since this problem was noticed within
Are there any decision to include any native ECC provider like NSS ?
There might have been some discussion at some point, but as far as I
know, there have never been any plans recently (last 3-4 years) to
bundle a third party native crypto provider into JDK.
Our current recommendation is
of SSLContextFactory?
We have integrated Bruno's library in our Restlet 1.1 version and find
it very useful. It would be great to have similar support straight from
the JDK.
Best regards,
Jerome Louvel
http://www.restlet.org
Brad Wetmore a écrit :
Hi Bruno,
Just to give you a quick update, some of us
Hi,
This morning's networking changeset in the JSN gate appears to have
broken several of the reg/unit tests under 64-bit.
6730740: Fix for 6729881 has apparently broken several 64
bit tests: Bad address
The TL gate normally closes and builds for PIT at 10pm PST tonight
As per: http://openjdk.java.net/projects/jdk7/builds/
Our first mercurial integration for b25 into the MASTER is next Friday,
so in order to get our PreIntegration Testing (PIT) done in time, our
JSN codefreeze will be Monday at noon (Pacific time), so we can get the
JSN changes into the
deepak sahu wrote:
We have fullfledged concept fo how to generate points on EC and are
working on new blind signature concept.
We have also implemented our idea in java.
Any one can guide us in including thi RFE into jdk7
I'm sorry for the delay, in addition to working on JCE, I am also
101 - 168 of 168 matches
Mail list logo
