Basic Project Website Content

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 ...

  • Identifies the name of submitted and associated contact details
  • Identifies the group/person(s) responsible for providing a fix
  • Includes a description of the problem
  • Identifies classification of the problem (criticality, urgency, relevance etc.)
  • Identifies the status of the reported problem
  • Identifies the target release(s) in which the problem will be fixed
  • Identifies the expected closure date
  • Identifies any closure criteria
  • Identifies re-review actions

A Change Request ...

  • Identifies purpose of change
  • Identifies request status (e.g., open, allocated, implemented, closed)
  • Identifies requester contact information
  • Impacted system(s)
  • Impact to operations of existing system(s) defined
  • Impact to associated documentation defined
  • Criticality of the request, due date

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.

FLOSS License

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.

Documentation

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 src/*/*/docs/doxygen.

Other

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.

Public version-controlled source repository

Our projects use Git repositories hosted on Bitbucket.

Version numbering

Our projects use Semantic Version (SemVer) format (MAJOR.MINOR.PATCH).

Release Notes (ChangeLog)

Our projects use Keep a CHANGELOG format. The ChangeLog is in the file CHANGELOG.md.

Bug reporting process

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.

Vulnerability reporting process

Please report vulnerabilities to cert@tomilo.org 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.

Working build system

Except from the compiler under Windows, we solely use common FLOSS tools to build our software:

  • Build, test and package: CMake
  • Compiler: GCC

Automated test suite

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 src/*/*/tests.

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.

New functionality testing

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.

Warning flags

Our projects use maximally strict compiler warnings. This is done using pragmas in the file src/*/*/platform.h. For GCC these are -Wall -Wextra. 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.

Secure development knowledge

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.

Good cryptographic practices

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.

Secured delivery against man-in-the-middle (MITM) attacks

Our projects can be clones using Git via SSH or HTTPS. Downloads are available via HTTPS.

Git uses cryptographic tooling to enforce integrity.

Publicly-known vulnerabilities fixed

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.

Other security

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.

Static code analysis

Our projects use the following static code analysis tools integrated in the test suite:

  • Static code analysis of the compiler itself using strict compiler flags
  • Source code documentation warnings using Doxygen located in the directory src/*/*/docs/doxygen
  • Code complexity using CCCC located in the directory src/*/*/tests/cccc
  • Static code analysis using Cppcheck located in the directory src/*/*/tests/cppcheck

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.

Dynamic analysis

Our projects use the following dynamic analysis tools integrated in the test suite:

  • Performance tests (not mandatory) located in the directory src/*/*/tests/performance that upon execution generates CSV output
  • Unit tests using Boost.Test

We intend to fix all reports discovered with dynamic analysis in a timely way.

Future

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.