Pretty sure it is not useful for applications to be able to write to
this.
However, caveat: this could break programs that expect to pass around
&heimdal_version or &heimdal_long_version to functions that expect
pointers to non-const objects even if they don't modify them.
Note: This changes the types of public symbols. It is unlikely that
any applications would rightly _write_ to these arrays, but it is
possible they might require some UNCONST in order to pass the
pointers to other functions that are missing const qualifiers.
This changes the public header file but I doubt it was ever intended
that applications could change these by writing to them. (Not sure
why they're not declared as const arrays in any case.)
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
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
