RFR 8042900: Allow com.sun.security.jgss to be in different module than org.ietf.jgss
Valerie Peng
valerie.peng at oracle.com
Mon Sep 8 22:25:17 UTC 2014
Max,
Mostly look fine. Just some comments, questions (see below):
<src/java.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSContext.java>
1) line 71 - 76 was done in Krb5Context.java. Is it really necessary to
move it here? I don't see a reason to.
<src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java>
1) line 1435, the cloning is removed? I didn't see a corresponding clone
being done in the caller, e.g. ExtendedGSSContext.
<src/java.security.jgss/share/classes/sun/security/jgss/JgssExtender.java>
1) the class description mentioned the registration process is hardcoded
in GSSManagerImpl. But it looks to me that it's actually done by the
com.sun.security.jgss.Extender class?
2) do you think we should require permissions for calls to
set/getExtender()?
<test/sun/security/krb5/auto/Context.java>
1) line 364: move it inside the if-block? Seems no value calling
xstatus() when x is null.
2) line 401: move it inside the if-block? Since if x is null, then there
is no output following this println() call.
Thanks,
Valerie
On 8/30/2014 6:59 PM, Weijun Wang wrote:
> Webrev updated at
>
> http://cr.openjdk.java.net/~weijun/8042900/webrev.01/
>
> as per Alan's suggestions.
>
> Can anyone in the security team take a look?
>
> Thanks
> Max
>
More information about the security-dev
mailing list