summaryrefslogtreecommitdiffstats
path: root/src/ccapi/server/win
diff options
context:
space:
mode:
authorGreg Hudson <ghudson@mit.edu>2014-05-23 19:58:41 -0400
committerGreg Hudson <ghudson@mit.edu>2014-06-05 11:34:28 -0400
commitfb5cd8df0dbd04dac4f610e68cba5b80a3cb8d48 (patch)
treebaff1e52e2262cc50df2d85a20f96a93abb3c2ee /src/ccapi/server/win
parent1825455ede7e61ab934b16262fb5b12b78a52f1a (diff)
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/ccapi/server/win')
0 files changed, 0 insertions, 0 deletions