This makes more sense as a module for them to live in. Now, util no
longer depends on crypto_core and can thus potentially be used in
crypto_core in the future (functions like min/max may be useful).
It can't happen in almost every reality, except when the RNG is fairly
broken and doesn't add 2 fake DHT friends on startup. Still, this code
should be defensive and never index outside `num_friends` elements.
Right now it only gets built from the first 2 friends in the DHT friend
list: either friend 0 and then 1 or friend 1 and then 0. The randomness
in this code doesn't make sense unless the intention was to select from
all friends, which the code will now do.
Also: use uniform random distribution to select the friends rather than
modulus, which is only uniform for powers of 2.
Ideally this would be able to reach some of the events, so we can write
code to respond to those events, but so far only the friend request
event actually happens.
Disabled a whole bunch of rules from the MISRA-C set. Some of them
should be fixed, but most of the ones we violate have good reasons. This
PR documents those reasons.
This isn't in production yet. It's in the new announce store code. The
problem was that a negative plain_len was converted to unsigned, which
made it a very large number.
`system_random()` can fail and return NULL, which should be handled by
toxencryptsave functions.
Also synced function comments between .h and .c file for toxencryptsave.
Every use of this function needs to allocate the same buffer. None of
the callers uses a differently sized buffer, so we might as well put it
in a struct and have the type checker prove the buffer size is correct.
Also rename `ip_ntoa` to `net_ip_ntoa` to avoid clashes with ESP-IDF
system libraries which define this function as well.
This is the "server-side" part of the new friend finding system,
allowing DHT nodes to store small amounts of data and permit searching
for it. A forwarding (proxying) mechanism allows this to be used by TCP
clients, and deals with non-transitivity in the network.
These help creating fuzzer fixtures with non-trivially constructed
objects and takes care of cleaning them up afterwards so the fuzzer code
can focus on the system under test.
Nothing checks whether these layers are actually observed. The bazel
build does check this, so there's no need to have this documentation in
the cmake build. It'll just go out of date.
Generating functions is ugly. Ideally astyle wouldn't ask us to write 4
lines of code where 1 would be more readable, but such is life (until we
move to clang-format).
