Instead of using `target_link_modules`, which does magic that we no
longer need, because we only have 1 library we install, and all binaries
we build link statically because they need access to internal symbols.
We now depend on libsodium unconditionally. Future work will require
functions from libsodium, and nobody we're aware of uses the nacl build
for anything other than making sure it still works on CI.
It doesn't work, because esp32 has too little RAM (320KB). DHT is a
240KB struct, so even just allocating that immediately fails. We'll need
to think carefully about trimming that if we ever want this to work on
embedded devices.
This function will return an IP address string associated with a peer.
If the peer is not accepting direct connections a placeholder value
will be returned, indicating that their real IP address is unknown.
We do not return TCP relay IP addresses because a TCP connection
with a peer may use multiple relays simultaneously.
This mainly saves spam in test logs, but may save some packets here and
there, if nodes are randomly selected twice for GET_NODES and onion
routing packets.
Rather than aborting the process on invalid group save data we
either try to continue if possible, or abort the saving/loading
instead of the entire process
memset() treats the passed buffer as a char* array, assigning to every
1-byte of the array the value. So for a single 4-byte int32_t element,
it is assigning bytes 0, 1, 2 and 3 of it to -1. It happens that -1 is
0xFF, so in the end the uint32_t is set to 0xFFFFFFFF, which is -1 in
the two's complement, so the memset() actually produces the correct
result in the end, assuming the platform uses two's complement integers.
Assigning it in the loop is less error-prone, as using memset() on
non-1-byte wide arrays with a non-zero value is fishy, and it is more
portable as we don't have to assume the use of two's complement.
It looks like in a future version of the C standard, C23, two's
complement is the only integer format in C23 (thanks to @robinlinden on
IRC for pointing that out), so perhaps we shouldn't be as concerned with
the portability here? Though @iphydf says that it's still a good idea to
use a for-loop for this case.
This allows client developers to use the private API without
needing to manually specify the header path in the source
code, which may vary from system to system.
Docker is defaulting to using BuildKit for building images since version
23.0 (2023-02-01), which is not compatible with this script. The script
was fishing the hash of the intermediate build container in which the
build has failed, in order to run the sha256sum in that image, however
with BuildKit there are no longer any intermediate build containers,
which breaks the script.
The legacy builder is supposedly getting removed in a future version of
Docker, which is why we embrace BuildKit instead of reverting to the
legacy builder via DOCKER_BUILDKIT=0:
$ DOCKER_BUILDKIT=0 docker build ...
DEPRECATED: The legacy builder is deprecated and will be removed in a
future release. BuildKit is currently disabled; enable it
by removing the DOCKER_BUILDKIT=0 environment-variable.
While DOCKER_BUILDKIT=1 is unnecessary on Docker >= 23.0, it's needed
for anyone running older Docker, so it makes sense to have it in for
now, while everyone transitions.
