diff options
author | Greg Hudson <ghudson@mit.edu> | 2014-05-23 19:58:41 -0400 |
---|---|---|
committer | Greg Hudson <ghudson@mit.edu> | 2014-06-05 11:34:28 -0400 |
commit | fb5cd8df0dbd04dac4f610e68cba5b80a3cb8d48 (patch) | |
tree | baff1e52e2262cc50df2d85a20f96a93abb3c2ee /src/tests | |
parent | 1825455ede7e61ab934b16262fb5b12b78a52f1a (diff) | |
download | krb5-fb5cd8df0dbd04dac4f610e68cba5b80a3cb8d48.zip krb5-fb5cd8df0dbd04dac4f610e68cba5b80a3cb8d48.tar.gz krb5-fb5cd8df0dbd04dac4f610e68cba5b80a3cb8d48.tar.bz2 |
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
Diffstat (limited to 'src/tests')
-rw-r--r-- | src/tests/kdbtest.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/tests/kdbtest.c b/src/tests/kdbtest.c index 64f28bb..d211265 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 }, |