Dolibarr ERP CRM

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.

Each version has a tag and interim version for next release is available on branch "develop" that is public too. For maintenance version, interim code can be reach by using the name of the branch (for example branch 14.0 will contains interim version for version 14.0.5 if last release was 14.0.4)

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

See our policy for version naming: https://wiki.dolibarr.org/index.php?title=FAQ_Release_process

The tag is automatically added by our script that build the release (so no way to forget it). This script is embedded into the directory dev/build/ with the sources.

Non-trivial release notes file in repository: https://github.com/Dolibarr/dolibarr/blob/develop/ChangeLog. The release note is also generated by the script that build the release so no way to forget a change.

When we commit a fix, the title of fix (re-used into the changelog) mention the CVE that it fixes. Example with this PR: https://github.com/Dolibarr/dolibarr/pull/6830

Link with the bug tracker is provided on bottom of Home page https://www.dolibarr.org that points to this page: https://www.dolibarr.org/bugs-manager.php

The bug tracker is here: https://github.com/Dolibarr/dolibarr/issues

Currently only 20 PR open (recently) on 14 000+ PR submitted.

The PR and discussion around them are publicly available at https://github.com/Dolibarr/dolibarr/pulls

Link with process is provided on web site on the entry page for Developer documentation https://www.dolibarr.org/developer-documentation.php Link is link "Security information"

The chapter "Reporting a Vulnerability" into the file https://github.com/Dolibarr/dolibarr/blob/develop/SECURITY.md explain different way to report privately a vulnerability.

The project leader has a look on channel for security report every 5 open days or less.

The tool to build package is available with sources into https://github.com/Dolibarr/dolibarr/blob/develop/build/makepack-dolibarr.pl The README https://github.com/Dolibarr/dolibarr/blob/develop/build/README explain how to use it.

We are using our own script in Perl because we need to build package using different format / standard. But our command line tools then use the common tools for each target (rpm for redhat package, dpkg for Debian/ubuntu, tar for manual zip package, ...)

We are using our own script in Perl because we need to build package using different format / standard. But our command line tools then use the common tools for each target (rpm for redhat package, dpkg for Debian/ubuntu, tar for manual zip package, ...)

The test suite is available into directory test/phpunit. A readme is available to explain how to launch it locally.

Each PR is ran throw the CTI travis to execute unit test and result is a condition to merge the PR

New features are mostly build with a tool called "modulebuilder" embedded with application. This tool automatically generated the tests on it. So it is an automatic policy however, there is no document that describe this (so i will se "Unmet" for the point "It is SUGGESTED that this policy be documented"...

The tests are embedded with the sources of application and they are included into the same PR than the feature. No documentation exists to ask this way of working but it is the common way it works like this.

We are using a separate linter tool. This tool has be developed as a command line tool bu ourself so we can implement more powerful rules that generic tool for php (that we are using too). Profiles or config files for such tools are embedded with code into dev/xxx directory (where xxx is the tool)

We have set all "warning" as "errors" or have disabled the one we accept into the config files that are embedded with code into dev/xxx directory (where xxx is the tool)

We do not accept warning. If this is something we think we can, it has been disabled by setup, if we think it is a real warning, we have set warning as "errors" that block the release.

The core developers contains several developers (some of them were old hacker). See what we did for security here: https://wiki.dolibarr.org/index.php?title=Security_information#Features

Core developer are helped by a security companies (Yogosha) specialized in finding security bug to be trained on technic to fix such troubles.

All dependencies of project are FLOSS.

Implemented with v15+

Old hash functions were replaced with password-hash several years ago.

Using password-hash for password hash, so the salt is per password.

Delivery is done using git clone or packages of we are provided a signature file to check if a MITM was done. The signature file is both available with package but also online.

The signature file is available over https.

According to yogosha (the platform we used to fix security bugs), average delay to fix vulnerability is < 7 days.

Some tools are checking we don't leak such credential into public repositories.

We are using phpcs + phplint for static analysis tool

We have developed our own static analytics tool to look for common vulnerabilities (based on custom phpunit files)

We are using scrutinize

It is possible to enable a mode on a develop environment to make testing and fuzzing easier (for example, option $dolibarr_authentication_mode can be set to "forceuser" so it is easy to setup tools to login to application).