Include autoconf.h (either directly or via proxy) before system
headers, so that feature test macros defined there can affect the
system namespace.  Where include order was changed, eliminate some
redundant or unnecessary includes.

ticket: 7961

Take advantage of the strerror_r portability wrapper to simplify code
using it.  Remove unused macros related to strerror_r in
ldap_service_stash.c and plugins.c.

ticket: 7961

In create_identifiers_from_stack: check for allocation errors from
PKCS7_ISSUER_AND_SERIAL_new and M_ASN1_INTEGER_dup.  Use
PKCS7_ISSUER_AND_SERIAL_free to more concisely clean up the OpenSSL
issuer variable, and make sure that any partially processed value is
cleaned up on error.  Use calloc to allocate krb5_cas so that all of
its pointers are initially nulled, so that
free_krb5_external_principal_identifier can operate on it safely in
case of error.  Eliminate the retval variable as it was not used
safely.  Rename the error label from "cleanup" to "oom" and separate
it from the successful return path (which has nothing to clean up).

ticket: 7943 (new)
target_version: 1.12.2
tags: pullup

Fix three mismatched constant names, and properly alphabetize and
columnize the lists of definitions.  No functional changes.

When constructing a draft9 PKINIT request, always include
KRB5_PADATA_AS_CHECKSUM padata to ask for an RFC 4556 ReplyKeyPack.
Do not accept a draft9 ReplyKeyPack in the KDC response.

For now, retain the krb5_reply_key_pack_draft9 ASN.1 codec and the KDC
support for generating a draft9 ReplyKeyPack when a draft9 PKINIT
request does not contain KRB5_PADATA_AS_CHECKSUM.

ticket: 7933

Remove the PKINIT Windows Server 2008 beta compatibility code
conditionalized under the "longhorn" variable.  It is not required to
interoperate with any released version of Windows.

ticket: 7934 (new)

As contributed, the PKINIT module contained code to read the
pkinit_win2k variable, but never used it.  Get rid of the structure
field and the code to populate it.

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

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.

ticket: 7919