Code review request, CR 7174244, NPE in Krb5ProxyImpl.getServerKeys()

Steven Read steve.read at microfocus.com
Fri Jun 8 12:31:20 UTC 2012


Xuelei Fan <xuelei.fan at ...> writes:

> 
> On 6/6/2012 9:11 PM, Weijun Wang wrote:
> > Hi Xuelei
> > 
> > I don't quite understand the bug report. Certainly it's good to prevent
> > that NPE, but why must the cipher suites be ordered? It seems it's not
> > ordered before the new HashMap.
> No, it was not ordered because of a regression.
> 
> > Is this a regression or an RFE?
> It's a regression. We used to use TreeSet to sort the cipher suites. But
> later it is miss-updated to use ArrayList rather then TreeSet in a bug
> fix. Then the order was lost.
> 
> We need to sort the cipher suites because the order is the preference
> when TLS handshaking selects a proper cipher suite. Please refer to TLS
> specification about the order, page 41, RFC5246:
> 
>    cipher_suites
>       This is a list of the cryptographic options supported by the
>       client, with the client's first preference first.
> 
> > You'd
> > better add some explanation in the bug report.
> > 
> I will.
> 
> Thanks,
> Xuelei
> 
> > Thanks
> > Max
> > 
> > On 06/06/2012 08:27 PM, Xuelei Fan wrote:
> >> Hi Weijun,
> >>
> >> Would you please review the fix for CR 7174244.
> >>      http://cr.openjdk.java.net./~xuelei/7174244/webrev.00/
> >>
> >> There are mainly two updates in the fix. One is to have
> >> Krb5ProxyImpl.getServerKeys()  to check null return value of
> >> Krb5Util.getServiceCreds(). The other one is to have cipher suite order
> >> to be independent from HashMap implementation.  TreeSet is used to
> >> replace ArrayList so that the cipher suites order are sorted
> >> automatically.
> >>
> >> Thanks,
> >> Xuelei
> 
> 

Hi Xuelei,

My only comment is that providing the ciphers in preference order goes beyond
what the API call specifies. I would agree it makes a lot of sense to have them
returned in order, but other implementations of JSSE do not necessarily provide
them in preference order as they are not required to - certainly looking at
JDK1.6.0 on IBM earlier today it was not.

Therefore, anyone wishing to write cross-JDK compatible code would be wrong to
assume that they don't need to order the ciphers by preference themselves as
well. Perhaps it is possible to do a docs change on the abstract classes to
indicate that the order is not guaranteed across JSSE implementations.

Best regards
Steve






More information about the security-dev mailing list