On 8/6/2014 20:55, Xuelei Fan wrote:
Weijun,
Where the krb5 impl will be packaged into in the future?
In the java.jgss module.
Still the
SunProvider but in a new jar file? I was wondering whether we can use
the provider service approach that we used to define other security
components implementations. I'm not quite confident with the security
of the use of ServiceLoader.load().
You mean define a new provider service like "MessageDigest" and
"Cipher", I think that's a heavier version of ServiceLoader. Also this
interface is now quite premature and only used internal.
By security, are you afraid of someone providing his own implementation
and shadow the JDK one? I'll do some investigation.
--Max
Xuelei
On 8/4/2014 9:48 AM, Wang Weijun wrote:
Hi Xuelei
Are you OK with the code change? The updated webrev is now at
http://cr.openjdk.java.net/~weijun/8038089/webrev.02/
Comparing to the last version. there are some comment changes and emptying
refs.allowed. The only major change is that the ServiecLoader now uses system
class loader.
Thanks
Max
On Jul 21, 2014, at 16:22, Wang Weijun <weijun.w...@oracle.com> wrote:
Please review the updated webrev at
http://cr.openjdk.java.net/~weijun/8038089/webrev.01
Some comment changes. Some arguments rearrangement between classes.
The interface is still in sun.security.ssl. It will be easy to move it to
somewhere else later. When module is introduced, we may need to export the
interface from java.base to java.security.jgss.
Thanks
Max
On Jul 17, 2014, at 12:35, Xuelei Fan <xuelei....@oracle.com> wrote:
On 7/16/2014 4:41 PM, Wang Weijun wrote:
Hi Xuelei
A *primitive* version of webrev available at
http://cr.openjdk.java.net/~weijun/8038089/webrev.00
Please confirm this is the way you like it.
I have not read too much about the details of the update. But looks
like it is in the right way.
ExternalCipherSuite is the service interface and Krb5CipherSuite implements it.
It's a modification of the old Krb5Proxy but I've moved as many as
Kerberos-related codes to the implementation side so it has less methods now.
Most likely we will define this new interface in a public package.
If krb5 is the only external implementation of TLS cipher suites, I
think, we may want to try the best not to define public interface if
possible.
Thanks,
Xuelei
I didn't touch any core SSL classes except for ClientHandshaker and
ServerHandShaker. If you think there are other places too closely connected
with kerberos, please let me know.
Ideally, those
case K_KRB5: case K_KRB5_EXPORT:
Krb5Helper.doXXX(...):
should be something like
default:
getExternalHelper(keyExchange).doXXX(...)
but I guess we won't do that unless we know there will be a second
implementation.
Thanks
Max
