warning: 'mp_read_unsigned_bin' is deprecated
(declared at ./libtommath/tommath.h:732): replaced by mp_from_ubin
[-Wdeprecated-declarations]
warning: 'mp_unsigned_bin_size' is deprecated
(declared at ./libtommath/tommath.h:731): replaced by mp_ubin_size
[-Wdeprecated-declarations]
warning: 'mp_to_unsigned_bin' is deprecated
(declared at ./libtommath/tommath.h:733): replaced by mp_to_ubin
[-Wdeprecated-declarations]
warning: 'mp_unsigned_bin_size' is deprecated
(declared at ./libtommath/tommath.h:731): replaced by mp_ubin_size
[-Wdeprecated-declarations]
warning: ignoring return value of 'mp_init_multi',
declared with attribute warn_unused_result [-Wunused-result]
warning: ignoring return value of 'mp_to_unsigned_bin',
declared with attribute warn_unused_result [-Wunused-result]
warning: ignoring return value of 'mp_read_unsigned_bin',
declared with attribute warn_unused_result [-Wunused-result]
Change-Id: I510fd7a57c9cd52b59086a85d13aa6204ebb9fd9
Refactor the call to verify_common() to pass the krb5_cred by
pointer to and call krb5_free_cred_contents() in
verify_user_opt_int() instead of verify_common().
Calling strerror() with a negative value is an error.
Besides fixing that, we streamline hx509_get_error_string(), making it much
simpler and easier to read.
Samba clients are often machine accounts with non-default salts that
will fail if they can't use the AES encryption type they know the KDC
supports. The problem is that arcfour-hmac-md5 has no salt so was
being used in preference.
Samba started to fail when
kdc_config->preauth_use_strongest_session_key = true;
was forced into the KDC configuration.
The history here is an attempt to avoid Kerberos v4 salts in des-cbc-crc
keys, but this instead broke Samba clients with AES-keys on machine accounts
as these have a non-default salt by default. These accounts were incorrectly
restricted to arcfour-hmac-md5 and they didn't like that.
A broader fix than Samba commit 8e1efd8bd3bf698dc0b6ed2081919f49b1412b53
REF: https://lists.samba.org/archive/samba/2021-October/237844.html
Samba BUG: https://bugzilla.samba.org/show_bug.cgi?id=14864
Change-Id: Ia8908a5a2eef107e6b133d7f0e4343c1988c18bb
First, we enlarge Member's val field to int64_t.
Then we warn about skipping 2int, int2, and parse units glue for such
things with too-large members.
And we error out when generating the template for such things with
>UINT32_MAX members.
What about too-negative members? That could be a thing for INTEGER /
ENUMERATED. We'll look at that later.
We sometimes use this idiom where we ignore the result of some function
such as krb5_unparse_name() and then we log something and we use the
ternary operator to handle any error from that function by substituting
a string like "<unknown>" or "<out-of-memory>". This yields some static
analyzer complaints. Maybe casting the function's result to void will
help.
Coverity thinks `handle` in lib/krb5/send_to_kdc.c:krb5_sendto_context()
at 1241 can be NULL, leading to a NULL derefence in `get_next()`. This
is an attempt to fix this by having `get_next()` check handle for NULL.
