This is the recommended location and import config as it allows running the
tests against installed versions of the package. And while the test file
itself is automatically included in the source distribution this way, the
__init__.py file is not, so we still have to update MANIFEST.in.
This reverts commit 1806ba0890bc503df3dacf01992ec1bca2b0fbb0 as the
workaround is not required anymore and now actually fails because
pre-installed tools have a dependency on libtool.
While the TPM expects and returns the data in big-endian, the SAPI
implementation converts it to native-endianness. As stated in the
SAPI specification (section 3.2):
8. All SAPI data SHALL be in native-endian format. This means that
the SAPI implementation will do any endian conversion required for
both inputs and outputs.
So to use the exponent in a chunk we have to convert it to big-endian again.
Fixes: 7533cedb9a8a ("libtpmtss: Read RSA public key exponent instead of assuming its value")
RFC 7296, section 2.21.3:
If a peer parsing a request notices that it is badly formatted (after
it has passed the message authentication code checks and window
checks) and it returns an INVALID_SYNTAX notification, then this
error notification is considered fatal in both peers, meaning that
the IKE SA is deleted without needing an explicit Delete payload.
RFC 7296, section 2.21.3:
If a peer parsing a request notices that it is badly formatted (after
it has passed the message authentication code checks and window
checks) and it returns an INVALID_SYNTAX notification, then this
error notification is considered fatal in both peers, meaning that
the IKE SA is deleted without needing an explicit Delete payload.
While the check probably made sense when strongSwan 4.x was started, gperf
version 3.0.1 was released in 2003, so it's very unlikely that version 2.x
is still around anywhere.
When building from a tarball gperf is not required as the generated
files already exist, however, when building from the repository that's
not the case, so warn the user if gperf is not found.
This happened when installing a duplicate bypass policy for a locally
connected subnet. The destructor and the kernel-net part already
handle this correctly.
Without this we only would learn that the algorithm isn't actually
available (e.g. due to FIPS mode) when set_key() is called later, so there
isn't any automatic fallback to other implementations.
Fixes#3284.
This adds a new constraint for vici/swanctl.conf that enforces that the
certificate chain of the remote peer contains a CA certificate with a
specific identity.
This is similar to the existing CA constraints, but doesn't require that
the CA certificate is locally installed, for instance, intermediate CA
certificates received by the peers.
Wildcard identity matching (e.g. "..., OU=Research, CN=*") could also be
used for the latter, but requires trust in the intermediate CA to only
issue certificates with legitimate subject DNs (e.g. the "Sales" CA must
not issue certificates with "OU=Research"). With the new constraint
that's not necessary as long as a path length constraint prevents
intermediate CAs from issuing further intermediate CAs.
This is a prominent example where the identity based CA constraint is
benefical. While the description of the test claims a strict binding
of the client to the intermediate CA, this is not fully true if CA operators
are not fully trusted: A rogue OU=Sales intermediate may issue certificates
containing a OU=Research.
By binding the connection to the CA, we can avoid this, and using the identity
based constraint still allows moon to receive the intermediate over IKE
or hash-and-url.
Enforcing CA based constraints previously required the CA certificate file
to be locally installed. This is problematic from a maintencance perspective
when having many intermediate CAs, and is actually redundant if the client
sends its intermediate cert in the request.
The alternative was to use Distinguished Name matching in the subject
identity to indirectly check for the issuing CA by some RDN field, such as OU.
However, this requires trust in the intermediate CA to issue only certificates
with legitime subject identities.
This new approach checks for an intermediate CA by comparing the issuing
identity. This does not require trust in the intermediate, as long as
a path len constraint prevents that intermediate to issue further
intermediate certificates.
This makes sure the nonce sent in an OCSP request is contained in the
response (it also fixes parsing the nonce, which didn't matter so far
as it was never used)
