src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java
--
- } else if (keyExchange == K_KRB5 || keyExchange == K_KRB5_EXPORT) {
+ } else if (ClientKeyExchangeService.find(keyExchange.name) != null) {
ClientKeyExchangeService is a pretty common name.
"ClientKeyExchan
There are several places you write
// DTLS bans stream ciphers.
if (suite.cipher.cipherType == CipherType.STREAM_CIPHER) {
return true;
}
According to rfc6347
4.1.2.5. New Cipher Suites
Upon registration, new TLS cipher suites MUST indica
Hi,
On Tue, May 26, 2015 at 8:46 PM, Bradford Wetmore
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 1a and not 1b.
>
> Sure, most of the heavy lifting takes place in ServerHa
On 5/27/2015 6:46 PM, Weijun Wang wrote:
> There are several places you write
>
> // DTLS bans stream ciphers.
> if (suite.cipher.cipherType == CipherType.STREAM_CIPHER) {
> return true;
> }
>
> According to rfc6347
>
> 4.1.2.5. New Cipher Sui
Good point! The Web Application Servers use case also seems to have been
the impetus behind
JSR 121: Application Isolation API Specification
(https://jcp.org/en/jsr/detail?id=121). Mark, note the dates on this
spec. Specification started in 2001 and ended in 2006.
Security Explorations release
Please review the fix below:
diff --git
a/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java
b/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java
---
a/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCr
Looks good!
--Sean
On 05/27/2015 11:08 AM, Weijun Wang wrote:
Please review the fix below:
diff --git
a/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java
b/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java
---
a/src/java.
[I'm sorry, I didn't send this to the correct list. I forgot that
there was a separate security list.]
An update:
I'm still working on this. Following last week's revelations [1] it
seems to me that a faster implementation of (integer) D-H is even more
important.
I've spent a couple of days tr
On 05/27/2015 10:17 AM, Andrew Haley wrote:
[I'm sorry, I didn't send this to the correct list. I forgot that
there was a separate security list.]
An update:
I'm still working on this. Following last week's revelations [1] it
seems to me that a faster implementation of (integer) D-H is even m
Sean,
FYI, I have asked the build team to review the makefile changes.
BTW, I changed java.security.Provider file to use @implSpec as Joe has
suggested. In addition, I changed the getArgument() impl in
OracleUcrypto provider + SunPKCS11 provider to only return the value if
the caller has read
Valerie,
Did you see my comment yesterday?
http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html
Since you have reverted the java.security to keep the classname, to avoid
causing merge conflict to jimage refresh, let’s remove the META-INF files in
the first push and the bu
On 05/27/2015 06:35 PM, Valerie Peng wrote:
In addition, I changed the getArgument() impl in OracleUcrypto provider
+ SunPKCS11 provider to only return the value if the caller has read
permission to the file. I feel this is probably safer as we don't want
to reveal the path (potential info leak)
On 05/27/2015 07:05 PM, Sean Mullan wrote:
On 05/27/2015 06:35 PM, Valerie Peng wrote:
In addition, I changed the getArgument() impl in OracleUcrypto provider
+ SunPKCS11 provider to only return the value if the caller has read
permission to the file. I feel this is probably safer as we don't wa
Hi, Mandy,
I have second thought on using the provider name for the java.security
file...
There are a few things that I want to discuss/brainstorm internally to
make sure that there is no "surprise" later.
Thus, I had not made the switch in this webrev. It doesn't affect the
overall functional
> On May 27, 2015, at 4:17 PM, Valerie Peng wrote:
>
> Hi, Mandy,
>
> I have second thought on using the provider name for the java.security file...
> There are a few things that I want to discuss/brainstorm internally to make
> sure that there is no "surprise" later.
> Thus, I had not made th
Hi Darwin
Thanks for looking into this file. Most of your words are correct, but
I'd like to explain what was behind those changesets.
See comments below.
On 5/21/2015 3:58 PM, Seán Coffey wrote:
FYI,
concerns from Darwin on the 8078439: 8048194 fixes.
regards,
Sean.
Forwarded Me
Sounds good to me.
I suppose we can add it later if really needed.
I will update the webrev and CCC.
Thanks,
Valerie
On 5/27/2015 4:05 PM, Sean Mullan wrote:
On 05/27/2015 06:35 PM, Valerie Peng wrote:
In addition, I changed the getArgument() impl in OracleUcrypto provider
+ SunPKCS11 provider
17 matches
Mail list logo
