From 8ddc5b444c175c696c8197dc8f24273252b0de77 Mon Sep 17 00:00:00 2001 From: Jacob Walls Date: Fri, 10 Apr 2026 14:40:40 -0400 Subject: Updated release procedure with new CVE workflows. Now that the DSF is a CVE Numbering Authority (CNA), we manage our own CVE assignments. --- docs/internals/howto-release-django.txt | 68 +++++++++++++++++++++++++++------ docs/spelling_wordlist | 1 + 2 files changed, 57 insertions(+), 12 deletions(-) diff --git a/docs/internals/howto-release-django.txt b/docs/internals/howto-release-django.txt index 248495b34c..fabf1331cc 100644 --- a/docs/internals/howto-release-django.txt +++ b/docs/internals/howto-release-django.txt @@ -53,6 +53,19 @@ The short version of the steps involved is: There are a lot of details, so please read on. +.. _checklist-generator: + +.. admonition:: Use the checklists app + + To generate a checklist compiling the tasks described below as relevant to + the specific release(s) you are issuing, use the checklists app in the + `project admin `_. This + populates a lot of boilerplate you will need for announcements, CVE + publication, and hashes for commit messages. By using this app for preparing + security issue metadata, your peer releasers can check your entries and + consult them again in the future. + (`Example `_) + Prerequisites ============= @@ -150,9 +163,23 @@ any time leading up to the actual release. 10 (or more) days before a security release ------------------------------------------- -#. Request the `CVE IDs `_ for the security - issue(s) being released. One CVE ID per issue, requested with - ``Vendor: djangoproject`` and ``Product: django``. +#. Reserve one `CVE ID `_ per security + issue as follows. (Or, if you lack CNA credentials, email + ``cna@djangoproject.com`` with a request.) + + * Enable virtual environment with :pypi:`cvelib` installed. + + * Export user information: + + .. code-block:: shell + + $ export CVE_USER=@djangoproject.com CVE_ORG=DSF + + * Reserve: + + .. code-block:: shell + + $ cve --interactive reserve #. Generate the relevant (private) patch(es) using ``git format-patch``, one for the ``main`` branch and one for each stable branch being patched. @@ -162,9 +189,9 @@ A week before a security release #. Send out pre-notification exactly **one week** before the security release. The template for that email and a list of the recipients are in the private - ``django-security`` GitHub wiki. BCC the pre-notification recipients and be + ``django-security`` GitHub wiki. BCC the pre-notification recipients, and be sure to include the relevant CVE IDs. Attach all the relevant patches - (targeting ``main`` and the stable branches) and sign the email text with + (targeting ``main`` and the stable branches), and sign the email text with the key you'll use for the release, with a command like: .. code-block:: shell @@ -185,6 +212,17 @@ A week before a security release For details of severity levels, see: https://docs.djangoproject.com/en/dev/internals/security/#how-django-discloses-security-issues +#. Prepare issue metadata: + * Severity + * Short description + * Reporter + * Remediator + * Reported at + * Confirmed at (usually date CVE reserved) + * CWE Problem Type + * CAPEC Impact Type + * CVSS (4.0) Score & Vector + A few days before any release ----------------------------- @@ -644,12 +682,18 @@ Now you're ready to actually put the release out there. To do this: #. Post the release announcement to the |django-announce| mailing list and the Django Forum. This should include a link to the announcement blog post. +#. If this is a security release, publish the CVE metadata. (The + :ref:`checklist app` generates JSON for this.): + + .. code-block:: shell + + $ cve publish --cve-json-file + #. If this is a security release, send a separate email to - ``oss-security@lists.openwall.com``. Provide a descriptive subject, for - example, "Django" plus the issue title from the release notes (including CVE - ID). The message body should include the vulnerability details, for example, - the announcement blog post text. Include a link to the announcement blog - post. + ``oss-security@lists.openwall.com``. Provide "Django" plus the CVE IDs in + the subject line. The message body should include the vulnerability details, + for example, the announcement blog post text. Include a link to the + announcement blog post. Post-release ============ @@ -708,8 +752,8 @@ You're almost done! All that's left to do now is: .. code-block:: shell - git checkout stable/A.B.x - git checkout -b update-translations-catalog-A.B.x + $ git checkout stable/A.B.x + $ git checkout -b update-translations-catalog-A.B.x #. Ensure that the release's dedicated virtual environment is enabled and run the following: diff --git a/docs/spelling_wordlist b/docs/spelling_wordlist index 1aa456b91a..46b7b21944 100644 --- a/docs/spelling_wordlist +++ b/docs/spelling_wordlist @@ -421,6 +421,7 @@ reindent releaser releasers reloader +remediator renderer renderers repo -- cgit v1.3