On 2015-05-22 02:46, Mandy Chung wrote:
I’m including build-dev and we need to ask for Erik and Magnus advice what’s
the best way to work around this.
Erik, Magnus,
Security providers now become service providers. They are provided from 11
different modules, 3 of them are os-specific. T
On 22/05/15 07:58, Erik Joelsson wrote:
On 2015-05-22 02:46, Mandy Chung wrote:
I’m including build-dev and we need to ask for Erik and Magnus advice
what’s the best way to work around this.
Erik, Magnus,
Security providers now become service providers. They are
provided from 11 different
This is the second in a series of fixes for JEP 232 (Improve Secure
Application Performance) [1].
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8065233/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8065233
This fix removes some obsolete synchronization code from the Policy
impl
Looks good.
Are you also going to remove the policy.ignoreIdentityScope definition
inside jdk\src\java.base\share\conf\security\java.security?
Thanks
Max
On 5/22/2015 10:25 PM, Sean Mullan wrote:
This is the second in a series of fixes for JEP 232 (Improve Secure
Application Performance) [1
On 05/22/2015 10:33 AM, Weijun Wang wrote:
Looks good.
Are you also going to remove the policy.ignoreIdentityScope definition
inside jdk\src\java.base\share\conf\security\java.security?
Good catch. I thought that had been removed as part of JDK-6876158. Let
me think this over a bit first.
-
On 22/05/2015 13:55, Chris Hegarty wrote:
:
I think it could be done either way.
Valerie - have you considered not pushing the services configuration
files with this change? With the change then the java.security
configuration is still class names, not provider names, so the fallback
should
On 05/21/2015 06:02 PM, Thomas Lußnig wrote:
Hi,
most of it look ok for me, but in
"http://cr.openjdk.java.net/~vinnie/8062552/webrev.01/src/share/classes/sun/security/util/KeyStoreDelegator.java.patch";
i found in the
method engineLoad the exception handling an bit ugly.
+} cat
Just a couple of other comments:
- Both JavaKeyStore and JavaKeyStore$DualFormatJKS can be
package-private since they are only referenced from SunEntries which is
in the same package. I would also move KeyStoreDelegator into
sun.security.provider and make it package-private.
- Can you add a
Hi,
On Fri, May 22, 2015 at 2:55 AM, Bradford Wetmore
wrote:
> 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
Hello security library team,
I neglected to include you in the original request for review of this
change. I'd like to replace all the package.html files in the java.base
module with package-info.java files and a few cryptography packages are
involved; please review.
Thanks,
-Joe
webrev:http://cr.openjdk.java.net/~xuelei/8043758/webrev.latest/
Updates:
1. Update to discard invalid records, rather than use an alert message,
per the requirements in section 4.1.2.7, RFC 6374.
2. Update to use a base test class, simplify the test case a lot.
Thanks,
Xuelei
On 5/21/2015 7:34
The 3 crypto files look fine to me.
BTW I did notice that you preserve the Copyright range years in all but
src/java.base/share/classes/javax/crypto/package-info.java
Thanks.
> On 22 May 2015, at 17:42, joe darcy wrote:
>
> Hello security library team,
>
> I neglected to include you in the o
On 05/22/2015 08:09 AM, Alan Bateman wrote:
On 22/05/2015 13:55, Chris Hegarty wrote:
:
I think it could be done either way.
Valerie - have you considered not pushing the services configuration
files with this change? With the change then the java.security
configuration is still class nam
Thanks for the review Vinnie; I've pushed with a consistent copyright date.
-Joe
On 5/22/2015 9:49 AM, Vincent Ryan wrote:
The 3 crypto files look fine to me.
BTW I did notice that you preserve the Copyright range years in all
but *src/java.base/share/classes/javax/crypto/package-info.java*
On 05/22/2015 10:41 AM, Sean Mullan wrote:
On 05/22/2015 10:33 AM, Weijun Wang wrote:
Looks good.
Are you also going to remove the policy.ignoreIdentityScope definition
inside jdk\src\java.base\share\conf\security\java.security?
Good catch. I thought that had been removed as part of JDK-68761
On 05/22/2015 12:12 PM, Simone Bordet wrote:
Would be great if we could make this class a FunctionalInterface
Yes, that would be nice.
, but
I guess it's not easy due to lack of commonality between SSLSocket and
SSLEngine.
Unless there is a way to abstract something out of those 2:)
There's
Thanks Thomas and Sean for your review comments.
KeyStoreDelegator matches the JDK 9 version. I’ve moved it to the
sun.security.package and modified it as suggested.
I also made JavaKeyStore package-private but DualFormatJKS needs to remain
public.
The cert in trusted.pem is an arbitrary X.509 c
> > There was also some internal discussion about whether the values
> > should be Strings or byte arrays. The ALPN RFC only discusses
> > bytes, and a String.toBytes("US-ASCII") would limit the API to
> > ASCII strings.
> >
> > Lastly, we could also add some convenience values for well-known
> >
Hi,
On Fri, May 22, 2015 at 8:54 PM, Sean Mullan wrote:
> There's actually a bunch of methods in common, so one possibility is to
> create a new interface containing the common methods (say SSLBase for now
> for lack of a better name). Then you could change SSLEngine and SSLSocket to
> implement
Hi,
On Fri, May 22, 2015 at 9:14 PM, Bernd Eckenfels wrote:
> I would suggest to make this encoded in latin1 instead. This is
> supposed to be a 8bit clean encoding (and will be compatible to all
> ASCII only strings). It is still ugly and needs to be documanted
> cleanly that the string you get
Looks fine to me.
--Sean
On 05/22/2015 03:10 PM, Vincent Ryan wrote:
Thanks Thomas and Sean for your review comments.
KeyStoreDelegator matches the JDK 9 version. I’ve moved it to the
sun.security.package and modified it as suggested.
I also made JavaKeyStore package-private but DualFormatJKS
Hello,
does jdk.tls.disabledAlgorithms support to disable DHE based on the
prime size (similiar to RSA keySize)? I have tried it, but I can only
disable DHE completely, but I cannot get a Java TLS client to enforce
higher standards (i.e. at least 768, better 1024) bit. I tried
Oracle 8u40. Is ther
On 5/23/2015 1:52 AM, Sean Mullan wrote:
After further thought, I think it makes sense to leave the property in
for now.
The one change I will make is to add a sentence to the java.security
file that the default JDK policy provider does not support this
property. This is just documenting existin
On 5/23/2015 3:20 AM, Simone Bordet wrote:
Hi,
On Fri, May 22, 2015 at 9:14 PM, Bernd Eckenfels wrote:
I would suggest to make this encoded in latin1 instead. This is
supposed to be a 8bit clean encoding (and will be compatible to all
ASCII only strings). It is still ugly and needs to be doc
Please refer to the "Customizing Size of Ephemeral Diffie-Hellman Keys"
section of JSSE Reference Guide.
http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html
Xuelei
On 5/23/2015 5:34 AM, Bernd Eckenfels wrote:
> Hello,
>
> does jdk.tls.disabledAlgorithms support
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 i
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 the over-the-wire byte
values, and http/1.1 !=
27 matches
Mail list logo
