Address review feedback

Author: sethmlarson

developer-workflow/psrt.rst

@@ -84,6 +84,8 @@ following additional responsibilities:
 * Running nomination elections, including counting final votes and giving
   the Steering Council an opportunity to veto nominations via email.
 
+.. _psrt-vulnerability-process:
+
 Triaging a vulnerability report
 -------------------------------
 

security-and-threat-model/index.rst security/index.rstsecurity-and-threat-model/index.rst renamed to security/index.rst

@@ -1,12 +1,12 @@
-=========================
-Security and threat model
-=========================
+========
+Security
+========
 
-The majority of Python Security Response Team (PSRT)
-members are volunteers. Therefore, you must respect this volunteered time
-by following this security policy. Repeated failure to
-respect the security policy will result in future reports
-being rejected or being banned from the `python` GitHub organization, regardless of technical merit.
+Python Security Response Team (PSRT) members balance this work against
+many other responsibilities. Please be thoughtful about the time and attention
+your report requires.  Repeated failure to respect the security policy will
+result in future reports being rejected or being banned from the ``python``
+GitHub organization, regardless of technical merit.
 
 What types of bugs are vulnerabilities?
 ---------------------------------------
@@ -15,6 +15,9 @@ Not all bugs are vulnerabilities. To avoid causing
 duplicate work for PSRT members all potential reports
 must be evaluated against the relevant threat models
 prior to being submitted to the PSRT.
+Where possible, cite the relevant threat model to show that
+the threat model has been considered while determining whether
+to report a bug as a vulnerability.
 
 Vulnerabilities must be exploitable from code, configurations,
 pre-conditions, and deployments that might feasibly exist in
@@ -23,21 +26,16 @@ that does not make sense in a production program
 will not be accepted as a vulnerability.
 
 Documented functionality will not be considered a vulnerability.
-For example, :mod:`pickle`, :mod:`marshal``, :mod:`shelve``, :mod:`eval``,
+For example, :mod:`pickle`, :mod:`marshal`, :mod:`shelve`, :mod:`eval`,
 and :mod:`exec` are documented to execute arbitrary Python code that is supplied
-as data. The :mod:`ctypes` module is documented to enable modifying arbitrary locations in memory.
+as data. The :mod:`ctypes` module is documented to enable modifying arbitrary
+locations in memory.
 
-Vulnerabilities must not depend on malicious control of:
-
-* what Python code is executed by the interpreter
-* locations where code is loaded prior to execution (such as current working
-  directory, ``PYTHONPATH``)
-* configuration files
-* environment variables
-* command line options
-* installed packages or modules
-* `.pth files <https://docs.python.org/3/library/site.html>`__
-* caches or ``.pyc`` files
+Vulnerabilities must not depend on malicious control of Python's launch
+conditions, including command line arguments, environment variables, or
+modifications to files on the target system. We assume that, at the time Python
+is executed, the environment is as intended by the legitimate user, and any
+malicious variation from this cannot be mitigated by Python itself.
 
 Vulnerabilities that affect availability (such as DoS, ReDoS) must be
 triggerable with data inputs that are reasonably sized for the use-case.
@@ -48,35 +46,32 @@ This is to avoid handling performance improvements as security vulnerabilities.
 Vulnerabilities in dependencies of Python (such as zlib, Tcl/Tk, or OpenSSL)
 are not vulnerabilities in Python unless Python's use of the dependency
 interferes with secure use of the dependency.
-For example, Python is not vulnerable because it bundles a vulnerable
-version of zlib, users are expected to upgrade their own dependencies.
-
-The complete threat model for Python and standard library modules
-is available in the Threat Model section of the Python Developer Guide.
+For example, a vulnerability in the bundled copy of zlib in Python is a
+vulnerability in zlib, not Python.
 
 What versions of Python are accepting reports?
 ----------------------------------------------
 
 Python accepts security vulnerabilities and will
-assign CVE IDs for `supported Python versions`_ that have a status of
-`"bugfix" or "security" <python-status>`_. Versions that are not yet
-stable (status of `"feature" or "prerelease" <python-status>`_) are not
-eligible for CVE IDs. If the vulnerability exclusively exists in
-non-stable versions, then the issue should be handled as a public bug issue.
+assign CVE IDs for `supported Python versions <branchstatus>`_ that have a status of
+`"bugfix" or "security" <version-status-key>`_. Versions that are not yet
+stable (status of `"feature" or "prerelease" <version-status-key>`_) are not
+eligible for CVE IDs. If the vulnerability only exists in prerelease versions
+(alphas, betas, release candidates), then the issue should be reported as a
+regular bug.
+Prior to submitting a report, check whether the issue has already been
+resolved on the ``main`` branch and only requires backporting.
 
 Sometimes features may be marked as
 "experimental" in Python, even in a stable Python version.
 These features are not eligible for security vulnerabilities.
 Instead open a public GitHub issue.
 
 If a vulnerability is platform-dependent, check if the platform is
-`supported per :pep:`11`.
+supported per :pep:`11`.
 Vulnerabilities that exclusively affect unsupported platforms
 may not be accepted.
 
-.. _supported Python versions: https://devguide.python.org/versions/
-.. _python-status: https://devguide.python.org/versions/#status-key
-
 What to include and how to structure a vulnerability report?
 ------------------------------------------------------------
 
@@ -87,7 +82,9 @@ be formatted correctly:
 * For the initial report and follow-up communications, avoid
   overly long, verbose, or excessive structure (such as headers or tables).
   Ideally reports should be a few sentences describing the vulnerability and
-  a proof-of-concept script that reproduces the issue.
+  a proof-of-concept script that reproduces the issue and provides a clear
+  indication whether the vulnerability is still present (such as exiting with
+  ``1`` if vulnerable and ``0`` if not vulnerable).
 * When reporting large numbers or "batches" of vulnerabilities or
   searching for potential vulnerabilities using an LLM, you as a reporter must
   verify the validity of all reports prior to submission to the PSRT.
@@ -124,7 +121,7 @@ Here's what to expect for how a vulnerability report will be handled:
   the advisory and CVE record will be published with attribution.
 
 For more information about how the PSRT handles vulnerabilities,
-`consult the Python Developer Guide <https://devguide.python.org/developer-workflow/psrt/#triaging-a-vulnerability-report>`__.
+`consult the Python Developer Guide <psrt-vulnerability-process>`__.
 
 PSF Code of Conduct
 -------------------

versions.rst

@@ -45,6 +45,7 @@ Full chart
 .. raw:: html
    :file: _static/release-cycle-all.svg
 
+.. _version-status-key:
 
 Status key
 ==========