netdata

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 interim versions are maintained in the same public github repo.

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

The release process is automated and uses semantic versioning. For rolling releases we use github commit IDs.

Yes, this is automated. Each release is tagged at the master branch.

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

Yes, we include them in the release notes.

We use github issues: https://github.com/netdata/netdata/issues?q=is%3Aissue+is%3Aopen+label%3Abug

We use github issues: https://github.com/netdata/netdata/issues

We apply github issue labels (bug) to github issues: https://github.com/netdata/netdata/issues?q=is%3Aissue+is%3Aopen+label%3Abug

We reply to all requests within a few days.

We use github issues: https://github.com/netdata/netdata/issues

https://github.com/netdata/netdata/security/policy

https://github.com/netdata/netdata/security/policy#reporting-a-vulnerability contains a link to post a vulnerability report at https://groups.google.com/a/netdata.cloud/forum/#!newtopic/security. The posts are not public.

All vulnerability reports we have received so far, have been addressed within a 1-2 days.

We use git submodules with automake and autoconf to build Netdata.

We use git submodules with automake and autoconf to build Netdata, using the standard build environment available in Linux systems.

We use git submodules with automake and autoconf to build Netdata, using the standard build environment available in Linux systems.

The netdata daemon has embedded unit and stress testing for its core components: database, query engine, dictionaries, array allocator, buffer, strings, etc. All these are integrated to our CI/CD and are executed as part of every PR.

The binary netdata produced by compiling the code, can run its unit tests by itself. It is a command line parameter. Details available at https://github.com/netdata/netdata/blob/master/tests/run-unit-tests.sh

The Netdata library upon which we build Netdata has extensive unit tests for all its critical components, covering almost 100% of the code branches on them. This includes dictionaries, strings, array allocator, buffer, etc. Also the critical parts of the Netdata daemon, such as the database and the query engine also have extensive unit-tests to ensure these components work as expected. In many cases where multi-threaded functionality is critical, multi-threaded stress tests are also included in the test suite. However the use of all these components in other parts of the code, is not automatically tested.

However, the use all these components is usually not unit-tested and we rely on manual testing them.

We run the implemented unit tests automatically via Github actions, visible at https://github.com/netdata/netdata/actions

The core components of the Netdata daemon always come with unit and stress tests to ensure they operate properly under all conditions. These core components are robust, we require fully automated testing on them, including stress testing and provide the foundation upon which Netdata is built. However, for data collection plugins or other supporting components we rely mainly on manual testing to merge them into Netdata.

All included automated unit and stress tests are part of the normal PR flow, integrated to Netdata's CI/CD. Our release-notes are semi-automated, meaning that the items to mention are automatically generated and then we re-format, re-group and present them in more human friendly way in the release notes. Usually, all code changes are mentioned in our release notes.

Under development we always compile with (for gcc):

CFLAGS="-O1 -ggdb -Wall -Wextra -Wformat-signedness -fstack-protector-all -DNETDATA_INTERNAL_CHECKS=1 -D_FORTIFY_SOURCE=2"

Compiling the code does not produce any warning on most major compiler versions. Keep in mind that Netdata includes third party libraries that may produce some compiler warnings, which we are unable to fix ourselves (they have to be addressed upstream).

Under development we always compile with (for gcc):

CFLAGS="-O1 -ggdb -Wall -Wextra -Wformat-signedness -fstack-protector-all -DNETDATA_INTERNAL_CHECKS=1 -D_FORTIFY_SOURCE=2"

The founder of Netdata, Costa Tsaousis, is the lead engineer for the security architecture of Netdata.

Netdata already has the following characteristics: - economy of mechanism (the design is simple and small as practical) - we use Linux file system permissions standards for all Netdata directories - complete mediation (every access that might be limited is checked for authority and is non-bypassable) - open design (security mechanisms does not depend on attacker ignorance of the design, but instead on more easily protected and changed information like keys) - separation of privilege (netdata components that require escalated privileges are totally isolated) - least privilege (netdata components run with the least possible privileges) - least common mechanism - psychological acceptability (the human interface must be designed for ease of use) - limited attack surface - input validation with allowlists

More can be found here: https://learn.netdata.cloud/docs/deployment-in-production/security-and-privacy-design

We have 2+ developers having this understanding.

We use OpenSSL and when we use it, the publicly accepted production-grade defaults are used.

We use OpenSSL.

We rely on modern versions of OpenSSL.

We don't have any known vulnerabilities unpatched.

We fix all vulnerabilities immediately (1-2 days) after they are identified.

We use several tools and online services:

FOSS tools:

• shellcheck
• pylint
• csslint
• jslint
• cppcheck

Online Services:

• Gihub's CodeQL
• Codacy at https://app.codacy.com/project/netdata/netdata/dashboard
• Coverity Scan at https://scan.coverity.com/projects/netdata-netdata

Several of the tools and static code analysis tools we use perform security analysis.

For example:

• Gihub's CodeQL
• Codacy has a security audit: https://app.codacy.com/app/netdata/netdata/security
• Coverity Scan at https://scan.coverity.com/projects/netdata-netdata

All security issues identified are fixed usually within 1-2 days.

Everything is automated via github. The only exception is Coverity Scan, which runs nightly and on demand and prior to each release.

We regularly use valgrind and we enforce its use before a release.

The programs runs controlled assertions to exit cleanly on such errors, in the form of a fatal() call.

All security issues identified are fixed usually within 1-2 days.