ticket: 7800

Previously, if you passed a service name with a realm part to a
kadm5_init function, you would get a KRB5_PARSE_MALFORMED error
because the code would internally append its own '@realm' suffix
before parsing the name.  Fix this as follows:

Change gic_iter so instead of producing a full service name, it
produces a krb5_principal which is taken from the cred it acquires.
Pass the client and full service name around as principals, rather
than strings, and use the gss_nt_krb5_principal name type to import
them in setup_gss().  Don't append a realm to the input service name;
instead, pass the input service name directly to the gic functions
(which do not need a realm in the service name and will ignore the
realm if one is present).  For the INIT_CREDS case, parse the input
service name with KRB5_PRINCIPAL_PARSE_IGNORE_REALM and then set the
realm.

ticket: 7800

The "realm" variable in init_any is used only to fill in the realm of
the service principal in gic_iter().  The service principal realm
should always be the realm we looked up config parameters for, so we
can supply that realm to get_init_creds() unconditionally and
eliminate the case where we use the client principal realm.

Also get rid of an outdated comment and an #if 0 block we will never
need again, and use SNPRINTF_OVERFLOW to check the snprintf result.

The kprop code has been pretty unloved, and uses some routines that
are marked as deprecated (which show up as warnings in the build log).
Use the documented replacement for krb5_get_in_tkt_with_keytab,
krb5_get_init_creds_keytab, instead.  As a bonus, there is no longer
a side effect of a credentials cache that needs to be destroyed.

The also-deprecated function krb5_get_in_tkt_with_skey was backending
to it when no keyblock was passed in; we can unroll the call to
krb5_get_init_creds_keytab ourselves as the documented workaround.
While here, improve style compliance with regards to cleanup.

The setkey test just wants to know whether it can use the key it
just put into a keytab to get credentials; as such the recommended
krb5_get_init_creds_keytab is quite sufficient.
While here, use that interface to request the particular enctype
as well, reducing the scope of an XXX comment.

ticket: 6366

"kdb5_util use_mkey" should not require a kadmind restart to take
effect.  At the cost of fetching the K/M principal once for each key
change operation, make kadmind use the current active master key list
for each operation.

ticket: 7685
target_version: 1.12
tags: pullup

Add kadmin support for "addprinc -nokey", which creates a principal
with no keys, and "purgekeys -all", which deletes all keys from a
principal.  The KDC was modified by #7630 to support principals
without keys.

ticket: 7679 (new)

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.

Wherever we use k5alloc with a multiplication in the size parameter,,
use the new k5calloc helper function instead.

In the gak_data value used by krb5_get_as_key_password, separate the
already-known password from the storage we might have allocated to put
it in, so that we no longer use an empty data buffer to determine
whether we know the password.  This allows empty passwords to work via
the API.

Remove the kadm5 test which explicitly uses an empty password.

Based on a patch from Stef Walter.

ticket: 7642