Remove krb5-send-pr

Remove the GNATS-based krb5-send-pr script and replace it with a
script that instructs users to send email.

ticket: 7840 (new)
Reinitialize ulog when wrapping serial number

When we wrap the serial number, reinitialize the ulog so that kdb_num
starts counting from 1, instead of leaving the ulog in a weird state
where kdb_num == ulogentries but kdb_last_sno == 1 and the serial
numbers in the circular array aren't necessarily contiguous.

ticket: 7839 (new)
target_version: 1.12.2
tags: pullup
Add test case for ulog serial number wrapping

Add a unit test program named t_ulog.  Make it map a ulog file, set up
header state where kdb_last_sno is the last serial number, and then
add an empty update.  Check that the result is a ulog header with one
update at serial number 1.

ticket: 7839
Check for unstable ulog in ulog_get_entries

If a process terminates in the middle of a logged database update, it
will release its lock and leave the ulog in the KDB_UNSTABLE state.
kadmind should notice this when it calls ulog_get_entries, but right
now it only checks for the KDB_CORRUPT state (which is never set any
more) and does not recover.  Check for any state other than KDB_STABLE
and recover by resetting the ulog and forcing full resyncs to slaves.

ticket: 7853 (new)
target_version: 1.12.2
tags: pullup
Remove kdb5_util load iprop safety net

Revert the safety net added #7370.  As written it only applied to the
master KDC, where a normal load sometimes makes sense.  Even on a
slave, there are edge cases where it can make sense to do a normal
load.

ticket: 7850 (new)
Fix kpropd -x

A missing break in the switch statement caused kpropd -x to error out
with a usage message.

ticket: 7854 (new)
target_version: 1.12.2
tags: pullup
Modernize iprop code

* Don't use "extern" for kdb_log.h prototypes.
* Avoid passing structures by value.
* Avoid the need to cast the result of the INDEX macro, and use char *
  instead of unsigned long for pointer arithmetic.
* Reorganize kdb_log.c so static helpers are at the top and don't use
  the "ulog_" prefix.
* Get rid of ulog_finish_update_slave since it's more concise to
  open-code it in ulog_replay.
* Get rid of ulog_delete_update.  In krb5_db_delete_principal, just
  call ulog_add_update with kdb_deleted set in upd.
* Modernize coding style of kproplog.c.  Use k5memdup0 instead of
  snprintf in print_str to convert a byte range to a C string.
  Remove an unnecesary textdomain call; libkrb5 takes care of calling
  bindtextdomain in the library initializer.
* Modernize coding style of kpropd.c and kprop.c.

No functional changes.
Clean up ovsec_kadmd.c

Fix code formatting issues.  Use static scope when possible, and put
all helper functions before main so that forward declarations aren't
needed.  Use GSS_KRB5_NT_PRINCIPAL_NAME instead of constructing it
with gss_str_to_oid, and get rid of display_status as that was the
only use.  Replace large verbose function comments with concise ones.
Factor out main loop setup and KDB keytab setup into helper functions.
Create a helper function fail_to_start for logging and exiting on
initialization failures, and use it instead of the large cleanup
blocks in main.

Some initialization error messages have changed; no other functional
changes.
In kdb5_util load, init ulog closer to promote

Always map the ulog with FKCOMMAND, not FKLOAD which reinitializes the
ulog.  Don't reinitialize the ulog until just before calling
krb5_db_promote().  Get rid of FKLOAD since it isn't needed any more;
we can just call ulog_init_header() manually.
Don't get KDB lock in ulog_get_entries

ulog_get_entries does not access the KDB, only the ulog, so it does
not need a KDB lock; its read lock on the ulog is sufficient to
prevent logged updates from happening while it is running.  There is
no reason to serialize against unlogged KDB updates such as those
performed by the KDC, as those do not affect the ulog.
Properly reflect MS krb5 mech in SPNEGO acceptor

