Here's an updated webrev that supports including/excluding specific
JCA engines:
Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.01/
For example, use the following to trace only MessageDigest and
Signature engines:
-Djava.security.debug=provider:engine=MessageDigest,Signature
an
On 09/16/2014 11:27 AM, Vincent Ryan wrote:
Here's an updated webrev that supports including/excluding specific
JCA engines:
Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.01/
Looks good, although the doDebug boolean is making my head spin, is
there an easier way to specify that?
Hello JDK security team,
(cced the Undertow guys cause I mentioned this on the IRC channel)
when trying to run the JBoss Undertow build tests with JDK9ea-b30 a lot
of tests fail with the same "NosuchMethodError", and I am not sure why.
It looks like an internal inconsitency in the JSSE? However
I'm OK with the doPrivileged-with-permission mode.
Generally speaking, we only need to define the authentication part of a
cipher suite for KRB5 implementation. I was wondering, can we simplify
the code more as follow:
1. define an private external authentication interface, which:
a. generate
This is because Undertow is testing SPDY and HTTP2, which use Jetty
ALPN. This jar resides on the boot class path, and you need to use a
specific version of it for a given JVM.
Undertow uses profiles to select between JDK 7 and 8, however it looks
like it will attempt to use the 8 jar if you t
Certainly it will be better to make the interface more generalized. But there
are ExternalCipherSuiteProvider methods like getServiceCreds() and isRelated()
and I don't know how they will be used for other key exchange services. Also it
seems we still need to define an extended HandshakeMessage
On 9/17/2014 11:32 AM, Wang Weijun wrote:
>
> Certainly it will be better to make the interface more generalized. But there
> are ExternalCipherSuiteProvider methods like getServiceCreds() and
> isRelated() and I don't know how they will be used for other key exchange
> services.
One of my moti
> I would prefer we do it now. If I did not miss something, the new design
> should be more simple
> and straightforward.
Maybe, but I am not sure since this would surely touch more TLS side codes. If
you want to be totally separated, we also need to move the ciphersuites
definitions outside C
On 9/17/2014 1:49 PM, Wang Weijun wrote:
>> I would prefer we do it now. If I did not miss something, the new design
>> should be more simple
>> and straightforward.
>
> Maybe, but I am not sure since this would surely touch more TLS side codes.
> If you want to be totally separated, we also ne
