diff options
-rw-r--r-- | doc/contributing/submitting-changes.xml | 27 |
1 files changed, 27 insertions, 0 deletions
diff --git a/doc/contributing/submitting-changes.xml b/doc/contributing/submitting-changes.xml index 14155021f614..6a8b4e0b249e 100644 --- a/doc/contributing/submitting-changes.xml +++ b/doc/contributing/submitting-changes.xml @@ -228,6 +228,33 @@ Additional information. </listitem> </itemizedlist> </section> + <section xml:id="submitting-changes-submitting-security-fixes"> + <title>Submitting security fixes</title> + + <para> + Security fixes are submitted in the same way as other changes and thus the same guidelines apply. + </para> + + <para> + If the security fix comes in the form of a patch and a CVE is available, then the name of the patch should be the CVE identifier, so e.g. <literal>CVE-2019-13636.patch</literal> in the case of a patch that is included in the Nixpkgs tree. If a patch is fetched the name needs to be set as well, e.g.: + </para> + +<programlisting> + (fetchpatch { + name = "CVE-2019-11068.patch"; + url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch"; + sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8"; + }) + </programlisting> + + <para> + If a security fix applies to both master and a stable release then, similar to regular changes, they are preferably delivered via master first and cherry-picked to the release branch. + </para> + + <para> + Critical security fixes may by-pass the staging branches and be delivered directly to release branches such as <literal>master</literal> and <literal>release-*</literal>. + </para> + </section> <section xml:id="submitting-changes-pull-request-template"> <title>Pull Request Template</title> |