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 /doc/tools/doxybuilder_funcs.py | |
parent | 1825455ede7e61ab934b16262fb5b12b78a52f1a (diff) | |
download | krb5-fb5cd8df0dbd04dac4f610e68cba5b80a3cb8d48.tar.gz krb5-fb5cd8df0dbd04dac4f610e68cba5b80a3cb8d48.tar.xz krb5-fb5cd8df0dbd04dac4f610e68cba5b80a3cb8d48.zip |
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 'doc/tools/doxybuilder_funcs.py')
0 files changed, 0 insertions, 0 deletions