From fb5cd8df0dbd04dac4f610e68cba5b80a3cb8d48 Mon Sep 17 00:00:00 2001 From: Greg Hudson Date: Fri, 23 May 2014 19:58:41 -0400 Subject: Treat LDAP KrbKey salt field as optional Per the ASN.1 definition, the KrbKey salt field is optional. Since 1.7, we have been treating it as mandatory in the encoder; since 1.11, we have been treating it as mandatory in the decoder. Mostly by luck, we have been encoding a salt type of 0 when key_data_ver is 1, but we really should not be looking at key_data_type[1] or key_data_length[1] in this situation. Treat the salt field as optional in the encoder and decoder. Although the previous commit ensures that we continue to always encode a salt (without any dangerous assumptions about krb5_key_data constructors), this change will allow us to decode key data encoded by 1.6 without salt fields. This also fixes issue #7918, by properly setting key_data_ver to 2 if a salt type but no salt value is present. It is difficult to get the decoder to actually assign 2 to key_data_ver just because the salt field is there, so take care of that in asn1_decode_sequence_of_keys. Adjust kdbtest.c to match the new behavior by setting key_data_ver to 2 in both test keys. ticket: 7919 target_version: 1.12.2 tags: pullup --- src/tests/kdbtest.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src/tests') diff --git a/src/tests/kdbtest.c b/src/tests/kdbtest.c index 64f28bbca..d21126558 100644 --- a/src/tests/kdbtest.c +++ b/src/tests/kdbtest.c @@ -120,7 +120,7 @@ static krb5_key_data keys[] = { U("expsalt") } }, { - 1, /* key_data_ver */ + 2, /* key_data_ver */ 2, /* key_data_kvno */ { ENCTYPE_AES128_CTS_HMAC_SHA1_96, 0 }, { 16, 0 }, -- cgit