This avoids the use of a variable length array, which should probably
be avoided in general due to potential performance, portability and
security issues (not in this particular case, though).
Closesstrongswan/strongswan#1095
GCC assumes this->b is zero (or may be zero) and spits out the following
warning (or error with -Werror):
src/libstrongswan/plugins/fips_prf/fips_prf.c:124:12: error: array subscript 18446744073709551615 is above array bounds of ‘uint8_t[<U8090>]’ {aka ‘unsigned char[<U8090>]’} [-Werror=array-bounds]
124 | one[this->b - 1] = 0x01;
| ~~~^~~~~~~~~~~~~
Even though the assignment of `removed` to `out_row` is tied to the
`found_removed` flag, which is only set if `removed` is set, the
compiler complains that it may be used uninitialized.
GCC 12 produces weird code when a callback is called directly (e.g.
parse_bool() via parse_option() in vici_config.c). Instead of the actual
pointer, it explicitly passes 0 as first argument, which likely causes
a segmentation fault. It doesn't happen when called indirectly via
function pointer that has void* as first argument, which this patch
kinda replicates for direct calls to avoid the issue.
Closesstrongswan/strongswan#1053
This should make it clearer to what the log messages generated by
verify_trust_chain() are related (in particular if building the chain
fails or the cert has expired).
More of this code was already removed with previous commits.
While versions < 1.1.1 are not officially supported anymore, 1.0.2 might
still be in use because before 3.x that was the latest version with
official FIPS support (OpenSSL apparently also provides extended commercial
support for it).
The old API has been deprecated with OpenSSL 3 and direct access to the
state isn't possible via EVP API. In the future we might just remove this
implementation but we'd probably have to implement EAP-AKA' first, which
uses HMAC-SHA-256 with IKEv2's prf+ construct to derive keys instead
of this weird construct (plus what fips-prf builds around it) that's used
by EAP-AKA.
The HKDF-Expand() function defined in RFC 5869 is basically the same as
IKEv2's prf+(), so we can use the former to implement the latter.
However, we can only support HMAC-based PRFs this way, which should be
fine as others are rarely used.
Tobias Brunner