Many libc implementations include notations to the linker to generate
warnings upon references to mktemp(3), due to its potential for
insecure operation.  This has been the case for quite some time,
as was noted in RT #6199.  Our usage of the function has decreased
with time, but has not yet disappeared entirely.  This commit
removes the last few instances from our tree.

kprop's credentials never need to hit the disk, so a MEMORY ccache
is sufficient (and does not need randomization).
store_master_key_list is explicitly putting keys on disk so as to
do an atomic rename of the stash file, but since the stash file
should be in a root-only directory, we can just use a fixed name
for the temporary file.  When using this fixed name, we must detect
(and error out) if the temporary file already exists; add a test to
confirm that we do so.

ticket: 1794

The comment previously failed to match the behavior. The intent was
that if we failed to write out the entire stash file into the
temporary location, we should remove the partial file.  However, the
code was actually checking whether the *real* stash file existed,
not whether the temporary one existed.

It is safe to always try to unlink the partial file, and not worry
about whether it already exists.

krb5_dbe_lookup_mkey_aux was decoding a 16-bit value directly into an
int, resulting in the wrong value on big-endian platforms.  The
consequences are mostly invisible because we ignore this field and try
all mkey_aux nodes in krb5_def_fetch_mkey_list.

ticket: 7738 (new)
target_version: 1.12
tags: pullup

In add_key_pwd, initialize s2k_params to NULL inside the loop over
enctypes instead of outside the loop, so that if the afs3 salt type
is used it does not contaminate later enctype/salt pairs in the list.

ticket: 7733
tags: pullup
target_version: 1.12

Starting with 1.7, databases are created with actkvno tl-data in the
K/M entry which gives the initial master key version an activation
time of 0.  A database created before 1.7 will not have this tl-data,
but we should behave in the same way as we do for a more recent
database.

Move the actkvno list synthesis code from krb5_dbe_fetch_act_key_list
to krb5_dbe_lookup_actkvno so it applies to kdb5_util commands as well
as libkadm5.  Synthesize the same list as we would have initialized
the KDB with, with an activation time of 0 for the earliest master
key.

ticket: 7686
target_version: 1.12
tags: pullup

Refactor krb5_dbe_find_act_mkey and make it reload the master key list
if it doesn't find a master key matching the active mkvno.

ticket: 7685

When we allocate space for an array of key_data structures, make sure
we allocate at least one, so we don't spuriously fail on platforms
where malloc(0) returns NULL.  Where we use malloc, use k5calloc
instead.  Where we use krb5_db_alloc or realloc, just allocate an
extra entry.

Provide default values in pre.in for PROG_LIBPATH, PROG_RPATH,
SHLIB_DIRS, SHLIB_RDIRS, and STOBJLISTS so that they don't have to be
specified in the common case.  Rename KRB5_RUN_ENV and KRB5_RUN_VARS
to RUN_SETUP (already the most commonly used name) and RUN_VARS.  Make
sure to use DEFINES for local defines (not DEFS).  Remove some other
unnecessary makefile content.

Locking and unlocking a non-recursive mutex is a simple memory
operation and should not fail on any reasonable platform with correct
usage.  A pthread mutex can return EDEADLK on lock or EPERM on unlock,
or EINVAL if the mutex is uninitialized, but all of these conditions
would reflect serious bugs in the calling code.

Change the k5_mutex_lock and k5_mutex_unlock wrappers to return void
and adjust all call sites.  Propagate this change through
k5_cc_mutex_lock and k5_cc_mutex_unlock as well.