While it's unlikely that so many (large) items are allocated, this is
technically more correct. The result previously could overflow an
unsigned int (the conversion to size_t happened afterwards).
This clearly never was correct, but didn't cause problems so far.
However, GCC 10 will default to `-fno-common` instead of
`-fcommon` (https://gcc.gnu.org/PR85678), so compilation there fails
with something like:
```
libtool: link: gcc ... -o .libs/swanctl ...
ld: commands/load_authorities.o:strongswan/src/swanctl/./swanctl.h:33:
multiple definition of `swanctl_dir'; commands/load_all.o:strongswan/src/swanctl/./swanctl.h:33: first defined here
```
Fixes: 501bd53a6c ("swanctl: Make credential directories relative to swanctl.conf")
Closesstrongswan/strongswan#163.
GCC 9+ and clang 4+ (partially) optimize out usages of
chunk_from_chars() if the value is read outside of the block where the
macro is used. For instance:
```
chunk_t chunk = chunk_empty;
if (...)
{
chunk = chunk_from_chars(0x01, 0x06);
}
/* do something with chunk */
```
The chunk_from_chars() macro expands to a chunk_t declaration, which is
technically only defined inside that block.
Still, with older GCC versions the fourth line was compiled to something
like this:
```
mov WORD PTR [rsp+14], 1537 # 0x0106 in little-endian
lea rdx, [rsp+14]
mov ecx, 2
```
However, with GCC 9.1 and -O2 the first instruction might be omitted
(strangely the others usually were not, so the chunk pointed to whatever
was stored on the stack). It's not easily reproducible, so there are
situations where the seemingly identical code is not optimized in this
way.
This query should detect such problematic uses of the macro (definition
and usage in different blocks).
References #3249.
IBM Z is big-endian, IBM Power runs in little-endian mode.
Botan requires a fix for issues with GCC and amalgamation enabled (target
pragma ‘*’ is invalid) on ARM64 and IBM Power, while wolfSSL can't be
compiled successfully on IBM Z without an additional patch.
libunwind is not available for x390x, but since we explicitly disable
such backtraces it's not necessary anyway.
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 1806ba0890 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: 7533cedb9a ("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.