We previously checked for older library versions without locking support at
all. But newer libraries can be built in single-threading mode as well, where
we have to care about the locking.
Real AEADs directly provide a suitable IV generator, but traditional crypters
do not. For some (stream) ciphers, we should use sequential IVs, for which
we pass an appropriate generator to the AEAD wrapper.
With OpenSSL commit 929b0d70c19f60227f89fac63f22a21f21950823 setting an empty
key fails if no previous key has been set on that HMAC.
In 9138f49e we explicitly added the check we remove now, as HMAC_Update()
might crash if HMAC_Init_ex() has not been called yet. To avoid that, we
set and check a flag locally to let any get_mac() call fail if set_key() has
not yet been called.
sem_init() is deprecated on OS X, and it actually fails with ENOSYS. Using our
wrapped semaphore object is not an option, as it relies on the thread cleanup
that we can't rely on at this stage.
It is unclear why startup synchronization is required, as we can allocate the
thread ID just before creating the pthread. There is a chance that we allocate
a thread ID for a thread that fails to create, but the risk and consequences
are negligible.
Since we can't get rid of all unmet dependencies (at least not in every
possible plugin configuration) the message is more confusing than
helpful. In particular because a detailed warning about plugin features
that failed to load due to unmet dependencies is only logged on level 2.
Some tokens might not fail when creating EC public keys in the incorrect
format, but they will later not be able to use them to verify signatures.
References #872.
Some CAs don't use SHA-1 hashes of the public key as subjectKeyIdentifier and
authorityKeyIdentifier. If that's the case we can't force the
calculation of the hash to compare that to authorityKeyIdentifier in the CRL,
instead we use the subjectKeyIdentifier stored in the issuer certificate, if
available. Otherwise, we fall back to the SHA-1 hash (or comparing the
DNs) as before.
There is a similar function to map key_type_t and hasher_t to an OID,
but this maps schemes directly (and to use the other function we'd
have to have a function to map schemes to hash algorithms first).
While these files are generated they don't really change and are not
architecture dependant. The previous solution prevented cross-compilation
from the repository as `bliss_huffman` was built for the target system but
was then executed on the build host to create the source files, which
naturally was bound to fail.
The `recreate-bliss-huffman` make target can be used inside the bliss
directory to update the source files if needed.
Fixes#812.
Martin Willi