FYI,
concerns from Darwin on the 8078439: 8048194 fixes.
regards,
Sean.
-------- Forwarded Message --------
Subject: 8078439: 8048194: possible bug in commit for these two fixes
Date: Wed, 20 May 2015 16:28:29 -0700
From: Darwin Felix <darwinfe...@yahoo.com>
To: jdk8u-...@openjdk.java.net
CC: darwinfe...@users.sourceforge.net
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
