I have revised sections 9-12 for grammar and clarity. Signed-off-by: Nandini Persad <nandinipersad...@gmail.com> --- doc/guides/contributing/linux_uapi.rst | 32 ++-- doc/guides/contributing/patches.rst | 177 +++++++++++----------- doc/guides/contributing/stable.rst | 163 ++++++++------------ doc/guides/contributing/vulnerability.rst | 59 ++++---- 4 files changed, 193 insertions(+), 238 deletions(-)
diff --git a/doc/guides/contributing/linux_uapi.rst b/doc/guides/contributing/linux_uapi.rst index 79bedb478e..72abef2133 100644 --- a/doc/guides/contributing/linux_uapi.rst +++ b/doc/guides/contributing/linux_uapi.rst @@ -7,14 +7,14 @@ Linux uAPI header files Rationale --------- -The system a DPDK library or driver is built on is not necessarily running the -same Kernel version than the system that will run it. -Importing Linux Kernel uAPI headers enable to build features that are not -supported yet by the build system. +The system used to build a DPDK library or driver may not be running the same kernel version +as the target system where it will be deployed. To support features that are not yet available +in the build system’s kernel, Linux kernel uAPI headers can be imported. -For example, the build system runs upstream Kernel v5.19 and we would like to -build a VDUSE application that will use VDUSE_IOTLB_GET_INFO ioctl() introduced -in Linux Kernel v6.0. +For example, if the build system runs upstream Kernel v5.19, but you need to build a VDUSE application +that uses the VDUSE_IOTLB_GET_INFO ioctl introduced in Kernel v6.0, importing the relevant uAPI headers allows this. + +The Linux kernel's syscall license exception permits the inclusion of unmodified uAPI header files in such cases. `Linux Kernel licence exception regarding syscalls <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/LICENSES/exceptions/Linux-syscall-note>`_ @@ -23,20 +23,19 @@ enable importing unmodified Linux Kernel uAPI header files. Importing or updating an uAPI header file ----------------------------------------- -In order to ensure the imported uAPI headers are both unmodified and from a -released version of the linux Kernel, a helper script is made available and -MUST be used. +To ensure that imported uAPI headers are unmodified and sourced from an official Linux +kernel release, a helper script is provided and must be used. Below is an example to import ``linux/vduse.h`` file from Linux ``v6.10``: .. code-block:: console devtools/linux-uapi.sh -i linux/vduse.h -u v6.10 -Once imported, the header files should be committed without any other change. -Note that all the imported headers will be updated to the requested version. +Once imported, header files must be committed without any modifications. Note that all imported +headers will be updated to match the specified kernel version. -Updating imported headers to a newer released version should only be done on -a need basis, it can be achieved using the same script: +Updates to a newer released version should be performed only when necessary, and can be done +using the same helper script. .. code-block:: console @@ -60,8 +59,9 @@ Note that all the linux-uapi.sh script options can be combined. For example: Header inclusion into library or driver --------------------------------------- -The library or driver willing to make use of imported uAPI headers needs to -explicitly include the header file with ``uapi/`` prefix in C files. +Libraries or drivers that rely on imported uAPI headers must explicitly include +the relevant header using the ``uapi/`` prefix in their C source files. + For example to include VDUSE uAPI: .. code-block:: c diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst index d21ee288b2..88945b8f5d 100644 --- a/doc/guides/contributing/patches.rst +++ b/doc/guides/contributing/patches.rst @@ -5,56 +5,53 @@ Contributing Code to DPDK ========================= +his document provides guidelines for submitting code to DPDK. -This document outlines the guidelines for submitting code to DPDK. - -The DPDK development process is modeled (loosely) on the Linux Kernel development model so it is worth reading the -Linux kernel guide on submitting patches: +The DPDK development process is loosely based on the Linux Kernel development +model. It is recommended to review the Linux kernel's guide: `How to Get Your Change Into the Linux Kernel <https://www.kernel.org/doc/html/latest/process/submitting-patches.html>`_. -The rationale for many of the DPDK guidelines is explained in greater detail in the kernel guidelines. +Many of DPDK's submissions guidelines draw from the kernel process, +and the rationale behind them is often explained in greater depth there. The DPDK Development Process ---------------------------- -The DPDK development process has the following features: +The DPDK development process includes the following key elements: -* The code is hosted in a public git repository. -* There is a mailing list where developers submit patches. -* There are maintainers for hierarchical components. +* Code is maintained in a public Git repository. +* Developers submit patches via a public mailing list. +* Maintainers are assigned to different components in a hierarchical structure. * Patches are reviewed publicly on the mailing list. -* Successfully reviewed patches are merged to the repository. -* Patches should be sent to the target repository or sub-tree, see below. +* Once reviewed, patches are merged into the repository. +* Patches should be sent to the target repository or sub-tree (see below for details). The mailing list for DPDK development is `dev@dpdk.org <https://mails.dpdk.org/archives/dev/>`_. Contributors will need to `register for the mailing list <https://mails.dpdk.org/listinfo/dev>`_ in order to submit patches. -It is also worth registering for the DPDK `Patchwork <https://patches.dpdk.org/project/dpdk/list/>`_ +You should also register for DPDK `Patchwork <https://patches.dpdk.org/project/dpdk/list/>`_ -If you are using the GitHub service, pushing to a branch will trigger GitHub -Actions to automatically build your changes and run unit tests and ABI checks. +If you're using GitHub, pushing to a branch will trigger GitHub Actions +which will build your changes and run unit tests and ABI checks. -The development process requires some familiarity with the ``git`` version control system. -Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further information. +Contributing to DPDK requires a basic understanding of the Git control system. +For more information, refer to the `Pro Git Book <http://www.git-scm.com/book/>`_. Source License -------------- -The DPDK uses the Open Source BSD-3-Clause license for the core libraries and -drivers. The kernel components are GPL-2.0 licensed. DPDK uses single line -reference to Unique License Identifiers in source files as defined by the Linux -Foundation's `SPDX project <http://spdx.org/>`_. +DPDK uses the Open Source BSD-3-Clause license for its core libraries and +drivers. Kernel components are GPL-2.0 licensed. +To identify licenses in source files, DPDK follows the SPDX standard +developed by the Linux Foundation `SPDX project <http://spdx.org/>`_. -DPDK uses first line of the file to be SPDX tag. In case of *#!* scripts, SPDX -tag can be placed in 2nd line of the file. +The SPDX tag should by used on the first line of the file. +In case of *#!* scripts, the SPDX tag should be placed on 2nd line. -For example, to label a file as subject to the BSD-3-Clause license, -the following text would be used: +For BSD-3-Clause: ``SPDX-License-Identifier: BSD-3-Clause`` -To label a file as dual-licensed with BSD-3-Clause and GPL-2.0 (e.g., for code -that is shared between the kernel and userspace), the following text would be -used: +For dual-licensing with BSD-3-Clause and GPL-2.0 (e.g.,shared kernel/user-space code): ``SPDX-License-Identifier: (BSD-3-Clause OR GPL-2.0)`` @@ -87,37 +84,41 @@ Where: Additional details are given in the ``MAINTAINERS`` file. -The role of the component maintainers is to: +Component maintainers are responsible for the following: -* Review patches for the component or delegate the review. +* Reviewing patches related to their component or delegating the review to others. The review should be done, ideally, within 1 week of submission to the mailing list. -* Add an ``acked-by`` to patches, or patchsets, that are ready for committing to a tree. -* Reply to questions asked about the component. +* Acknowledging patches by adding an ``acked-by`` tag to those deemed ready for merging. +* Responding to questions regarding the component and offering guidance when needed. + +Maintainers can be added or removed by submitting a patch to the ``MAINTAINERS`` file. +New maintainers should have demonstrated consistent contributions or reviews to the component area. +Their addition should be confirmed by an ``ack`` from an established contributor. +Multiple maintainers may be assigned to a single component, if needed. + +Tree Maintainer Responsibilities: + +Tree maintainers are responsible for ensuring the overall quality and integrity of their tree. +Their duties include: + +* Conducting additional reviews, compilation checks, or other tests as needed. +* Committing patches that have been sufficiently reviewed by component maintainers or other contributors. +* Ensuring timely review of submitted patches. +* Preparing the tree for integration. +* Appointing a designated backup maintainer and coordinating handovers when unavailable. -Component maintainers can be added or removed by submitting a patch to the ``MAINTAINERS`` file. -Maintainers should have demonstrated a reasonable level of contributions or reviews to the component area. -The maintainer should be confirmed by an ``ack`` from an established contributor. -There can be more than one component maintainer if desired. +Maintainer Changes: -The role of the tree maintainers is to: +Tree maintainers can be added or removed by submitting a patch to the MAINTAINERS file. +Proposals must justify the creation of a new sub-tree and demonstrate a significant contribution +to the relevant area. An ack from an existing tree maintainer is required. -* Maintain the overall quality of their tree. - This can entail additional review, compilation checks or other tests deemed necessary by the maintainer. -* Commit patches that have been reviewed by component maintainers and/or other contributors. - The tree maintainer should determine if patches have been reviewed sufficiently. -* Ensure that patches are reviewed in a timely manner. -* Prepare the tree for integration. -* Ensure that there is a designated back-up maintainer and coordinate a handover for periods where the - tree maintainer can't perform their role. +In case of disputes regarding trees or maintainers, issues may be escalated to the Technical Board. -Tree maintainers can be added or removed by submitting a patch to the ``MAINTAINERS`` file. -The proposer should justify the need for a new sub-tree and should have demonstrated a sufficient level of contributions in the area or to a similar area. -The maintainer should be confirmed by an ``ack`` from an existing tree maintainer. -Disagreements on trees or maintainers can be brought to the Technical Board. +Backup Maintainers: -The backup maintainer for the main tree should be selected -from the existing sub-tree maintainers of the project. -The backup maintainer for a sub-tree should be selected from among the component maintainers within that sub-tree. +* The main tree's backup maintainer should be chosen from among existing sub-tree maintainers. +* A sub-tree's backup should come from the component maintainers within that sub-tree. Getting the Source Code @@ -135,63 +136,57 @@ sub-repositories (`list <https://git.dpdk.org/next>`_):: git clone git://dpdk.org/next/dpdk-next-* git clone https://dpdk.org/git/next/dpdk-next-* -Make your Changes ------------------ -Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines and requirements: -* Follow the :ref:`coding_style` guidelines. +Make Changes +------------ + +Once you've cloned the DPDK repository, make your planned changes while following +these key guidelines and requirements: -* If you are a new contributor, or if your mail address changed, - you may update the ``.mailmap`` file. - Otherwise the new name or address will be added by a maintainer. - Keeping this file up-to-date will help when someone wants to contact you - about the changes you contributed to. +* Follow the :ref:`coding_style` guidelines. +* Update ``.mailmap`` if you’re a new contributor or have changed your email address. + Maintainers may also handle this, but keeping it current ensures others can contact you about your contributions. +* Update ``MAINTAINERS`` if you add new files or directories, by adding your name under the appropriate section. -* If you add new files or directories you should add your name to the ``MAINTAINERS`` file. +PMD Submissions +~~~~~~~~~~~~~~~ -* Initial submission of new PMDs should be prepared against a corresponding repo. +Submit new PMDs to the appropriate next repo: - * Thus, for example, initial submission of a new network PMD should be - prepared against dpdk-next-net repo. +* New network PMDs → dpdk-next-net - * Likewise, initial submission of a new crypto or compression PMD should be - prepared against dpdk-next-crypto repo. +* New crypto or compression PMDs → dpdk-next-crypto - * For other PMDs and more info, refer to the ``MAINTAINERS`` file. +* For other PMD types, refer to the MAINTAINERS file. -* New external functions should be added to the local ``version.map`` file. See - the :doc:`ABI policy <abi_policy>` and :ref:`ABI versioning <abi_versioning>` - guides. New external functions should also be added in alphabetical order. +API and ABI Guidelines +~~~~~~~~~~~~~~~~~~~~~~ -* Any new API function should be used in ``/app`` test directory. +* Add any new external functions to the relevant ``version.map`` file in alphabetical order. + Refer to the ABI policy and ABI versioning documentation. -* When introducing a new device API, at least one driver should implement it. +* New API functions should be accompanied by a corresponding test in the /app/test directory. -* Important changes will require an addition to the release notes in ``doc/guides/rel_notes/``. - See the :ref:`Release Notes section of the Documentation Guidelines <doc_guidelines>` for details. +* When adding a new device API, ensure that at least one driver implements it. -* Test the compilation works with different targets, compilers and options, see :ref:`contrib_check_compilation`. +Documentation and Release Notes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -* Don't break compilation between commits with forward dependencies in a patchset. - Each commit should compile on its own to allow for ``git bisect`` and continuous integration testing. +* Document new APIs using Doxygen-style comments. -* Add tests to the ``app/test`` unit test framework where possible. +* If needed, provide user-facing documentation in reStructuredText (RST) format, following the Documentation Guidelines. -* Add documentation, if relevant, in the form of Doxygen comments or a User Guide in RST format. - See the :ref:`Documentation Guidelines <doc_guidelines>`. +* For major changes, add an entry to the release notes under doc/guides/rel_notes/. -* Code and related documentation must be updated atomically in the same patch. +Compilation and Testing +~~~~~~~~~~~~~~~~~~~~~~~ -Once the changes have been made you should commit them to your local repo. +* Test compilation across different targets, compilers, and build options (see Checking Compilation :ref:`contrib_check_compilation`.). -For small changes, that do not require specific explanations, it is better to keep things together in the -same patch. -Larger changes that require different explanations should be separated into logical patches in a patchset. -A good way of thinking about whether a patch should be split is to consider whether the change could be -applied without dependencies as a backport. +* Each commit in a patchset must compile independently to support git bisect and CI testing. -As a guide to how patches should be structured run ``git log`` on similar files. +* Include unit tests in the app/test framework wherever applicable. Commit Messages: Subject Line @@ -229,7 +224,7 @@ It is intended as a way of getting early feedback. Commit Messages: Body --------------------- -Here are some guidelines for the body of a commit message: +Here are guidelines for the body of a commit message: * The body of the message should describe the issue being fixed or the feature being added. It is important to provide enough information to allow a reviewer to understand the purpose of the patch. @@ -566,6 +561,10 @@ Script ``get-maintainer.sh`` can be used to select maintainers automatically:: git send-email --to-cmd ./devtools/get-maintainer.sh --cc dev@dpdk.org 000*.patch +New additions can be sent without a maintainer:: + + git send-email --to dev@dpdk.org 000*.patch + You can test the emails by sending it to yourself or with the ``--dry-run`` option. If the patch is in relation to a previous email thread you can add it to the same thread using the Message ID:: diff --git a/doc/guides/contributing/stable.rst b/doc/guides/contributing/stable.rst index 808e7fa779..9e8b6d4f62 100644 --- a/doc/guides/contributing/stable.rst +++ b/doc/guides/contributing/stable.rst @@ -6,154 +6,117 @@ DPDK Stable Releases and Long Term Support ========================================== -This section sets out the guidelines for the DPDK Stable Releases and the DPDK -Long Term Support releases (LTS). +This section outlines the guidelines for DPDK Stable Releases and Long Term Support (LTS) Releases. Introduction ------------ -The purpose of the DPDK Stable Releases is to maintain releases of DPDK with -backported fixes over an extended period of time. This provides downstream -consumers of DPDK with a stable target on which to base applications or -packages. +The purpose of DPDK Stable Releases is to maintain DPDK versions with backported +fixes over an extended period. This allows downstream users to base applications +or packages on a stable, well-maintained version of DPDK. -The primary characteristics of stable releases is that they attempt to -fix issues and not introduce any new regressions while keeping backwards -compatibility with the initial release of the stable version. - -The Long Term Support release (LTS) is a designation applied to a Stable -Release to indicate longer term support. +The primary goal of stable releases is to fix issues without introducing regressions, +while preserving backward compatibility with the original version. +LTS (Long Term Support) is a designation given to specific stable releases to indicate +extended support duration. Stable Releases --------------- -Any release of DPDK can be designated as a Stable Release if a -maintainer volunteers to maintain it and there is a commitment from major -contributors to validate it before releases. -If a version is to be a "Stable Release", it should be designated as such -within one month of that version being initially released. - -A Stable Release is used to backport fixes from an ``N`` release back to an -``N-1`` release, for example, from 16.11 to 16.07. - -The duration of a stable is one complete release cycle (4 months). It can be -longer, up to 1 year, if a maintainer continues to support the stable branch, -or if users supply backported fixes, however the explicit commitment should be -for one release cycle. - -The release cadence is determined by the maintainer based on the number of -bugfixes and the criticality of the bugs. Releases should be coordinated with -the validation engineers to ensure that a tagged release has been tested. +Any DPDK release may become a Stable Release if a maintainer volunteers to support it +and major contributors commit to validating it before each release. This designation +should ideally be made within one month of the version’s initial release. +Stable Releases are typically used to backport fixes from an N release to an N-1 release. +For example: from version 16.11 to 16.07. -LTS Release ------------ +- The standard support duration is one full release cycle (4 months). +- This may extend up to one year if the maintainer continues support or if users provide backported fixes. +- The release cadence is determined by the maintainer based on the volume and criticality of fixes. +- Releases must be coordinated with validation engineers to ensure proper testing before tagging. -A stable release can be designated as an LTS release based on community -agreement and a commitment from a maintainer. The current policy is that each -year's November (X.11) release will be maintained as an LTS for 3 years, -however that is dependent on continued community support for validation. +LTS Releases +------------ -After the X.11 release, an LTS branch will be created for it at -https://git.dpdk.org/dpdk-stable where bugfixes will be backported to. +A Stable Release can be promoted to an LTS Release through community agreement and a maintainer’s commitment. -A LTS release may align with the declaration of a new major ABI version, -please read the :doc:`abi_policy` for more information. +- The current policy designates each November release (X.11) as an LTS and maintains it for 3 years, + contingent on community validation support. +- After release, an LTS branch is created at: https://git.dpdk.org/dpdk-stable +- Fixes are backported to this branch. +- LTS Releases may coincide with the declaration of a new major ABI version. Refer to the :ref:`abi_policy` for details. -It is anticipated that there will be at least 3 releases per year of the LTS -or approximately 1 every 4 months. This is done to align with the DPDK main -branch releases so that fixes have already gone through validation as part of -the DPDK main branch release validation. However, the cadence can be shorter or -longer depending on the number and criticality of the backported -fixes. Releases should be coordinated with the validation engineers to ensure -that a tagged release has been tested. +Release Cadence: -For a list of the currently maintained stable/LTS branches please see -the latest `stable roadmap <https://core.dpdk.org/roadmap/#stable>`_. +- At least three LTS updates per year (roughly one every four months). +- Aligned with main DPDK releases to leverage shared validation. +- Frequency may vary depending on the urgency and volume of fixes. +- As with stable releases, validation must be coordinated with test engineers. -At the end of the 3 years, a final X.11.N release will be made and at that -point the LTS branch will no longer be maintained with no further releases. +For the latest list of supported Stable/LTS branches, refer to the current stable roadmap. +At the end of the 3-year period, a final `X.11.N` release will be made, after which the LTS branch will no longer be maintained. -What changes should be backported +What Changes Should Be Backported --------------------------------- -Backporting should be limited to bug fixes. All patches accepted on the main -branch with a Fixes: tag should be backported to the relevant stable/LTS -branches, unless the submitter indicates otherwise. If there are exceptions, -they will be discussed on the mailing lists. - -Fixes suitable for backport should have a ``Cc: sta...@dpdk.org`` tag in the -commit message body as follows:: - - doc: fix some parameter description +Backports should be limited to **bug fixes**. - Update the docs, fixing description of some parameter. +All main-branch patches with a ``Fixes:`` tag should be considered for backport unless the +submitter indicates otherwise. These patches must include a ``Cc: sta...@dpdk.org`` tag in the commit message: - Fixes: abcdefgh1234 ("doc: add some parameter") - Cc: sta...@dpdk.org +.. code-block:: none - Signed-off-by: Alex Smith <alex.sm...@example.com> + doc: fix parameter description + Update the docs to fix the description of a parameter. -Fixes not suitable for backport should not include the ``Cc: sta...@dpdk.org`` tag. + Fixes: abcdefgh1234 ("doc: add some parameter") + Cc: sta...@dpdk.org -To support the goal of stability and not introducing regressions, -new code being introduced is limited to bug fixes. -New features should not be backported to stable releases. + Signed-off-by: Alex Smith <alex.sm...@example.com> -In some limited cases, it may be acceptable to backport a new feature -to a stable release. Some of the factors which impact the decision by -stable maintainers are as follows: +Patches **not** suitable for backport should omit the ``Cc: sta...@dpdk.org`` tag. -* Does the feature break API/ABI? -* Does the feature break backwards compatibility? -* Is it for the latest LTS release (to avoid LTS upgrade issues)? -* Is there a commitment from the proposer or affiliation to validate the feature - and check for regressions in related functionality? -* Is there a track record of the proposer or affiliation validating stable releases? -* Is it obvious that the feature will not impact existing functionality? -* How intrusive is the code change? -* What is the scope of the code change? -* Does it impact common components or vendor specific? -* Is there a justifiable use case (a clear user need)? -* Is there a community consensus about the backport? +Backports must avoid introducing new features. However, in limited cases, a new feature may be allowed if: -Performance improvements are generally not considered to be fixes, -but may be considered in some cases where: +- It does **not** break API or ABI. +- It preserves **backward compatibility**. +- It targets the latest LTS release (to help with upgrade paths). +- The proposer commits to testing the feature and monitoring regressions. +- The proposer or their organization has a strong track record of validating stable releases. +- It clearly does not impact existing functionality. +- The change is minimally invasive and scoped. +- It affects vendor-specific components rather than common ones. +- There is a compelling use case. +- There is broad community support. -* It is fixing a performance regression that occurred previously. -* An existing feature in LTS is not usable as intended without it. +Performance enhancements are generally not considered bug fixes, unless: -APIs marked as ``experimental`` are not considered part of the ABI version -and can be changed without prior notice. This is necessary for the API to be -improved and stabilized and become part of the ABI version in the future. +- They resolve a performance regression. +- They are necessary to make an existing feature usable. -However, in LTS releases ``experimental`` API should not be changed as there -will not be a future ABI version on the branch and compatibility with previous -release of an LTS version is of the highest importance. +**Experimental APIs** are excluded from the ABI versioning and may be changed in mainline development. +However, **experimental APIs must not be modified in LTS branches**, where stability and compatibility are paramount. The Stable Mailing List ----------------------- -The Stable and LTS release are coordinated on the sta...@dpdk.org mailing -list. +Coordination for all Stable and LTS releases occurs on the ``sta...@dpdk.org`` mailing list. -All fix patches to the main branch that are candidates for backporting -should also be CCed to the `sta...@dpdk.org <https://mails.dpdk.org/listinfo/stable>`_ -mailing list. +All fix patches intended for backporting should be CCed to this list when sent to the main branch. Releasing --------- -A Stable Release will be released by: +A Stable Release will be occur by: * Tagging the release with YY.MM.n (year, month, number). * Uploading a tarball of the release to dpdk.org. * Sending an announcement to the `annou...@dpdk.org <https://mails.dpdk.org/listinfo/announce>`_ list. -Stable releases are available on the `dpdk.org download page <https://core.dpdk.org/download/>`_. +Stable releases are available on the `dpdk.org download page <https://core.dpdk.org/download/>`_. \ No newline at end of file diff --git a/doc/guides/contributing/vulnerability.rst b/doc/guides/contributing/vulnerability.rst index fc60e02e37..aee618f6ec 100644 --- a/doc/guides/contributing/vulnerability.rst +++ b/doc/guides/contributing/vulnerability.rst @@ -23,41 +23,33 @@ If in doubt, please consider the vulnerability as security sensitive. At worst, the response will be to report the bug through the usual channels. -Finding -------- +Finding Security Issues +----------------------- There is no pro-active security engineering effort at the moment. Please report any security issue you find in DPDK as described below. -Report ------- +Reporting Security Issues +------------------------- -Do not use Bugzilla (unsecured). -Instead, send GPG-encrypted emails -to `secur...@dpdk.org <https://core.dpdk.org/security#contact>`_. -Anyone can post to this list. -In order to reduce the disclosure of a vulnerability in the early stages, -membership of this list is intentionally limited to a `small number of people -<https://mails.dpdk.org/roster/security>`_. +Do not use Bugzilla to report security vulnerabilities, as it is not secured for such communication. +Instead, send a GPG-encrypted email to `secur...@dpdk.org <https://core.dpdk.org/security#contact>`_. +This address is open to all, but access to its inbox is intentionally limited to a small group +to minimize the risk of early disclosure. -It is additionally encouraged to GPG-sign one-on-one conversations -as part of the security process. +It is strongly recommended to GPG-sign any one-on-one correspondence related to the vulnerability +report as part of maintaining a secure communication process. -As it is with any bug, the more information provided, -the easier it will be to diagnose and fix. -If you already have a fix, please include it with your report, -as that can speed up the process considerably. +As with any bug report, detailed information greatly aids in diagnosing and resolving the issue. +If you have already developed a fix, please include it in your submission to help accelerate resolution. -In the report, please note how you would like to be credited -for discovering the issue -and the details of any embargo you would like to impose. +In your report, specify how you would like to be credited for the discovery and mention any embargo +period you wish to impose. -If the vulnerability is not public yet, -no patch or information should be disclosed publicly. -If a fix is already published, -the reporting process must be followed anyway, as described below. +If the vulnerability has not yet been made public, do not disclose patches or related information +publicly. Even if a fix has already been published, the proper reporting process outlined here must still be followed. Confirmation @@ -91,7 +83,7 @@ using the standard patch process, once a CVE number has been assigned. The confirmation mail should be sent within **3 business days**. -Following information must be included in the mail: +The following information must be included in the mail: * Confirmation * CVSS severity and score @@ -275,17 +267,18 @@ Private Disclosure Mail Template Public Disclosure ----------------- -On embargo expiration, following tasks will be done simultaneously: +When the embargo expires, the following actions will be carried out simultaneously: -* The assigned bug is filled by a member of the security team, - with all relevant information, and it is made public. -* The patches are pushed to the appropriate branches. -* For long and short term stable branches fixed, - new versions should be released. +* A member of the security team files the assigned bug with all relevant details and makes it publicly accessible. -Releases on Monday to Wednesday are preferred, so that system administrators -do not have to deal with security updates over the weekend. +* The associated patches are pushed to the appropriate branches. +* Updated versions are released for all affected stable branches, both short-term and long-term. + +To ease adoption by system administrators, security releases are preferably +scheduled between Monday and Wednesday, avoiding weekends. + +A security advisory is sent to annou...@dpdk.org and the public OSS Security mailing list as soon as the patches are published. The security advisory is posted to `annou...@dpdk.org <mailto:annou...@dpdk.org>`_ and to `the public OSS-security mailing list <mailto:oss-secur...@lists.openwall.com>` as soon as the patches -- 2.34.1
