The contribution process in case you found an issue is to report it via the project's Issue Tracker. You can attach patches to your issues or send us pull requests.
We require you to sign a Contributor Agreement before your code can be integrated. This allows us to change to another Open Source License if it's more beneficial to the project. We intend to be compliant with the Automotive SPICE® process. In this process ...
A Problem Record ...
A Change Request ...
Our coding style and conventions follow common Open Source standards, such as Qt Coding Style, Qt Coding Conventions. Optional MISRA-C++ compliance available. Try to use the newest C++ standard as much as possible to reduce complexity, to enhance maintainability and performance, and to code safer. Source code has to be documented using Doxygen format.
We have a policy that anytime new functionality is added, tests of that functionality should be added to the automated test suite. For more details see below.
Our software libraries are provided under two licenses. With the GNU General Public License (GPL) you can review and test the software. Our commercial license is required as soon as you intend to use the software for commercial purposes.
Our projects contain a README.md file that is displayed on Bitbucket. In addition the generated source code documentation contains a main page that contains additional information.
A source code documented can be generated using Doxygen.
Consequently all source code is documented using the Doxygen format.
The configuration file (Doxyfile) is located in the directory
Our project sites (website, repository, and download URLs) are hosted on Bitbucket.
We don't have a dedicated forum for discussions. Instead we appreciate issue-related discussions taken place within the project's Issue Tracker.
We require English language throughout the project, including documentation, issues, and code comments.
Our projects use Semantic Version (SemVer) format (MAJOR.MINOR.PATCH).
Our projects use Keep a CHANGELOG format.
The ChangeLog is in the file
Our projects use the Issue Tracker provided by Bitbucket.
We intend to acknowledge bug reports within three days, however the response not always includes a fix.
We intend to respond to enhancement requests within a week, however complex issues may remain without respond.
Please report vulnerabilities to email@example.com and not via the Issue Tracker.
Email can be sent encrypted using the public key available at CAcert.
We intend to respond to any vulnerability report in less than or equal to 14 days.
Our projects come with an automated test suite integrated with CMake's test facility.
The tests performed are documented below in Static code analysis and Dynamic analysis.
In the repositories they are all located in the directory
We use a Jenkins server to automatically build, test and package our software on every checkin. The Jenkins master is provided by one of our developers. Public read access is granted. Multiple build slaves continuously integrate on Windows and Linux.
We have a general policy that as major new functionality is added, tests of that functionality are added to the test suite within the repository.
This policy on adding tests is also documented in the instructions for change proposals.
Our projects use maximally strict compiler warnings.
This is done using pragmas in the file
For GCC these are
The Windows compiler is overly strict, so we disabled some warnings such as 4251, 4351, and 4482.
Warnings from all tools (compiler, documentation generation) are measured and tracked as diagrams within Jenkins.
Our primary developer is Tobias Lorenz. He has over ten years experience of development in Open Source projects and in the Automotive Industry. Please consult him on how to design secure softare and how to prevent common errors that otherwise can lead to vulnerabilities in the software.
Our projects don't contain cryptographic algorithms except from those required by the particular specifications. These algorithms are not necessarily secure by design, but alternatives would break the compatibility. Special care has been taken that at least the implementation is secure and tested as much as possible.
Our projects can be clones using Git via SSH or HTTPS. Downloads are available via HTTPS.
Git uses cryptographic tooling to enforce integrity.
We intend to fix publicly-known vulnerabilities within 60 days. None of our projects statically link to libraries. So vulnerabilities within such libraries can be fixed on your own. If there are issues, then they are likely located in our environment such as our code generators (flex, bison) or template codes (Boost).
We intend to fix critical vulnerabilities rapidly after they are reported.
There are no private credentials located in public repositories. However to link infrastructure services there are some private credentials stores in Bitbucket's project settings. If such is known to be leaked they are replaced as soon as possible.
Our projects use the following static code analysis tools integrated in the test suite:
We intend to fix all reports discovered with static code analysis in a timely way.
Jenkins ensures build, test, and package happens on every commit.
Our projects use the following dynamic analysis tools integrated in the test suite:
src/*/*/tests/performancethat upon execution generates CSV output
We intend to fix all reports discovered with dynamic analysis in a timely way.
Jenkins resp. CMake regularly generates packages in all major formats. However these packages are generated on Debian Linux in the Testing Release, so dependencies can be different than expected in your Linux distribution.
Bitbucket is provided by Atlassian. There security team ensures that their servers are hardened. Vulnerabilities and Incidents can be reported to their security team.
GCC is uses with the hardening settings defined in Hardening in the Debian Wiki.