r25590 changed negotiate_mech() to return an alias into the acceptor's
mech set, with the unfortunate side effect of transforming the
erroneous Microsoft krb5 mech OID into the correct krb5 mech OID,
meaning that we answer with a different OID than the requested one.
Return an alias into the initiator's mech set instead, and store that
in mech_set field the SPNEGO context.  The acceptor code only uses
mech_set to hold the allocated storage pointed into by internal_mech,
so this change is safe.

ticket: 7858
target_version: 1.12.2
tags: pullup
Test SPNEGO acceptor response to MS krb5 mech OID

In t_spnego.c, add code to make a SPNEGO request with the erroneous
Microsoft OID value and examine the response to make sure that it uses
the same OID value as the request did.  The token and tmp variables
were unused, so rename them to itok and atok for the purpose of the
new test code.

ticket: 7858
target_version: 1.12.2
tags: pullup
Move OTP sockets to KDC_RUN_DIR

Some system configurations expect Unix-domain sockets to live under
/run or /var/run, and not other parts of /var where persistent
application state lives.  Define a new directory KDC_RUN_DIR using
$runstatedir (new in autoconf 2.70, so fall back to $localstatedir/run
if it's not set) and use that for the default socket path.

[ghudson@mit.edu: commit message, otp.rst formatting fix]

ticket: 7859 (new)
Correctly get default realm in kdb5.c

Call krb5_get_default_realm instead of directly accessing
context->default_realm, to remove the requirement that
krb5_get_default_realm or krb5_set_default_realm be used before
krb5_db_open.
Fix SAM-2 preauth when password argument is used

sam2_process accesses gak_data to get the password, so that it can do
string-to-key with the etype in the SAM-2 challenge.  When #7642
changed gic_pwd.c to use struct gak_password instead of krb5_data,
sam2_process wasn't altered to match.  We don't see a problem when the
password is read through the prompter (as with kinit), because the
password winds up in the storage field at the beginning of the
gak_password structure.  But when a password is supplied as a
parameter (as with ksu), the storage field is empty and we get the
wrong answer from sam2_process.

ticket: 7862
target_version: 1.12.2
tags: pullup
Don't use system dictionary files for DB2 tests

The system dictionary may contain entries with punctuation, which can
confuse the shell.  It's more predictable to always use the word list
from the source tree.

ticket: 7860
status: open
Generate dependencies for t_stringattr

When t_stringattr.c was introduced, it wasn't added to EXTRADEPSRCS,
so no dependencies were created for it.  Fix that now.
Update doc build instructions

Documentation build instructions in doc/README were out of date.
Update them.

ticket: 7864 (new)
tags: pullup
target_version: 1.12.2
Support referrals from Windows Server 2003

Although RFC 6806 Section 7 requires servers to indicate a client
referral in a WRONG_REALM message, Microsoft Windows Server 2003
returns this information in a message with error code
PRINCIPAL_UNKNOWN.  Failure to follow the referral in these messages
prevents referral chasing in Windows Server 2003 forests.  Detect
referral messages of this type by checking for a non-empty
client.realm field in the response, and activate the referral logic in
these cases.

[tlyu@mit.edu: style, comments, and commit message]

ticket: 7856 (new)
target_version: 1.12.2
tags: pullup
Make KDC "status" statements more homogeneous

Generally we want KDC status strings to be concise, informative and follow
some common rules:

- All letters in the status string should be capitalized;
- the words in the status phrase are separated by underscore;
- abbreviations should be avoided.  Some acceptable "standard" acronyms
  are AS_REQ, TGS_REP etc.
- since in almost all cases KDC status is set on error, no need
  to state this fact as part of the status string;
- KDC status string should be an imperative phrase.

For example, "DECRYPT_SERVER_KEY".

This commit is to modify some KDC status messages to follow this format.

Even though KDC status messages are not standardized, it is possible that some
administrators use them in the Kerberos log file processing. Hence, the vast
majority of them are left unchanged pending further investigation (mostly,
feedback from the administrators).