Currently, when fuzzers are enabled, we run meson from within meson to build the fuzzer executables with sanitizers. The idea is that we can build the fuzzers with different kinds of sanitizers independently from the main build. The issue with this setup is that we don't actually make use of it. We only build the fuzzers with one set of sanitizers (address,undefined) so we're adding a bunch of extra complexity without any benefit as we can just setup the top level meson build with these sanitizers and get the same result. The other issue with this setup is that we don't pass on all the options passed to the top level meson build to the nested meson build. The only things we pass on are extra compiler arguments and the value of the auto_features option, but none of the individual feature options if overridden are passed on, which can lead to very hard to debug issues as an option enabled in the top level build is not enabled in the nested build. Since we're not getting anything useful out of this setup, let's simplify and get rid of the nested meson build. Instead, sanitizers should be enabled for the top level meson.build. This currently didn't work as we were overriding the sanitizers passed to the meson build with the fuzzer sanitizer, so we fix that as well by making sure we combine the fuzzer sanitizer with the ones passed in by the user. We also drop support for looking up libFuzzer as a separate library as it has been shipped builtin in clang since clang 6.0, so we can assume that -fsanitize=fuzzer is available. To make sure we still run the fuzzing tests, we enable the fuzz-tests option by default now to make sure they still always run (without instrumentation unless one of llvm-fuzz or oss-fuzz is enabled).
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS
