8078439: 8048194: possible bug in commit for these two fixes

[Seán Coffey]

Darwin,

being a security libs issues, this is probably best discussed on the 
security-dev java.net mailing list. I'll forward this and cc you.  You 
may also wish to report your issue via http://bugreport.java.com/

Regards,
Sean.

On 21/05/2015 00:28, Darwin Felix wrote:
> 8078439: 8048194: possible bug in commit for these two fixes
>   
> It appears that this commit has a bug:
>   
> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d777e2918a77/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java
> Fundamentally, it appears that this commit desires to honor the initiator/client's preferred mechanism - first one in the list of mechanisms the client is offering to the target/server.
> However, the commit does not allow for the condition where the server can only support a different mechanism from the client's offering/list (server not able to support mechList[0] but is able to support mechList[N]).
>   
> In my humble opinion, based on my quick glance of the code, this commit is broken because the server is no longer allowed to select from one of the other mechanisms from the client's list.
>   
>   
> This next commit also appears to have a bug:
>   
> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/9ab9f20e9bdd/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java
> It appears that this commit also desires to honor the initiator/client's preferred mechanism.
> However, this commit also appears to suffer from the condition where the server can only support a different mechanism from the client's offering/list (server not able to support mechList[0] but is able to support mechList[N]).
>   
>   
>   
> Perhaps the above two (2) commits should be reverted?
>   
> An alternative approach to supporting/honoring the initiator/client's preferred mechanism:
>   
> Prior to the above two (2) commits, SpNegoContext.java suffered from the condition where it did not make an attempt/consider to use the initiator/client's preferred mechanism. Instead, the code would find a mechanism from the client's list that the server can support. Meaning, the server's supported/preferred mechanisms is the outer loop and the client's supported/preferred mechanism is the inner loop (preference specified by its order in the list).
>   
> Here's what the code looked like prior to the above two (2) commits:
>   
> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/1a3de3cdc684/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java
> Perhaps, if we simply place the client's list as the outer loop and the server's list as the inner loop, we might be able to honor the client's preferred mechanism while ensuring that the chosen mechanism is one that the server can support.
>   
> For example, have a look at the implementation of the method named
>   
> SpNegoContext.negotiate_mech_type(supported_mechSet, mechList)
>   
> Notice that the server's list is chosen as being the outer loop. It might make more sense to have the client's list be the outer loop.
>   
>   
> If possible, I would like to discuss the possibility of reverting the above two commits and instead implement my proposed change (mechList as the outer loop and supported_mechSet as the inner loop) to the method named negotiate_mech_type.
>   
>   
> thanks,
> -darwin