TRUE/FALSE may not be defined, so emitting those symbols when generating
code for `... BOOLEAN DEFAULT TRUE -- or FALSE` causes the generated
code to fail to compile. We could move the definitions of TRUE/FALSE to
krb5-types.h, or maybe we could have an asn1_compile option to force
inclusion of more than one header file so we can have headers defining
such constants. But the simplest fix is to just emit 1/0 instead of
TRUE/FALSE.
This explains why some BOOLEAN DEFAULT usages in PKIX are made OPTIONAL
in Heimdal.
In preparation for adding support for TPM attestations as an authentication
method in bx509d for a host trust bootstrap mechanism based on TPMs and their
endorsement keys and endorsement key certificates.
The plan is to add support to libhx509 and hxtool for PermanentIdentifier
(RFC4043) and HardwareModuleName (RFC4108) SANs, and then to add a query
parameter to bx509d for passing an attestation and a proof-of-possession
(either CMS or CSR), and add an authorizer plugin call for authorizing a device
manufacturer and serial number to hostname. Support for TPMs w/o endorsement
key certificates should also be possible based on a digest of the endorsement
key as the "serial number".
macOS packs ccapi structures to 16 bits on PowerPC and Intel platforms only;
no special packing is used on ARM (Apple Silicon). Harmonize so Heimdal is ABI
compatible.
When encountering a backslash character the memmove() call removes it. But then the pointer p should only be incremented by 1 to skip the escaped character rather than 2, which also skips the character following the escaped one.
Fix the possible leak of 's' allocated by asprintf()
When squashing the changes reference "this fixes an issue introduced by 7bf4d76 ("krb5: Improve cccol sub naming; add gss_store_cred_into2()")" in the commit message.
Test that we can dump an HDB w/o blocking write transactions.
This currently works for different processes (both backends), but not
for threads (for either backend), and it's not yet clear why.
Do not allow a change in build configuration time default HDB backend
selection cause existing default HDBs to not be possible to open.
Otherwise such a change will cause a KDC configured to use the default
HDB (i.e., without setting it in the "database" stanza in the "[kdc]"
section of krb5.conf) to not start.
tests/kdc/check-iprop.in tends to wait for a log message then it reads a
status file. Well, we shouldn't write the log message before writing
the status file then!
Running ipropd-slave on a system whose hostname's realm is not the
requested realm breaks. Since the iprop client principal should really
be in the same realm as the master, we now force it after calling
krb5_sname_to_principal().
The new [hdb] new_service_key_delay parameter should not apply to
principal entries when used as clients. Otherwise new passwords would
not take effect immediately, and that would be very confusing.
