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

Valerie (Yu-Ching) Peng valerie.peng at
Wed Jun 12 17:21:49 PDT 2013

Ok, I have no more comments.

On 06/12/13 15:16, Wang Weijun wrote:
> ÔÚ Jun 13, 2013£¬4:14 AM£¬"Valerie (Yu-Ching) Peng" <valerie.peng at> дµÀ£º
>> Changes look fine.
>> Just curious, what's the reason for the changes in
> 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
>>>> 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

More information about the security-dev mailing list