Add a Security Implications section

python · warsaw · 11f72a0d9d3faa0a7334d198e03efba2eeb8abfd
commit 11f72a0d9d3faa0a7334d198e03efba2eeb8abfd
@@ -1243,6 +1243,43 @@ A suggested approach:
    compatibility.
 
 
+.. _security-implications:
+
+Security Implications
+=====================
+
+Does PEP 694 make it easier to (maliciously) register project names, i.e. to name- or typo-squat?  The authors
+do not believe so.  With the legacy API, it's trivially easy to create and upload a dummy package to register
+a project name.  This PEP does not effectively change that equation either way, nor does it aim to.  That
+said, indexes such as PyPI could impose additional limitations on project registration activities, such as
+rate limiting either the legacy API or Upload 2.0 API for empty packages or sessions.  An index such as PyPI
+which supports organizations or :pep:`752`-style implicit namespaces, could implement different rate limiting
+rules for different actors.  Such implementations are left as index-specific policy decisions.
+
+It's possible for a user with upload permissions at the start of a session to lose such permissions while a
+session is open and before the entire session is published.  Indexes should consider re-validating permissions
+at key points during the session lifecycle, such as on artifact uploads, file upload session completion,
+session extension requests, or at publish time.
+
+Staged releases, while useful for testing and embargoes, do provide some potential for larger scale hosting of
+malware which isn't detectable by third party, external scanning tools, because staged artifacts are only
+visible to clients which hold the stage token/url.  It's not clear how much proactive malware scanning is
+actually going on today with indexes such as PyPI, so it's unclear whether the (optional) staging feature is
+much of an additional malware vector.  Indexes should likely do some amount of proactive malware scanning on
+all artifacts, regardless of the protocol used to upload them.  Indexes can also mitigate the problem by
+putting limits on session extensions, which might differ between projects depending on the user or (in the
+case of PyPI) organization which owns the project.  Indexes can refuse to extend sessions, and they can use
+this to limit the availability of packages with unverified contents.
+
+Considering the testing and embargoed use cases may lead to different session expiry choices.  Testing a
+release can have a relatively short session lifespan, e.g. on the order of hours.  Embargoed sessions may need
+to be extended for several days or a few weeks.  An index such as PyPI could use any number of criteria to
+determine the total lifetime of any particular session, such as whether the credentials are a user or an
+organization.  An index could even support :ref:`index-specific-metadata` to decide whether the testing or
+embargoed use case is being employed.
+
+.. _faq:
+
 FAQ
 ===
 
@@ -1376,6 +1413,7 @@ Change History
   * Add non-normative :ref:`Recommendations for Client Implementers <client-recommendations>` section
     with suggested UX patterns for tools like twine, uv, and GitHub Actions.
   * Add FAQ entries explaining why project name and version are required at session creation.
+  * Add a :ref:`security-implications` section.
 
 * `06-Dec-2025 <https://discuss.python.org/t/pep-694-pypi-upload-api-2-0-round-2/101483/35>`__