* Move ThreadSanitizer job to the scheduled jobs (once a day): all our tests
are intrinsically mono-thread and this job takes quite some time
* Two explicit jobs to test LTO and Gold linker, used by oss-fuzz
* Two explicit jobs for Windows (with msys2)
* Run address sanitizer only on the 4 main jobs: newest/oldest gcc/clang
* Reduce the time used by fuzzing jobs. Note that oss-fuzz is
continuosly fuzzing our code!
* Move the no x86_64 jobs to a dedicated file
This way, the main matrix is a little bit simpler and the CI jobs last a
little shorter
Without the `-fsanitize-memory-track-origins` flag, MSAN job is ~30%
faster. Since this flag is useful only while debugging (and not to
simply discover memory issues), avoid it on the CI. Note that, by
default it is still enabled by default.
Right now, MingW runs on *every* ubuntu builds: limit it only to the
standard matrix (i.e. ubuntu 20.04, 22.04, 24.04 with default
configuration), without any sanitizers (note that MingW doesn't support
*san anyway).
armhf job is by far the longest job in the CI: remove asan configuration
to make it faster. Note that we already have a lot of different jobs (on
x86_64) with some sanitizers, and that the other 2 jobs on arm/s390x don't
have asan support anyway.
If we really, really want a job with arm + asan we can add it as a
async/scheduled job.
Remove an old workaround for ubuntu jobs
Avoid installing packages needed only for the documentation
About `check_symbols.sh` script: even if uses the compiled library/objects,
it basicaly only checks if we are using, in the source code, same functions
that we shoudn't. We don't need to perform the same kind of check so
many times..
Add a simple job with macos-14 on M1.
https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/)
There are some issues with external dependencies (they are installed but
autoconf script doens;t find them) so keep it simple.
On macos-13 it seems that:
* there is no `realpath` program (even if coreutils has been
installed...)
* most of the filesystem is read only (we can't write on /usr/lib).
So I change
```
make install DESTDIR=$(realpath _install)
ls -alhHR _install
```
to
```
DESTDIR=/tmp/ndpi make install
ls -alhHR /tmp/ndpi
```
for all the jobs
Fix a warning on GitHub logs:
```
Node.js 16 actions are deprecated. Please update the following actions
to use Node.js 20: actions/checkout@v3. For more information see:
https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.
```
Try to have a faster classification, on first packet; use standard extra
dissection data path for sub-classification, metadata extraction and
monitoring.
STUN caches:
* use the proper confidence value
* lookup into the caches only once per flow, after having found a proper
STUN classification
Add identification of Telegram VoIP calls.
CI duration is quite long: the longest jobs is the "Performance" one.
Try to reduce the overall duration: that job (and some others) will not
be triggered for each PR/commit anymore, but asynchronously, once a day
(this scheduling seems right since the frequency of the PR/commits in
the project).
It should be possibly to trigger them manually, via GUI, anyway.
Remove two identical jobs; we already tests ASAN with 4 different
compilers.
After 9eff0754 it is safe to reduce fuzzing time.
Bottom line: try to have as upper-time of CI tests the duration of the
fuzzing jobs
Autodetecting the needed buffer size is quite complex (especially with
float/double values) so it is mandatory to properly check for
`ndpi_snprintf` truncation.
These issues have been undetected so far probably because the default
buffer is big enough for all common cases.
Add an example of usage of `ndpi_deserialize_clone_all()` (taken from
`ntopng`)
The goal of this fuzzer is to test init and deinit of the library, with
different configurations. In details:
* random memory allocation failures, even during init phase
* random `ndpi_init_prefs` parameter of `ndpi_init_detection_module()`
* random LRU caches sizes
* random bitmask of enabled protocols
* random parameters of `ndpi_set_detection_preferences()`
* random initialization of opportunistic TLS
* random load/don't load of configuration files
This new fuzzer is a C++ file, because it uses `FuzzedDataProvider`
class (see
https://github.com/google/fuzzing/blob/master/docs/split-inputs.md).
Note that the (existing) fuzzers need to be linked with C++ compiler
anyway, so this new fuzzer doesn't add any new requirements.
QUIC packets are encrypted/obfuscated; that means that we need to
decrypt them before parsing the real (TLS) message.
Fuzzing is not effective here, since a random buffer is hardly a valid
encrypted QUIC packet.
Add a new fuzzer, testing *decrypted* QUIC packets.
Add a basic corpus.
Fix a few bugs already found by this fuzzer.
