This is almost certainly intended never to be written to, so let's
let the operating system detect that mistake for us by mapping it in
a .rodata segment mapped read-only that will cause SIGSEGV on write.
fix https://github.com/heimdal/heimdal/issues/1136
This way if anything _does_ write to it, it has the opportunity to be
caught by SIGSEGV, by having zero_ivec in a .rodata segment mapped
read-only.
fix https://github.com/heimdal/heimdal/issues/1135
If a char width is specified the number of output buffer bytes
consumed might be greater than one. Update append_char() to
return the number of bytes consumed and use that value in xyzprintf()
instead of one.
The struct _krb5_key_type.type is krb5_enctype. Cast it to
krb5_keytype before assigning to the 'krb5_keytype *keytype'
output variable to avoid a warning from Clang 1500 on Darwin.
If the master is unreachable for a while we can end up with expired
tickets that don't get refreshed, then ipropd-slave gets stuck until
it's manually restarted.
Excluded: libtomath and libedit files, most of which appear to be
testing or example code not involved in production, and which are
derived from an upstream that should perhaps have patches submitted
upstream instead.
fix https://github.com/heimdal/heimdal/issues/1111
Check for OpenSSL features while LDFLAGS and CFLAGS are set with
the paths provided in the configure command line. This allows
detecting a non-default OpenSSL's version correctly, such as
on FreeBSD with one of the OpenSSL 3.0 ports.
decrypt_internal_derived(), decrypt_internal_enc_then_cksum(),
decrypt_internal(), and decrypt_internal_special() execute the
following pattern where 'p' is an allocation of size 'len'
l = len - n
memmove(p, p + n, l);
result->data = realloc(p, l);
if (result->data == NULL && l != 0) {
free(p);
return krb5_enomem(context);
}
result->length = l;
which when compiled by gcc 13.0.1-0.12.fc38 or gcc-13.0.1-0.13.fc39
generates the following warning
warning: pointer 'p' may be used after 'realloc' [-Wuse-after-free]
The C language specification indicates that it is only safe to free()
the pointer passed to realloc() if errno is set to ENOMEM. Yet the
warning is generated by the following pattern
l = len - n
memmove(p, p + n, l);
errno = 0;
result->data = realloc(p, l);
if (result->data == NULL && l != 0) {
if (errno == ENOMEM)
free(p);
return krb5_enomem(context);
}
result->length = l;
The value of performing the realloc() is questionable. realloc()
in many cases will need to perform a second allocation of the
smaller size and then perform a memcpy() which will slow down
the operation without saving much memory. The allocation is already
very small.
This change avoids the warning by removing the realloc() entirely.
The interface between the krb5 mechanism and the mechglue API
gsskrb5_extract_authtime_from_sec_context() assumed the authtime would fit into
an uint32_t, which is not the case on platforms where time_t is 64-bit.
Fixes: #1073
This reverts commit a9c0b8f264.
From Joseph Sutton:
> I found that this commit would result in `KRB5KRB_AP_ERR_BAD_INTEGRITY`
> errors in Samba whenever explicit FAST armor was present. Reverting the
> commit made FAST work again.
> It should be safe to use `tgs_ac` here, since it will always be non-NULL if
> `r->explicit_armor_present` is true. Maybe a local variable
> `explicit_armor_present` (which would be assigned to
> `r->explicit_armor_present` before the function returns successfully) would
> help a static analyser to deduce that its value doesn't change within the
> function, and that `tgs_ac != NULL` still holds.
a9c0b8f264 (commitcomment-95581208)
