Code review request: 8014310: JAAS/Krb5LoginModule using des encytypes failure with NPE after JDK-8012679

[Wang Weijun]

在 Jun 13, 2013，4:14 AM，"Valerie (Yu-Ching) Peng" <valerie.peng at oracle.com> 写道：

> 
> Changes look fine.
> Just curious, what's the reason for the changes in KeyTab.java?

There was an EType.getDefaults() call there and it is useless. If kept, will need to check exception.

-Max

> Valerie
> 
> On 06/07/13 00:31, Weijun Wang wrote:
>> Ding dong.
>> 
>> On 5/27/13 10:06 AM, Weijun Wang wrote:
>>> 
>>> Please review the code changes at
>>> 
>>>    http://cr.openjdk.java.net/~weijun/8014310/webrev.00/
>>> 
>>> The reason is that since we set allow_weak_crypto to false, if the user
>>> only had DES keys or only has DES-related etypes enabled, there will be
>>> no working etype at all. Soon or later, an NPE is thrown.
>>> 
>>> This fix includes:
>>> 
>>> 1. Instead of returning null in Config::defaultEtype(configName), a
>>> KrbException is thrown.
>>> 
>>> 2. Removes useless if-null-then-KrbException checks.
>>> 
>>> 3. Not related to the bug: remove sort-by-etype in
>>> KeyTab::readServiceKeys(princ). It was meant to make sure a preferred
>>> etype appears before another one. In fact, the order of etypes returned
>>> by EType::getDefaults(configName,keys) are determined by the order of
>>> Config::defaultEtype(configName) instead of keys. Therefore it's
>>> actually useless. The sort-by-kvno is preserved. This does not matter
>>> when the key is used to decrypt an EncryptedData structure (which knows
>>> what kvno should be used). Sometime we still have to pick one with no
>>> hint at all, say, creating the encrypted timestamp in preauth AS-REQ. A
>>> key with higher kvno is normally more likely to be the current one.
>>> 
>>> Thanks
>>> Max
>