systemd

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

All development is public on github.

Repository on GitHub, which uses git. git is distributed.

Releases are cut from the master branch after testing and bugfixing. List of releases is at https://github.com/systemd/systemd/releases.

All releases are tagged in git and available under https://github.com/systemd/systemd/releases.

Non-trivial release notes file in repository: https://github.com/systemd/systemd/blob/master/NEWS.

See https://github.com/coreinfrastructure/best-practices-badge/commit/9003ba17bc7af2d494f3e30907f840274418e49c: users cannot update systemd themselves, because integration with the rest of the system is required. Distribution maintainers backport crucial patches without updating systemd.

Github backtracker is used for upstream bugs https://github.com/systemd/systemd/issues/. Various distributions (Fedora, Debian, Ubuntu, OpenSUSE) keep their bug lists but cooperate closely with upstream.

Github issues are used.

We fix most issues reported. As of late 2018, we have 980 issues open, out of the total of 3500 reported.

https://github.com/systemd/systemd/issues/

https://github.com/systemd/systemd/blob/master/.github/CONTRIBUTING.md#security-vulnerability-reports Instead of creating our own infrastructure, we ask reporters to report the bug to Fedora, Ubuntu or Debian, which have suitable mechanisms for non-public disclosure.

https://github.com/systemd/systemd/blob/master/.github/CONTRIBUTING.md#security-vulnerability-reports

All vulnerability reports were fixed with 48h.

meson & ninja are used for the build system. There's also a Makefile wrapper that implements the standard make all && make install interface.

meson & ninja.

We depend on many tools, but they are all open source: a compiler (gcc or clang), python, sed, awk, perl, meson, ninja, bash, and probably a bunch of others.

meson configuration includes 247 unit tests (mostly separate binaries). There are also larger integration tests in the source tree which use qemu and systemd-nspawn to boot a real system with the compiled systemd version.

ninja test invokes standard unit tests. https://mesonbuild.com/Unit-tests.html

There are 177 test binaries which do unit tests. There are also integration tests in tree. This certainly doesn't test all combinations, but most of the code is certainly tested in some way.

We have CI hooked up to github PRs on Github Actions, Semaphore, Ubuntu autopkgtests, and a custom setup to test Fedora rpms. Those tests are run on every PR and commit to the master branch. Example: https://github.com/systemd/systemd/actions

We strive to add tests to all new library functionality (in the form of unit tests). Integration testing for new features often requires a lot of work, so we attempt to add that, but features are routinely merged without it.

The informal policy is to add tests for new functionality, but without a hard requirement. Hence it is always satisfied.

We use many compiler warning flags, with select ones in -Werror mode. A way to run all units under valgrind is provided.

A build with -O0 is warning-free. Builds at higher optimization levels generate various warnings, most of them false positives. We try to silence as many of those warnings as possible, but prefer to have some warnings instead of ugly work-arounds in the code. We silence specific warnings with compiler pragmas where possible.

We turn on most compiler warnings, many of them in -Werror mode.

We rely on standard libraries to provide crypto (libgcrypt, gnutls, libcryptsetup, etc.) and standard security mechanisms. The only non-standard security mechanism is Forward Secure Sealing, which is described in peer-reviewed journal article.

We rely on standard libraries to provide crypto (libgcrypt, gnutls, libcryptsetup, etc.).

We don't configure key lengths and such directly, and instead rely on the libraries we use to provide good defaults (which they do).

We don't implement cryptographic algorithms ourselves, but instead rely on well-established libraries like gnutls and openssl.

The libraries which we use for crypto support that.

We don't store any passwords ourselves, we rely on standard nss mechanisms.

Release tarballs are available on github using https urls, and release tags are signed.

So far all vulnerabilities are fixed within 48h.

We use coverity and LGTM.

Coverity does that.

LGTM runs on all PRs. Coverity runs when it wants to.

We use valgrind, the tests are automatically run under it. We also build with address-sanitizer in CI and run tests with that.

We have fuzzers for various parts of the code and they run on oss-fuzz.

A quick grep shows 25000+ assertion statements.