If the `recvbuf` network function returns 0 all the time, that means
there is never any data available on the TCP socket. This change makes
it so there is a random amount of data available on the TCP socket.
This invalidates the bootstrap fuzzer corpus.
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.
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.
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.
The idea here is to have a `Network` object that contains functions for
network operations and an optional userdata object that can manage those
network operations. This allows e.g. a fuzzer to replace the network
functions with no-ops or fuzzer inputs, reducing the need for `#ifdef`s.
Cimple cannot actually find these without also causing false positives,
but I found them with cimple before removing the code causing false
positives again.
These were found by the new stronger type check in cimple. The one
bugfix is in `crypto_sha512_cmp`, which used to think `crypto_verify_32`
returns bool while actually it's -1/0/1.
Use of `strcpy` in these particular cases was safe, but it's hard to
tell and also useless. `strcpy` would effectively need to do another
`strlen` which we already did.
Also removed sprintf, which was also safe in this case but it's easier to
be "obviously safe", especially for static analysers.
These have all dependencies built with asan/tsan, so they can do deeper
sanity checks such as checking what opus is doing with our buffers.
The asan check currently fails for me locally, so these are not yet set
to be required for PRs to be merged.
atoi doesn't check if the conversion from string to int succeeded
which doesn't allow us to do proper error handling.
We also now make sure that the port argument is a valid port
in addition to being properly converted
This seems to be the sweet spot for the current tokstyle implementation.
4 cores gives the same speedup, 5 also, 6 makes it slower, and 2 also
makes it slower.
iphydf