Skip Menu |
 

From: tlyu@mit.edu
Subject: git commit
Download (untitled) / with headers
text/plain 1.2KiB

Always include salt in LDAP KrbKey encoding

In the LDAP KDB module, ensure that every krb5_key_data we pass to
asn1_encode_sequence_of_keys includes a salt type, for compatibility
with the decoder in unpatched krb5 1.11 and 1.12.

This is not a behavior change by itself; since 1.7 the encoder has
always included a KrbKey salt field because it erroneously treats that
field as non-optional. (Luckily, the encoded salt always happens to
have salt type 0 because krb5_key_data constructors start with zeroed
memory.) The next commit will fix the encoder and decoder to properly
treat the KrbKey salt field as optional, so we need this change to
ensure that our encodings remain compatible.

Also fix the ASN.1 tests to set key_data_ver correctly for the sample
test key data.

(cherry picked from commit 1825455ede7e61ab934b16262fb5b12b78a52f1a)

https://github.com/krb5/krb5/commit/0149ee13d51b48d77fbbaa5c1109036332a5577c
Author: Greg Hudson <ghudson@mit.edu>
Committer: Tom Yu <tlyu@mit.edu>
Commit: 0149ee13d51b48d77fbbaa5c1109036332a5577c
Branch: krb5-1.11
src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c | 21 +++++++++++++++++++-
src/tests/asn.1/ktest.c | 1 +
2 files changed, 21 insertions(+), 1 deletions(-)
From: tlyu@mit.edu
Subject: git commit
Download (untitled) / with headers
text/plain 1.5KiB

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.

(back ported from commit fb5cd8df0dbd04dac4f610e68cba5b80a3cb8d48)

https://github.com/krb5/krb5/commit/482ff54758a3d0dcef855a546340922a541fa458
Author: Greg Hudson <ghudson@mit.edu>
Committer: Tom Yu <tlyu@mit.edu>
Commit: 482ff54758a3d0dcef855a546340922a541fa458
Branch: krb5-1.11
src/lib/krb5/asn.1/ldap_key_seq.c | 19 ++++++++++++++++---
src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c | 6 ++++--
2 files changed, 20 insertions(+), 5 deletions(-)
From: tlyu@mit.edu
Subject: git commit

Use calloc, not k5calloc in ldap back end

The changes cherry picked in 0149ee13d51b48d77fbbaa5c1109036332a5577c
rely on k5calloc(), which is not present in the 1.11 branch.
Compensate by using calloc() instead.

https://github.com/krb5/krb5/commit/c582dfb3cc5c28cb8f909532184495c429c55ffb
Author: Tom Yu <tlyu@mit.edu>
Commit: c582dfb3cc5c28cb8f909532184495c429c55ffb
Branch: krb5-1.11
src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)