[krbdev.mit.edu #7488] Various nits in krb5-1.10.3

[Nickolai Zeldovich via RT]

src/plugins/preauth/pkinit/pkinit_clnt.c:1392 checks whether
out==NULL, but it's already known to be non-NULL at that point.
Perhaps it was meant to check out[i-1]==NULL?

src/lib/kdb/kdb_log.c:207 checks if cur_sno==ULONG_MAX to detect
overflow, but that's always false on a system with 64-bit long, since
cur_sno is kdb_sno_t==uint32_t.

src/lib/gssapi/spnego/spnego_mech.c:3979 tries to check whether
gssint_get_der_length returns a negative value, but the check is
always false because gssint_get_der_length's return value is assigned
to seqsize, an unsigned int.  Similar problems show up at
src/lib/gssapi/spnego/spnego_mech.c:3996 and src/kdc/kdc_util.c:1121.

src/kdc/kdc_preauth.c:510 multiplies the number of enctypes it got
from a krb5_kdc_req by sizeof(krb5_keyblock), and allocates that much
memory, without checking for overflow.  On a 32-bit machine,
sizeof(krb5_keyblock) is 4 times larger than the sizeof(krb5_enctype)
that the client has to send along with the request, so it seems
vaguely possible for a client to send 2^30 enctypes and get the server
to allocate 2^32=0 bytes of memory.  I didn't check whether a client
can really send an as_req with 2^30 enctypes, but it may be worth
fixing just in case.

src/kadmin/dbutil/dump.c:1855 multiplies a value it read from the dump
file by sizeof(krb5_key_data), and allocates that much memory, without
checking for overflow.  This doesn't seem like a particularly big
deal, since the dump file is likely trusted, though.

Nickolai.