diff options
| -rw-r--r-- | documentation/dev-manual/index.rst | 1 | ||||
| -rw-r--r-- | documentation/dev-manual/security-subjects.rst | 194 | ||||
| -rw-r--r-- | documentation/index.rst | 7 | ||||
| -rw-r--r-- | documentation/migration-guides/release-notes-4.3.rst | 2 | ||||
| -rw-r--r-- | documentation/security-reference/index.rst | 14 | ||||
| -rw-r--r-- | documentation/security-reference/reporting-vulnerabilities.rst | 85 | ||||
| -rw-r--r-- | documentation/security-reference/security-team.rst | 110 |
7 files changed, 216 insertions, 197 deletions
diff --git a/documentation/dev-manual/index.rst b/documentation/dev-manual/index.rst index 8243c0f4cb..612fba55e4 100644 --- a/documentation/dev-manual/index.rst +++ b/documentation/dev-manual/index.rst | |||
| @@ -41,7 +41,6 @@ Yocto Project Development Tasks Manual | |||
| 41 | build-quality | 41 | build-quality |
| 42 | debugging | 42 | debugging |
| 43 | licenses | 43 | licenses |
| 44 | security-subjects | ||
| 45 | vulnerabilities | 44 | vulnerabilities |
| 46 | sbom | 45 | sbom |
| 47 | error-reporting-tool | 46 | error-reporting-tool |
diff --git a/documentation/dev-manual/security-subjects.rst b/documentation/dev-manual/security-subjects.rst deleted file mode 100644 index 1ec7c8b385..0000000000 --- a/documentation/dev-manual/security-subjects.rst +++ /dev/null | |||
| @@ -1,194 +0,0 @@ | |||
| 1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK | ||
| 2 | |||
| 3 | Dealing with Vulnerability Reports | ||
| 4 | ********************************** | ||
| 5 | |||
| 6 | The Yocto Project and OpenEmbedded are open-source, community-based projects | ||
| 7 | used in numerous products. They assemble multiple other open-source projects, | ||
| 8 | and need to handle security issues and practices both internal (in the code | ||
| 9 | maintained by both projects), and external (maintained by other projects and | ||
| 10 | organizations). | ||
| 11 | |||
| 12 | This manual assembles security-related information concerning the whole | ||
| 13 | ecosystem. It includes information on reporting a potential security issue, | ||
| 14 | the operation of the YP Security team and how to contribute in the | ||
| 15 | related code. It is written to be useful for both security researchers and | ||
| 16 | YP developers. | ||
| 17 | |||
| 18 | How to report a potential security vulnerability? | ||
| 19 | ================================================= | ||
| 20 | |||
| 21 | If you would like to report a public issue (for example, one with a released | ||
| 22 | CVE number), please report it using the | ||
| 23 | :yocto_bugs:`Security Bugzilla </enter_bug.cgi?product=Security>`. | ||
| 24 | |||
| 25 | If you are dealing with a not-yet-released issue, or an urgent one, please send | ||
| 26 | a message to security AT yoctoproject DOT org, including as many details as | ||
| 27 | possible: the layer or software module affected, the recipe and its version, | ||
| 28 | and any example code, if available. This mailing list is monitored by the | ||
| 29 | Yocto Project Security team. | ||
| 30 | |||
| 31 | For each layer, you might also look for specific instructions (if any) for | ||
| 32 | reporting potential security issues in the specific ``SECURITY.md`` file at the | ||
| 33 | root of the repository. Instructions on how and where submit a patch are | ||
| 34 | usually available in ``README.md``. If this is your first patch to the | ||
| 35 | Yocto Project/OpenEmbedded, you might want to have a look into the | ||
| 36 | Contributor's Manual section | ||
| 37 | ":ref:`contributor-guide/submit-changes:preparing changes for submission`". | ||
| 38 | |||
| 39 | Branches maintained with security fixes | ||
| 40 | --------------------------------------- | ||
| 41 | |||
| 42 | See the | ||
| 43 | :ref:`Release process <ref-manual/release-process:Stable Release Process>` | ||
| 44 | documentation for details regarding the policies and maintenance of stable | ||
| 45 | branches. | ||
| 46 | |||
| 47 | The :yocto_home:`Releases </development/releases/>` page contains a list of all | ||
| 48 | releases of the Yocto Project, grouped into current and previous releases. | ||
| 49 | Previous releases are no longer actively maintained with security patches, but | ||
| 50 | well-tested patches may still be accepted for them for significant issues. | ||
| 51 | |||
| 52 | Security-related discussions at the Yocto Project | ||
| 53 | ------------------------------------------------- | ||
| 54 | |||
| 55 | We have set up two security-related emails/mailing lists: | ||
| 56 | |||
| 57 | - Public Mailing List: yocto [dash] security [at] yoctoproject[dot] org | ||
| 58 | |||
| 59 | This is a public mailing list for anyone to subscribe to. This list is an | ||
| 60 | open list to discuss public security issues/patches and security-related | ||
| 61 | initiatives. For more information, including subscription information, | ||
| 62 | please see the :yocto_lists:`yocto-security mailing list info page | ||
| 63 | </g/yocto-security>`. | ||
| 64 | |||
| 65 | This list requires moderator approval for new topics to be posted, to avoid | ||
| 66 | private security reports to be posted by mistake. | ||
| 67 | |||
| 68 | - Yocto Project Security Team: security [at] yoctoproject [dot] org | ||
| 69 | |||
| 70 | This is an email for reporting non-published potential vulnerabilities. | ||
| 71 | Emails sent to this address are forwarded to the Yocto Project Security | ||
| 72 | Team members. | ||
| 73 | |||
| 74 | |||
| 75 | What you should do if you find a security vulnerability | ||
| 76 | ------------------------------------------------------- | ||
| 77 | |||
| 78 | If you find a security flaw: a crash, an information leakage, or anything that | ||
| 79 | can have a security impact if exploited in any Open Source software built or | ||
| 80 | used by the Yocto Project, please report this to the Yocto Project Security | ||
| 81 | Team. If you prefer to contact the upstream project directly, please send a | ||
| 82 | copy to the security team at the Yocto Project as well. If you believe this is | ||
| 83 | highly sensitive information, please report the vulnerability in a secure way, | ||
| 84 | i.e. encrypt the email and send it to the private list. This ensures that | ||
| 85 | the exploit is not leaked and exploited before a response/fix has been generated. | ||
| 86 | |||
| 87 | Security team | ||
| 88 | ============= | ||
| 89 | |||
| 90 | The Yocto Project/OpenEmbedded security team coordinates the work on security | ||
| 91 | subjects in the project. All general discussion takes place publicly. The | ||
| 92 | Security Team only uses confidential communication tools to deal with private | ||
| 93 | vulnerability reports before they are released. | ||
| 94 | |||
| 95 | Security team appointment | ||
| 96 | ------------------------- | ||
| 97 | |||
| 98 | The Yocto Project Security Team consists of at least three members. When new | ||
| 99 | members are needed, the Yocto Project Technical Steering Committee (YP TSC) | ||
| 100 | asks for nominations by public channels including a nomination deadline. | ||
| 101 | Self-nominations are possible. When the limit time is | ||
| 102 | reached, the YP TSC posts the list of candidates for the comments of project | ||
| 103 | participants and developers. Comments may be sent publicly or privately to the | ||
| 104 | YP and OE TSCs. The candidates are approved by both YP TSC and OpenEmbedded | ||
| 105 | Technical Steering Committee (OE TSC) and the final list of the team members | ||
| 106 | is announced publicly. The aim is to have people representing technical | ||
| 107 | leadership, security knowledge and infrastructure present with enough people | ||
| 108 | to provide backup/coverage but keep the notification list small enough to | ||
| 109 | minimize information risk and maintain trust. | ||
| 110 | |||
| 111 | YP Security Team members may resign at any time. | ||
| 112 | |||
| 113 | Security Team Operations | ||
| 114 | ------------------------ | ||
| 115 | |||
| 116 | The work of the Security Team might require high confidentiality. Team members | ||
| 117 | are individuals selected by merit and do not represent the companies they work | ||
| 118 | for. They do not share information about confidential issues outside of the team | ||
| 119 | and do not hint about ongoing embargoes. | ||
| 120 | |||
| 121 | Team members can bring in domain experts as needed. Those people should be | ||
| 122 | added to individual issues only and adhere to the same standards as the YP | ||
| 123 | Security Team. | ||
| 124 | |||
| 125 | The YP security team organizes its meetings and communication as needed. | ||
| 126 | |||
| 127 | When the YP Security team receives a report about a potential security | ||
| 128 | vulnerability, they quickly analyze and notify the reporter of the result. | ||
| 129 | They might also request more information. | ||
| 130 | |||
| 131 | If the issue is confirmed and affects the code maintained by the YP, they | ||
| 132 | confidentially notify maintainers of that code and work with them to prepare | ||
| 133 | a fix. | ||
| 134 | |||
| 135 | If the issue is confirmed and affects an upstream project, the YP security team | ||
| 136 | notifies the project. Usually, the upstream project analyzes the problem again. | ||
| 137 | If they deem it a real security problem in their software, they develop and | ||
| 138 | release a fix following their security policy. They may want to include the | ||
| 139 | original reporter in the loop. There is also sometimes some coordination for | ||
| 140 | handling patches, backporting patches etc, or just understanding the problem | ||
| 141 | or what caused it. | ||
| 142 | |||
| 143 | When the fix is publicly available, the YP security team member or the | ||
| 144 | package maintainer sends patches against the YP code base, following usual | ||
| 145 | procedures, including public code review. | ||
| 146 | |||
| 147 | What Yocto Security Team does when it receives a security vulnerability | ||
| 148 | ----------------------------------------------------------------------- | ||
| 149 | |||
| 150 | The YP Security Team team performs a quick analysis and would usually report | ||
| 151 | the flaw to the upstream project. Normally the upstream project analyzes the | ||
| 152 | problem. If they deem it a real security problem in their software, they | ||
| 153 | develop and release a fix following their own security policy. They may want | ||
| 154 | to include the original reporter in the loop. There is also sometimes some | ||
| 155 | coordination for handling patches, backporting patches etc, or just | ||
| 156 | understanding the problem or what caused it. | ||
| 157 | |||
| 158 | The security policy of the upstream project might include a notification to | ||
| 159 | Linux distributions or other important downstream projects in advance to | ||
| 160 | discuss coordinated disclosure. These mailing lists are normally non-public. | ||
| 161 | |||
| 162 | When the upstream project releases a version with the fix, they are responsible | ||
| 163 | for contacting `Mitre <https://www.cve.org/>`__ to get a CVE number assigned and | ||
| 164 | the CVE record published. | ||
| 165 | |||
| 166 | If an upstream project does not respond quickly | ||
| 167 | ----------------------------------------------- | ||
| 168 | |||
| 169 | If an upstream project does not fix the problem in a reasonable time, | ||
| 170 | the Yocto's Security Team will contact other interested parties (usually | ||
| 171 | other distributions) in the community and together try to solve the | ||
| 172 | vulnerability as quickly as possible. | ||
| 173 | |||
| 174 | The Yocto Project Security team adheres to the 90 days disclosure policy | ||
| 175 | by default. An increase of the embargo time is possible when necessary. | ||
| 176 | |||
| 177 | Current Security Team members | ||
| 178 | ----------------------------- | ||
| 179 | |||
| 180 | For secure communications, please send your messages encrypted using the GPG | ||
| 181 | keys. Remember, message headers are not encrypted so do not include sensitive | ||
| 182 | information in the subject line. | ||
| 183 | |||
| 184 | - Ross Burton: <ross@burtonini.com> `Public key <https://keys.openpgp.org/search?q=ross%40burtonini.com>`__ | ||
| 185 | |||
| 186 | - Michael Halstead: <mhalstead [at] linuxfoundation [dot] org> | ||
| 187 | `Public key <https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969>`__ | ||
| 188 | or `Public key <https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xd1f2407285e571ed12a407a73373170601861969>`__ | ||
| 189 | |||
| 190 | - Richard Purdie: <richard.purdie@linuxfoundation.org> `Public key <https://keys.openpgp.org/search?q=richard.purdie%40linuxfoundation.org>`__ | ||
| 191 | |||
| 192 | - Marta Rybczynska: <marta DOT rybczynska [at] syslinbit [dot] com> `Public key <https://keys.openpgp.org/search?q=marta.rybczynska@syslinbit.com>`__ | ||
| 193 | |||
| 194 | - Steve Sakoman: <steve [at] sakoman [dot] com> `Public key <https://keys.openpgp.org/search?q=steve%40sakoman.com>`__ | ||
diff --git a/documentation/index.rst b/documentation/index.rst index 6c6be38a7e..037edcee61 100644 --- a/documentation/index.rst +++ b/documentation/index.rst | |||
| @@ -20,7 +20,6 @@ Welcome to the Yocto Project Documentation | |||
| 20 | Yocto Project Software Overview <https://www.yoctoproject.org/software-overview/> | 20 | Yocto Project Software Overview <https://www.yoctoproject.org/software-overview/> |
| 21 | Tips and Tricks Wiki <https://wiki.yoctoproject.org/wiki/TipsAndTricks> | 21 | Tips and Tricks Wiki <https://wiki.yoctoproject.org/wiki/TipsAndTricks> |
| 22 | 22 | ||
| 23 | |||
| 24 | .. toctree:: | 23 | .. toctree:: |
| 25 | :maxdepth: 1 | 24 | :maxdepth: 1 |
| 26 | :caption: Manuals | 25 | :caption: Manuals |
| @@ -39,6 +38,12 @@ Welcome to the Yocto Project Documentation | |||
| 39 | 38 | ||
| 40 | .. toctree:: | 39 | .. toctree:: |
| 41 | :maxdepth: 1 | 40 | :maxdepth: 1 |
| 41 | :caption: Security | ||
| 42 | |||
| 43 | Yocto Project Security Reference <security-reference/index> | ||
| 44 | |||
| 45 | .. toctree:: | ||
| 46 | :maxdepth: 1 | ||
| 42 | :caption: Release Manuals | 47 | :caption: Release Manuals |
| 43 | :hidden: | 48 | :hidden: |
| 44 | 49 | ||
diff --git a/documentation/migration-guides/release-notes-4.3.rst b/documentation/migration-guides/release-notes-4.3.rst index 0103ac985e..797e1cf74b 100644 --- a/documentation/migration-guides/release-notes-4.3.rst +++ b/documentation/migration-guides/release-notes-4.3.rst | |||
| @@ -274,7 +274,7 @@ New Features / Enhancements in 4.3 | |||
| 274 | 274 | ||
| 275 | - New :doc:`../contributor-guide/index` document. | 275 | - New :doc:`../contributor-guide/index` document. |
| 276 | 276 | ||
| 277 | - New :doc:`../dev-manual/security-subjects` chapter in the Development | 277 | - New "Dealing with Vulnerability Reports" chapter in the Development |
| 278 | Tasks Manual. | 278 | Tasks Manual. |
| 279 | 279 | ||
| 280 | - Long overdue documentation for the :ref:`ref-classes-devicetree` class. | 280 | - Long overdue documentation for the :ref:`ref-classes-devicetree` class. |
diff --git a/documentation/security-reference/index.rst b/documentation/security-reference/index.rst new file mode 100644 index 0000000000..c20a54d1a9 --- /dev/null +++ b/documentation/security-reference/index.rst | |||
| @@ -0,0 +1,14 @@ | |||
| 1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK | ||
| 2 | |||
| 3 | ================================ | ||
| 4 | Yocto Project Security Reference | ||
| 5 | ================================ | ||
| 6 | |||
| 7 | .. toctree:: | ||
| 8 | :caption: Table of Contents | ||
| 9 | :numbered: | ||
| 10 | |||
| 11 | security-team | ||
| 12 | reporting-vulnerabilities | ||
| 13 | |||
| 14 | .. include:: /boilerplate.rst | ||
diff --git a/documentation/security-reference/reporting-vulnerabilities.rst b/documentation/security-reference/reporting-vulnerabilities.rst new file mode 100644 index 0000000000..0c457278d5 --- /dev/null +++ b/documentation/security-reference/reporting-vulnerabilities.rst | |||
| @@ -0,0 +1,85 @@ | |||
| 1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK | ||
| 2 | |||
| 3 | Reporting Vulnerabilities | ||
| 4 | ************************* | ||
| 5 | |||
| 6 | The Yocto Project and OpenEmbedded are open-source, community-based projects | ||
| 7 | used in numerous products. They assemble multiple other open-source projects, | ||
| 8 | and need to handle security issues and practices both internal (in the code | ||
| 9 | maintained by both projects), and external (maintained by other projects and | ||
| 10 | organizations). | ||
| 11 | |||
| 12 | This manual assembles security-related information concerning the whole | ||
| 13 | ecosystem. It includes information on reporting a potential security issue, | ||
| 14 | the operation of the YP Security team and how to contribute in the | ||
| 15 | related code. It is written to be useful for both security researchers and | ||
| 16 | YP developers. | ||
| 17 | |||
| 18 | How to report a potential security vulnerability? | ||
| 19 | ================================================= | ||
| 20 | |||
| 21 | If you would like to report a public issue (for example, one with a released | ||
| 22 | CVE number), please report it using the | ||
| 23 | :yocto_bugs:`Security Bugzilla </enter_bug.cgi?product=Security>`. | ||
| 24 | |||
| 25 | If you are dealing with a not-yet-released issue, or an urgent one, please send | ||
| 26 | a message to security AT yoctoproject DOT org, including as many details as | ||
| 27 | possible: the layer or software module affected, the recipe and its version, | ||
| 28 | and any example code, if available. This mailing list is monitored by the | ||
| 29 | Yocto Project Security team. | ||
| 30 | |||
| 31 | For each layer, you might also look for specific instructions (if any) for | ||
| 32 | reporting potential security issues in the specific ``SECURITY.md`` file at the | ||
| 33 | root of the repository. Instructions on how and where submit a patch are | ||
| 34 | usually available in ``README.md``. If this is your first patch to the | ||
| 35 | Yocto Project/OpenEmbedded, you might want to have a look into the | ||
| 36 | Contributor's Manual section | ||
| 37 | ":ref:`contributor-guide/submit-changes:preparing changes for submission`". | ||
| 38 | |||
| 39 | Branches maintained with security fixes | ||
| 40 | --------------------------------------- | ||
| 41 | |||
| 42 | See the | ||
| 43 | :ref:`Release process <ref-manual/release-process:Stable Release Process>` | ||
| 44 | documentation for details regarding the policies and maintenance of stable | ||
| 45 | branches. | ||
| 46 | |||
| 47 | The :yocto_home:`Releases </development/releases/>` page contains a list of all | ||
| 48 | releases of the Yocto Project, grouped into current and previous releases. | ||
| 49 | Previous releases are no longer actively maintained with security patches, but | ||
| 50 | well-tested patches may still be accepted for them for significant issues. | ||
| 51 | |||
| 52 | Security-related discussions at the Yocto Project | ||
| 53 | ------------------------------------------------- | ||
| 54 | |||
| 55 | We have set up two security-related emails/mailing lists: | ||
| 56 | |||
| 57 | - Public Mailing List: yocto [dash] security [at] yoctoproject[dot] org | ||
| 58 | |||
| 59 | This is a public mailing list for anyone to subscribe to. This list is an | ||
| 60 | open list to discuss public security issues/patches and security-related | ||
| 61 | initiatives. For more information, including subscription information, | ||
| 62 | please see the :yocto_lists:`yocto-security mailing list info page | ||
| 63 | </g/yocto-security>`. | ||
| 64 | |||
| 65 | This list requires moderator approval for new topics to be posted, to avoid | ||
| 66 | private security reports to be posted by mistake. | ||
| 67 | |||
| 68 | - Yocto Project Security Team: security [at] yoctoproject [dot] org | ||
| 69 | |||
| 70 | This is an email for reporting non-published potential vulnerabilities. | ||
| 71 | Emails sent to this address are forwarded to the Yocto Project Security | ||
| 72 | Team members. | ||
| 73 | |||
| 74 | |||
| 75 | What you should do if you find a security vulnerability | ||
| 76 | ------------------------------------------------------- | ||
| 77 | |||
| 78 | If you find a security flaw: a crash, an information leakage, or anything that | ||
| 79 | can have a security impact if exploited in any Open Source software built or | ||
| 80 | used by the Yocto Project, please report this to the Yocto Project Security | ||
| 81 | Team. If you prefer to contact the upstream project directly, please send a | ||
| 82 | copy to the security team at the Yocto Project as well. If you believe this is | ||
| 83 | highly sensitive information, please report the vulnerability in a secure way, | ||
| 84 | i.e. encrypt the email and send it to the private list. This ensures that | ||
| 85 | the exploit is not leaked and exploited before a response/fix has been generated. | ||
diff --git a/documentation/security-reference/security-team.rst b/documentation/security-reference/security-team.rst new file mode 100644 index 0000000000..b773653822 --- /dev/null +++ b/documentation/security-reference/security-team.rst | |||
| @@ -0,0 +1,110 @@ | |||
| 1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK | ||
| 2 | |||
| 3 | Security team | ||
| 4 | ************* | ||
| 5 | |||
| 6 | The Yocto Project/OpenEmbedded security team coordinates the work on security | ||
| 7 | subjects in the project. All general discussion takes place publicly. The | ||
| 8 | Security Team only uses confidential communication tools to deal with private | ||
| 9 | vulnerability reports before they are released. | ||
| 10 | |||
| 11 | Security team appointment | ||
| 12 | ========================= | ||
| 13 | |||
| 14 | The Yocto Project Security Team consists of at least three members. When new | ||
| 15 | members are needed, the Yocto Project Technical Steering Committee (YP TSC) | ||
| 16 | asks for nominations by public channels including a nomination deadline. | ||
| 17 | Self-nominations are possible. When the limit time is | ||
| 18 | reached, the YP TSC posts the list of candidates for the comments of project | ||
| 19 | participants and developers. Comments may be sent publicly or privately to the | ||
| 20 | YP and OE TSCs. The candidates are approved by both YP TSC and OpenEmbedded | ||
| 21 | Technical Steering Committee (OE TSC) and the final list of the team members | ||
| 22 | is announced publicly. The aim is to have people representing technical | ||
| 23 | leadership, security knowledge and infrastructure present with enough people | ||
| 24 | to provide backup/coverage but keep the notification list small enough to | ||
| 25 | minimize information risk and maintain trust. | ||
| 26 | |||
| 27 | YP Security Team members may resign at any time. | ||
| 28 | |||
| 29 | Security Team Operations | ||
| 30 | ======================== | ||
| 31 | |||
| 32 | The work of the Security Team might require high confidentiality. Team members | ||
| 33 | are individuals selected by merit and do not represent the companies they work | ||
| 34 | for. They do not share information about confidential issues outside of the team | ||
| 35 | and do not hint about ongoing embargoes. | ||
| 36 | |||
| 37 | Team members can bring in domain experts as needed. Those people should be | ||
| 38 | added to individual issues only and adhere to the same standards as the YP | ||
| 39 | Security Team. | ||
| 40 | |||
| 41 | The YP security team organizes its meetings and communication as needed. | ||
| 42 | |||
| 43 | When the YP Security team receives a report about a potential security | ||
| 44 | vulnerability, they quickly analyze and notify the reporter of the result. | ||
| 45 | They might also request more information. | ||
| 46 | |||
| 47 | If the issue is confirmed and affects the code maintained by the YP, they | ||
| 48 | confidentially notify maintainers of that code and work with them to prepare | ||
| 49 | a fix. | ||
| 50 | |||
| 51 | If the issue is confirmed and affects an upstream project, the YP security team | ||
| 52 | notifies the project. Usually, the upstream project analyzes the problem again. | ||
| 53 | If they deem it a real security problem in their software, they develop and | ||
| 54 | release a fix following their security policy. They may want to include the | ||
| 55 | original reporter in the loop. There is also sometimes some coordination for | ||
| 56 | handling patches, backporting patches etc, or just understanding the problem | ||
| 57 | or what caused it. | ||
| 58 | |||
| 59 | When the fix is publicly available, the YP security team member or the | ||
| 60 | package maintainer sends patches against the YP code base, following usual | ||
| 61 | procedures, including public code review. | ||
| 62 | |||
| 63 | What Yocto Security Team does when it receives a security vulnerability | ||
| 64 | ======================================================================= | ||
| 65 | |||
| 66 | The YP Security Team team performs a quick analysis and would usually report | ||
| 67 | the flaw to the upstream project. Normally the upstream project analyzes the | ||
| 68 | problem. If they deem it a real security problem in their software, they | ||
| 69 | develop and release a fix following their own security policy. They may want | ||
| 70 | to include the original reporter in the loop. There is also sometimes some | ||
| 71 | coordination for handling patches, backporting patches etc, or just | ||
| 72 | understanding the problem or what caused it. | ||
| 73 | |||
| 74 | The security policy of the upstream project might include a notification to | ||
| 75 | Linux distributions or other important downstream projects in advance to | ||
| 76 | discuss coordinated disclosure. These mailing lists are normally non-public. | ||
| 77 | |||
| 78 | When the upstream project releases a version with the fix, they are responsible | ||
| 79 | for contacting `Mitre <https://www.cve.org/>`__ to get a CVE number assigned and | ||
| 80 | the CVE record published. | ||
| 81 | |||
| 82 | If an upstream project does not respond quickly | ||
| 83 | =============================================== | ||
| 84 | |||
| 85 | If an upstream project does not fix the problem in a reasonable time, | ||
| 86 | the Yocto's Security Team will contact other interested parties (usually | ||
| 87 | other distributions) in the community and together try to solve the | ||
| 88 | vulnerability as quickly as possible. | ||
| 89 | |||
| 90 | The Yocto Project Security team adheres to the 90 days disclosure policy | ||
| 91 | by default. An increase of the embargo time is possible when necessary. | ||
| 92 | |||
| 93 | Security Team Members | ||
| 94 | ===================== | ||
| 95 | |||
| 96 | For secure communications, please send your messages encrypted using the GPG | ||
| 97 | keys. Remember, message headers are not encrypted so do not include sensitive | ||
| 98 | information in the subject line. | ||
| 99 | |||
| 100 | - Ross Burton: <ross [at] burtonini [dot] com> `Public key <https://keys.openpgp.org/search?q=ross%40burtonini.com>`__ | ||
| 101 | |||
| 102 | - Michael Halstead: <mhalstead [at] linuxfoundation [dot] org> | ||
| 103 | `Public key <https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969>`__ | ||
| 104 | or `Public key <https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xd1f2407285e571ed12a407a73373170601861969>`__ | ||
| 105 | |||
| 106 | - Richard Purdie: <richard.purdie [at] linuxfoundation [dot] org> `Public key <https://keys.openpgp.org/search?q=richard.purdie%40linuxfoundation.org>`__ | ||
| 107 | |||
| 108 | - Marta Rybczynska: <marta DOT rybczynska [at] syslinbit [dot] com> `Public key <https://keys.openpgp.org/search?q=marta.rybczynska@syslinbit.com>`__ | ||
| 109 | |||
| 110 | - Steve Sakoman: <steve [at] sakoman [dot] com> `Public key <https://keys.openpgp.org/search?q=steve%40sakoman.com>`__ | ||
