Security private reporting

(WIP) Security team and private reporting

How to Report a Vulnerability?

Please send a message to security [at] yoctoproject [dot] org, including as many details as possible: the layer or software module affected, the recipe and its version, and an example code, if available.

Branches maintained with security fixes

---

See Stable release and LTSfor detailed info regarding the policies and maintenance of Stable branch.

Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them.

How to Contact the Yocto Project regarding Security

We have set up two security-related mailing lists:

• Public List

yocto [dash] security [at] yoctoproject[dot] org

This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches and security-related initiatives. For more information, including subscription information, please see the yocto-security mailing list info page.

• Private List

security [at] yoctoproject [dot] org

This is a private mailing list for reporting non-published potential vulnerabilities. The list is monitored by the Yocto Project Security team.

What you should do if you find a security vulnerability

---

If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Project Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well. If you believe this is highly sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

What Yocto Security Team does when it receives a security vulnerability

---

The YP Security Team team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream project analyzes the problem. If they deem it a real security problem in their software, they develop and release a fix following their own security policy. They may want to include the original reporter in the loop. There is also sometimes some coordination for handling patches, backporting patches etc, or just understanding the problem or what caused it.

The security policy of the upstream project might include a notification to Linux distributions or other important downstream projects in advance to discuss coordinated disclosure. These mailing lists are normally non-public.

When the upstream project releases a version with the fix, they are responsible for contacting Mitre (cve.mitre.org) to get a CVE number assigned and the CVE record published.

If an upstream project does not respond quickly

---

If an upstream project does not fix the problem in a reasonable time, the Yocto's Security Team will contact other interested parties (usually other distributions) in the community and together try to solve the vulnerability as quickly as possible.

The Yocto Project Security team adheres to the 90 days disclosure policy by default. An increase of the embargo time is possible when necessary.

Security Team Appointment

The Yocto Project Security Team consists of at least three members. When new members are needed, the YP TSC asks for nominations by public channels, including also the limit date. Self-nominations are possible. When the limit time is reached, the YP TSC posts the list of candidates for the comments of project participants and developers. Comments may be sent publicly or privately to the YP and OE TSCs. The candidates are approved by both YP TSC and OE TSC and the final list of the team members is announced publicly.

YP Security Team members may resign at any time.

Current Security Team Members

For secure communications, please send your messages encrypted using the GPG keys. Remember message headers are not encrypted so do not include sensitive information in the subject line.

• Richard Purdie

• Michael Halstead <mhalstead [at] linuxfoundation [dot] org>

Public keys: Michael Halstead or Michael Halstead

• Ross Burton <ross@burtonini.com>

Public key