LinuxTV

We use Git for all sub-projects.

We use Git for all sub-projects.

Development is continuous using git. Patches contain incremental changes.

We use Git for all sub-projects.

We use formal release versions.

Most of the trees we use use SemVer. Linux Kernel doesn't use, neither does XawTv, due to historical reasons.

We have tags for every release stored at the git repository.

Kernel community maintain release notes on separate sites, like lwn.net and kernel-newbies: https://kernelnewbies.org/LinuxVersions

On other sub-projects, we maintain a ChangeLog file summarizing the changes.

Kernel CVE are propely documented. For other sub-projects, we never got a CVE assignment.

Bugs are submitted via mailing list: linux-media@vger.kernel.org: http://vger.kernel.org/vger-lists.html#linux-media

For the Kernel, we use: https://bugzilla.kernel.org. Other sub-projects use GitHub; Kaffeine uses http://bugs.kde.org/.

We answer to bug reports via mailing list.

There are several mirrors for the mailing lists. The main one is at: https://lore.kernel.org/linux-media/ we also maintain logs for the IRC channel discussions.

The only vulnerabilities we ever got are related to the Kernel. There's a documented process about reporting security issues to the Linux Kernel: https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html

The only vulnerabilities we ever got are related to the Kernel. There's a documented process about reporting security issues to the Linux Kernel: https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html

Most of the time, we don't receive any vulnerability to the media subsystem. Last year, we got only one CVE and one private report at the beginning of 2018. Once we received the reports, they were promptly solved.

Kernel just uses standard Makefiles; other projects use cmake or autotools.

Kernel just uses standard Makefiles; other projects use cmake or autotools.

Everything is buildable with standard FLOSS tools like GNU c and glibc. No need to use proprietary build tools.

The Linux Kernel has several CI tools. One of them is at: https://kernelci.org/ We also have apps to check the compliance with hardware drivers with media APIs. We're in the process of adding CI for other sub-projects.

As most of the stuff is hardware-dependent, there's no way to implement unit tests. So, we designed a test suite to check if the Kernel drivers are properly implementing the media APIs. The main tool is v4l2-compliance. We also provide a set of other tools in order to test the hardware.

As most of the stuff is hardware-dependent, there's no way to implement unit tests. So, we designed a test suite to check if the Kernel drivers are properly implementing the media APIs. The main tool is v4l2-compliance. We also provide a set of other tools in order to test the hardware.

The Linux Kernel has several CI tools. One of them is at: https://kernelci.org/ We also have apps to check the compliance with hardware drivers with media APIs. We're in the process of adding CI for other sub-projects.

We follow Linux Kernel policies.

New drivers are required to pass at the compliance tools. The results of the tests should be submitted together with the patchsets adding the drivers.

We follow Linux Kernel policies.

We have low tolerance to warnings at the project. Besides compiler warnings, we also test the Kernel multimedia subsystem with Coverity, Sparse and Smatch static code analyzers.

Our goal is to have zero warnings when the media subsystem is built with W=1 (with enables lots of additional warnings over the usual Kernel standard).

We follow the Kernel policies. On distros, usually all warnings produce errors. At the Linux Kernel, this is an optional build feature.

The project main maintainer has CISSP certification (https://www.isc2.org/Certifications/CISSP).

The project main maintainer has CISSP certification (https://www.isc2.org/Certifications/CISSP).

We don't implement cryptography at the project. The website are https only.

We don't implement cryptography at the project.

We don't implement cryptography at the project. The DVB API supports access to DVB CI hardware modules (with are meant to implement cryptography), but the implementation is out of the scope of the project, as we just enable access to the hardware cryptographic functions.

We don't implement cryptography at the project.

We don't implement cryptography at the project.

We don't implement cryptography at the project.

We don't implement cryptography at the project.

Only Camorama sub-project may allow the user to optionally store passwords, but this is done via standard Glib authentication mechanism. Nothing is stored directly by it.

We don't implement cryptography at the project nor depend on random number generator.

Only camorama may use URLs to store camera images on a remote place. The mechanism supports https and scp.

We don't implement cryptography at the project. The website we use is https only.

There's no known unpatch vulnerabilities.

We speed up fixes for critical vulnerabilities.

We do our best efforts to keep private data confidential. We also have a privacy policy implemented: https://linuxtv.org/wiki/index.php/LinuxTVWiki:Privacy_policy

Coverity, sparse, smatch.

The tools we use check for common vulnerabilities.

Our goal is to have zero warnings from static code analyzers and compiler warnings (except for false-positive ones).

We run sparse and smatch for every single commit applied to the tree.

https://01.org/lkp/documentation/0-day-test-service runs lots of these tools on all trees before release.

We don't run directly any fuzzer, but there are a group of Kernel developers doing that and doing periodic reports to our channels.

Look at all of the wonderful BUG_ON() calls in the kernel (hint, you really don't want those to ever trigger, but they are there...) Outside the Kernel, errors are properly handled by the library and tools, reporting runtime errors or using assert() calls.

We actively monitor reports from Kernel fuzzer projects and address them.