Modify the signature of the checksum operation in the
krb5_checksum_type structure so that it processes iovecs rather than
solid blocks of data.
Update all of the implementations of these functions for all of the
checksum types that we support so that they process iovecs, either
by iterating through the iovec in each function, or by calling
_krb5_evp_digest_iov or _krb5_evp_hmac_iov()
Update callers of these functions so that they turn their single blocks
of data into a single iovec of the correct type before calling checksum
Add a function which will perform an HMAC over a set of iovecs,
using the hcrypto provided HMAC functions.
Join contiguous iovecs together before passing them to the hash
function so we make as few calls into the hash as possible.
Add a pair of functions which can be used to allocate and free
an HMAC_CTX structure on the heap. This means that the caller doesn't
need to know the size of the underlying structure.
When replying to a door call, if allocating the buffer using malloc()
fails, we return EAGAIN to the client to avoid it hanging, using a
variable on the stack. However in this case the code did not reset the
reply length, which would result in it reading past the end of the stack.
At the expense of a goto, this patch uses the same path for returning an
error as if it was generating by the application.
Also, ensure that reply->length is set to zero when returning an error;
it shouldn't affect the client as it will not read this in the event of
a non-zero return code, but it avoids leaking uninitialized memory.
The ucred_t argument must be initialized to zero otherwise it is assumed to
point to allocated memory. Also, the logic is inverted: getpeerucred()
returns zero on success, not failure.
In the interest of being paranoid, when a WinCNG crypto or digest
context is being reinitialized, zero out the backing store as well
as destroying the handle.
This is required as the PKCS#11 library needs to be reinitialized after
forking. This was causing a problem with ipropd.
This fix appears to incur a repeatable 10ms performance penalty on aes-test.
Caching the initialization status using a once control and invalidating it
on fork provided no measurable performance benefit on Solaris 11. Other
approaches would not be thread-safe or would involve more intrusive code
changes, such as exposing heimbase's atomics.
Similar fix to a88d0066, but for the WinCNG EVP backend. However this
is just a fix for leaking handles if the same EVP context is used with
a new key; there is no functionality issue as cipherstate is maintained
directly in the EVP context, not internally by WinCNG.
Clients of the EVP API can reinitialize message digest contexts
without destroying them. The PKCS#11 backend assumed they were
only used once, and was leaking session handles upon reinitialization.
This fix disposes of any existing PKCS#11 message digest context
in the initialization method.
Some callers of EVP_DigestUpdate (such as libntlm) pass NULL as the
data argument. PKCS#11 returns CKR_ARGUMENTS_BAD which may poison
the context. Pass an empty string to C_DigestUpdate work around this.
81c778e broke the PKCS#11 hcrypto backend broke for many cases as it did
not support cipherstate resetting. (Prior to 81c778e, which was to fix#194,
the PKCS#11 backend did not support cipherstate chaining across invocations.)
hcrypto backends that maintain cipherstate independently of the hcrypto
context IV field need to set EVP_CIPH_ALWAYS_CALL_INIT to avoid the two
diverging. Their init function should support resetting the cipherstate
independently of key scheduling.
despite the fact that the called function returns void,
returning a result here throws an error with solaris cc.
just call the function and don't return
camellia-ntt had none of its symbols renamed into the hc_ namespace,
and rand's missed timer_method (while all other methods were done). rename
these like we do for others
if when we need to determine if getauxval sets errno, we determine it doesn't
after getting a 0 return code, make sure we return a value, since we didn't
previously. fall through to code we'd otherwise have called in this case
above.
depending what's available when you compile for iOS it's possible to
be __APPLE__ and not have CF; actually test for it instead of blythely
assuming it can be used
This allows the optimized checksum->verify() function to be used.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
(cherry picked from Samba commit fb318ab0203297019c5e47c6bef4a9abfdeea8a5)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
(cherry picked from Samba commit 05cc099499ef3a07d140981ef82937c842a3ffef)
Doing an fsync per-record when receiving the complete HDB is a performance
disaster. Among other things, if the HDB is very large, then one slave
receving a full HDB can cause other slaves to timeout and, if HDB write
activity is high enough to cause iprop log truncation, then also need full
syncs, which leads to a cycle of full syncs for all slaves until HDB write
activity drops.
Allowing the iprop log to be larger helps, but improving receive_everything()
performance helps even more.
This reverts commit ccb63bb0aa, which was
unnecessary and broke tests/kdc/check-kadmin (and other things).
host->port happens to be an unsigned short, so that promotion to an integer in
the snprintf() call is safe in that the promoted value will still be
non-negative, and no larger than an unsigned short's maximum value. We're
still assuming that 7 bytes is sufficient to hold the text representation of
that maximum value, which indeed it is, assuming sizeof(unsigned short) == 2
and CHAR_BIT == 8, which are fair assumptions here. A better patch, if we
needed it, would be to just make portstr[] an array of 11 char, or perhaps make
it a VLA (but we can't yet use VLAs, I don't think, because of older Windows
systems that must be supported still).
Heimdal will refuse to create new entries when an entry already exists even
if said entry has no kerberos info and is a new entry.
This patch fixes this issue by allowing object modifications even if the
flags disallow them when we are inserting a new principal on the database.
Signed-off-by: Francisco Blas Izquierdo Riera (klondike) <klondike@gentoo.org>
