When a slave is many diffs behind, send these in batches of up to
50, then handle other slaves.
This also implements a fast-path that makes incremental diffs faster
when the log has not rolled over.
Related code cleanup.
If a slave is slow to consume what the master sends it, the master can
block and all iprop operations with it.
With minimal effort we make the master async oriented.
ipropd-master sends AYT messages often as a result of a possibly-
transient error, but if the slave responds to such an AYT with I_HAVE,
then the same code path that failed will be executed on the master, and
if the error wasn't transient then we'll loop hard. So don't send an
I_HAVE in response to an AYT.
Refactor krb5_cc_set_default_name() by splitting out the part that looks
for a configured default ccache name. This will allow one to check if a
given ccache is a default ccache for a process ignoring KRB5CCNAME,
which might prove useful in the kx509 client.
It's still not supported, but at least it generates valid JSON now.
Note that --json w/o -v is functional but has issues, specifically the
rtbl_add_column_entry() does not encode strings properly for output as JSON
strings. Fixing this will take significantly more effort. One wonders if it
might not be better to use a proper JSON library instead of the rtbl stuff.
Move init/copy/destroy fallback sequence from fcc_move() to
krb5_cc_move().
Make sure all backends's move() method calls krb5_cc_destroy() on the
source on success (and only on success).
In text_cc make sure that we can find in the destination the cred
stored into the source.
This is necessary in order to have more control over, e.g., template
certificates for kx509. But also it's good to have this more generally.
Some batteries not included. Specifically: no attempt is made to validate that
given KeyUsage values are compatible with the subjectPublicKey's alrogithm and
parameters.
```
hxtool request-create --subject=... \
--generate-key=... \
--key-bits=... \
--key=STORE \
store
```
wants to generate a key, store it in the location specified by the --key
argument, then read it back, then generate the CSR, and store it in
`store`.
But it didn't work because for generating a key this really wants the
`--key` argument to be a file path into which a raw DER-encoded RSA key
will be written (only RSA is supported, ay!), but for reading the key
back it uses `hx509_certs_init()`, which wants `TYPE:name` keystore
specification. A deadly embrace.
Now that we have improved libhx509 functionality for reading/writing
private keys from/to PEM files we use this functionality and require a
store type in the `--key=STORE` argument.
This commit adds:
- hx509_cert_init_private_key() for creating an hx509_cert object that
has just a private key
- hx509_cert_have_private_key_only() for checking whether an hx509_cert
object has just a private key
This also generalizes the get_key() internal function in hxtool, which
is tasked with reding or generating a private key for use in signing
CSRs. Now hxtool request-create can read/write private keys to/from PEM
files, not just DER files.
This is needed to support key types other than just RSA for CSRs and
certificates.
The header file was not installed, and the manpage had the wrong
name for the plugin load function, it is "krb5_plugin_kuserok_plugin_load",
not "kuserok_plugin_load".
%{loginname} is for getlogin_r().
Now %{username} uses only the $USER and $LOGNAME environment variables
(if the caller is not set-uid), or if absent or the caller is set-uid,
then getpwuid_r().
The intent is to allow kadmin(1) to use the loginname instead of the
username for the construction of the kadmin client principal name. This
is helpful when the user runs kadmin as root via sudo and/or su.
In order to support certain use cases, we implement a mechanism to
allow wildcard principals to be defined and for the KDC to issue
tickets for said principals by deriving a key for them from a
cluster master entry in the HDB.
The way that this works is we defined an entry of the form:
WELLKNOWN/DERIVED-KEY/KRB5-CRYPTO-PRFPLUS/<hostname>@REALM
When reading from the Kerberos DB, if we can't find an entry for
what looks like a hostbased principal, then we will attempt to
search for a principal of the above form chopping name components
off the front as we search.
If we find an entry, then we derive keys for it by using
krb5_crypto_prfplus() with the entry's key and the principal name
of the request.
