Looks like a cipher suite without DHE was selected previously.
Could be a side-effect of dc1085734f34 ("testing: Remove unnecessary
FreeRADIUS dh_file option as recommended in the log").
Errors in load-testconfig are hidden due to not checking scp
return code and mute all errors. Add -e to trap script on
any errors in this script.
References strongswan/strongswan#2310
Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
OpenSSH defaults have changed and scp stopped to work with newer versions.
There are 2 options to fix it, either use -O (legacy scp protocol)
with scp, or enable the sftp subsystem in the SSH server config.
This fix uses the second variant.
Closesstrongswan/strongswan#2310
Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
Instead of just adding the offset internally, this way the reported
base address is always the first assignable address (e.g. for
192.168.0.0/24 vs. 192.168.0.1/24).
Closesstrongswan/strongswan#2264
If the regular daemon is running, it creates an unconditional routing
rule for the routing table. The rule that charon-nm tries to create,
which excludes marked IKE/ESP traffic to avoid a routing loop, then
can't be installed and we'd end up with said loop.
Closesstrongswan/strongswan#2230
As recommended by RFC 2985, section 5.4.1:
ChallengePassword attribute values generated in accordance with this
version of this document SHOULD use the PrintableString encoding
whenever possible. If internationalization issues make this
impossible, the UTF8String alternative SHOULD be used.
Even though the RFC continues with
PKCS #9-attribute processing systems MUST be able to recognize and
process all string types in DirectoryString values.
there might be older SCEP server implementations that don't accept
UTF8String-encoded passwords. In particular because previous versions of
PKCS#9 defined this attribute's type as a CHOICE between PrintableString
and T61String.
References strongswan/strongswan#1831
Can be useful if the CID inside the VM is not known.
The \htmlonly\endhtmlonly hack is used to avoid compiler warnings due
to /* inside a block comment.
These allow, for instance, a vici client on a host to communicate with
an IKE daemon running in a VM.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
If somebody copies our .gitignore and tries to import the source code,
the proposal_keywords.c file will not be added as it's ignored by the
`*keywords.c` pattern we use to ignore gperf-generated source files.
Closesstrongswan/strongswan#2014
If a base address is configured, we don't expect the pool to be empty,
so reject the creation (e.g. with the broadcast address as base).
References strongswan/strongswan#2205
We explicitly pass the final .info file prepared with lcov, so there is
no need to search for other files (that then won't work anyway). The
search also finds the uncleaned .info file, which includes the test code.
The latter should have gotten ignored anyway, but the patterns are
apparently not correct anymore. So fixing that as well just to be sure.
There are definitions of RNG in <wolfssl/wolfcrypt/settings.h> and
<wolfssl/wolfcrypt/random.h> that play havoc with the literal RNG being
used in the expansions of PLUGIN_*(RNG, ...) when ##-concatenated to
build the enum value FEATURE_RNG.
The #undef in wolfssl_cmmon.h only had an effect if wolfSSL was built
with EdDSA or FIPS enabled, otherwise, the headers that define RNG were
not pulled in before it.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
This is a patch from the OpenWrt package sources necessary to adapt to
changes from 2008 that abstracted the option datatype (added a list
type).
Signed-off-by: Noel Kuntze <noel.kuntze@thermi.consulting>
Reviewed-by: Philip Prindeville <philipp@redfish-solutions.com>
With GCC 13, the compiler apparently applies new aliasing optimizations
when compiled with -O2 and without -fno-strict-aliasing. This caused
the application of the second padding bit, where the state was accessed
via uint8_t[], to be moved before the loop that absorbs the buffer into
the state, where the state is accessed via uint64_t[], resulting in
incorrect output. By only accessing the state via uint64_t[] here the
compiler won't reorder the instructions.
musl's headers define a lot of networking structs. For some, the
definition in the Linux UAPI headers is then suppressed by e.g.
__UAPI_DEF_ETHHDR.
Since we included musl's net/ethernet.h, which includes netinet/if_ether.h
that defines `struct ethhdr` (and the above constant), **after** we
include linux/if_ether.h, there was a compilation error because the
struct was defined multiple times.
However, simply moving that include doesn't fix the problem because for
ARP-specific structs the Linux headers don't provide __UAPI_DEF* checks.
So instead of directly including the linux/ headers, we include those
provided by the C library. For glibc these usually just include the
Linux headers, but for musl this allows them to define the struct
directly. We also need to move if.h and add packet.h, which define
other structs (or include headers that do so) that we use.
Fixes: 187c72d1afdc ("dhcp: Port the plugin to FreeBSD/macOS")
The previous option caused such requests to be enabled if not explicitly
disabled, which only the vici plugin did, for all other backends requests
would have been sent.
References strongswan/strongswan#2016
Only the vici plugin previously set OCSP_SEND_REPLY explicitly, all other
backends would have defaulted to OCSP_SEND_BOTH.
References strongswan/strongswan#2016
In particular for static code analyzers. The previous nesting of case
statements inside of a while loop that's inside a switch statement and
a wrapping block with declaration was quite weird and Coverity didn't
like it (it figured that `type` was uninitialized even when it assumed
that get_type() returned a known type for which a case statement
existed).
AWS-LC rejects public keys with explicitly encoded parameters but allows
private keys that use explicit encodings of the NIST curves. Since the
more important aspect is that public keys are rejected, this addition to
the warning message points that out.
References strongswan/strongswan#1907
