LinuxTV

We maintain a ports tree that allows usind new drivers with older Kernels.

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

We use Reported-by: tags to indicate contributions. Those are stored at the git trees: https://git.linuxtv.org/

https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html

https://linuxtv.org/wiki/index.php/Development:_Coding_Style

scripts/checkpatch.pl checks and enforces coding style rules.

All build environment variables are properly handled.

For the Kernel, configuration options allow for all debugging symbols to be retained in the built objects. For userspace apps/libraries, the building system honours LDFLAGS.

No recursion in the build system when there are cross-dependencies in the subdirectories.

The project meets the reproducible build requirements.

Many third parties provide packages (e.g., .deb for apt-get, .rpm). We also store compressed tarballs at https://linuxtv.org/downloads for the source code userspace components. The install steps are described at the top level directory at README and INSTALL files (or README.md/INSTALL.md).

It uses standard tools that honors things like DESTDIR.

At Kernel, all distros usually have a 'kernel-developer' meta-package option to automatically install needed dependancies to build the project. On userspace, "make install" install all compiled components.

This applies only for userspace. We don't maintain a per-distribution parseable list of components upstream, as this is distro-dependent, but this is easily obtained within the distributions.

The kernel has no external dependencies. No media apps require priviledged (root) access.

All efforts are made to avoid non-standard components.

All efforts are made to keep the projects updated to the latest versions of the libraries it uses.

It is not possible to automate tests for hardware-dependent components. We're adding automation to the media core function by using virtual drivers that emulate a real hardware. For the Linux Kernel, the 0-day bot runs on each commit in almost all maintainers trees before they are merged into Linus's tree.

It is impossible to create automated regression tests for even a small percentage of the bugs found in the kernel. It is even harder for parts that depend having an specific hardware. Yet, people are actively working on this, and we do have a very large test suite that includes checks for almost all major CVEs that can be tested for.

Code coverage is a horrible metric, specially for hardware-dependent software components. See above for the discussion about our automated regression tests.

Not all new features are able to have automated tests added for them. Yet, there are compliance tools and it is a requirement that developers should run them before submitting new drivers.

We follow Linux Kernel policies.

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

The kernel and userspace tools implement "known secure design" principles.

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.

We don't implement cryptography at the project.

We don't implement cryptography at the project.

We don't implement cryptography at the project.

For the Linux Kernel, all tags for kernel releases are properly signed. We also sign tags on userspace tools. For all download source code, we maintain sha1sum and sha512sum.

For the Linux Kernel, all tags for kernel releases are properly signed. We also sign tags on userspace tools

Only valid users can push things at the git trees, using cryptographic keys.

The Linux kernel self protection project develops hardening improvements for the Linux kernel; many of them have already been accepted into the Linux kernel mainline: http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project There are a number of hardening mechanisms in the Linux kernel, such as Linux kernel stack protection. For userspace tools, that doesn't apply, as priviledged permission is not required.

We have it only for the Linux Kernel. The kernel's security requirements are constantly tested and probed by everyone in the world. When problems are found, they are resolved as quickly as possible as described in our security bugs reporting documentation: https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html

The tools we use check for common vulnerabilities.

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