Yocto Project

We maintain stable release branches for a period of one year and provide upgrade paths to newer versions.

https://bugzilla.yoctoproject.org/

No vulnerabilities resolved in the last 12 months

https://wiki.yoctoproject.org/wiki/Security

https://www.openembedded.org/wiki/Styleguide

Our recipe metadata format is our own and our tools error/warn if they find issues in the metadata. We run testing at patch submission time through patchtest/patchwork and on our autobuilder infrastructure before merging changes.

As a cross compiling system we're acutely aware of handling compiler/linker flags correctly.

We allow the user to configure debug symbol handling

We have advanced dependency handling and handle parallelism correctly

We have reproducibility testing and can demonstrate we can generate bit-for-bit identical results for the same input configuration

We don't install/uninstall our software as we're primarily a build system. We do support package managers on our target images.

We make extensive use of DESTDIR

As a build system we offer the user the ability to make and test changes

Our documentation lists the requirements for common distributions we test/support http://docs.yoctoproject.org/brief-yoctoprojectqs/index.html

We regularly test on different distributions on our autobuilder infrastructure

We use standard system components

We have minimal dependencies and don't use obsolete components

We do pre commit testing on batches of patches pre-merge and that system produces extensive test reports

We are a build system building complete linux (and other OS) stacks so the breadth of our bug load makes this impractical. We can point out that we run around 2 million tests on any given autobuilder run including glibc and gcc test suites any one of which could trigger a bug report. We do have a policy of adding regression tests for the areas where bugs occur or could have significant impact.

We use our own file format and a mix of python and shell which makes this metric inapplicable.

https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

Where our autobuilder generates warnings, we flag and fix these so that our builds don't show them.

The project works to appropriate best practices for the tasks it undertakes such as checksumming its input source code and licenses and implementing reproducibility

Our default configurations use best known algorithms and update to match current best practises.

The project uses components which support multiple algorithms and we can switch components easily too.

We rely on the components we build and configure to do this but all of our default recipes follow this best practise.

We prefer secure versions of networking components

We support TLS 1.2

We use TLS certificate verification by default

We believe software we're including does do this

We sign the release tags in our repositories which are how we expect our users to primarily use the project

We use signed release tags

The project builds upstream source code but we checksum the code coming in, or verify it through version control systems so there is always a chain of checksums to verify the build system inputs.

The project is a configurable build system and users can chose to include many different levels of hardening. By default we include compiler options, this can range through to selinux and other software from the meta-security layer http://git.yoctoproject.org/cgit.cgi/meta-security

As a configurable OS build tool this is tricky but the project is world leading used by many different companies in different environments and we encourage collaboration on any issues encountered and sharing and collaborating around best practises. We have processes for managing and verifying build reproducibility, building and running security and audit tools and regularly run CVE scans for components with known issues amongst other things. As such, common security weaknesses would be identified, raised with is and rectified. https://wiki.yoctoproject.org/wiki/Security https://wiki.yoctoproject.org/wiki/Reproducible_Builds

We use pylint since our codebase is python based

As a build system we do not fuzz the upstream software we build, we consider that the job of the upstream developers and it would be impractical to do this for a whole Linux stack. Our main build tools and code base is primarily python based so its not memory-unsafe.