CINXE.COM

<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta name="color-scheme" content="light dark"> <title>PEP 708 – Extending the Repository API to Mitigate Dependency Confusion Attacks | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0708/"> <link rel="stylesheet" href="../_static/style.css" type="text/css"> <link rel="stylesheet" href="../_static/mq.css" type="text/css"> <link rel="stylesheet" href="../_static/pygments.css" type="text/css" media="(prefers-color-scheme: light)" id="pyg-light"> <link rel="stylesheet" href="../_static/pygments_dark.css" type="text/css" media="(prefers-color-scheme: dark)" id="pyg-dark"> <link rel="alternate" type="application/rss+xml" title="Latest PEPs" href="https://peps.python.org/peps.rss"> <meta property="og:title" content='PEP 708 – Extending the Repository API to Mitigate Dependency Confusion Attacks | peps.python.org'> <meta property="og:description" content="Dependency confusion attacks, in which a malicious package is installed instead of the one the user expected, are an increasingly common supply chain threat. Most such attacks against Python dependencies, including the recent PyTorch incident, occur wit..."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0708/"> <meta property="og:site_name" content="Python Enhancement Proposals (PEPs)"> <meta property="og:image" content="https://peps.python.org/_static/og-image.png"> <meta property="og:image:alt" content="Python PEPs"> <meta property="og:image:width" content="200"> <meta property="og:image:height" content="200"> <meta name="description" content="Dependency confusion attacks, in which a malicious package is installed instead of the one the user expected, are an increasingly common supply chain threat. Most such attacks against Python dependencies, including the recent PyTorch incident, occur wit..."> <meta name="theme-color" content="#3776ab"> </head> <body> <svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <symbol id="svg-sun-half" viewBox="0 0 24 24" pointer-events="all"> <title>Following system colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="9"></circle> <path d="M12 3v18m0-12l4.65-4.65M12 14.3l7.37-7.37M12 19.6l8.85-8.85"></path> </svg> </symbol> <symbol id="svg-moon" viewBox="0 0 24 24" pointer-events="all"> <title>Selected dark colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <path stroke="none" d="M0 0h24v24H0z" fill="none"></path> <path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z"></path> </svg> </symbol> <symbol id="svg-sun" viewBox="0 0 24 24" pointer-events="all"> <title>Selected light colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="5"></circle> <line x1="12" y1="1" x2="12" y2="3"></line> <line x1="12" y1="21" x2="12" y2="23"></line> <line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line> <line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line> <line x1="1" y1="12" x2="3" y2="12"></line> <line x1="21" y1="12" x2="23" y2="12"></line> <line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line> <line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line> </svg> </symbol> </svg> <script> document.documentElement.dataset.colour_scheme = localStorage.getItem("colour_scheme") || "auto" </script> <section id="pep-page-section"> <header> <h1>Python Enhancement Proposals</h1> <ul class="breadcrumbs"> <li><a href="https://www.python.org/" title="The Python Programming Language">Python</a> » </li> <li><a href="../pep-0000/">PEP Index</a> » </li> <li>PEP 708</li> </ul> <button id="colour-scheme-cycler" onClick="setColourScheme(nextColourScheme())"> <svg aria-hidden="true" class="colour-scheme-icon-when-auto"><use href="#svg-sun-half"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-dark"><use href="#svg-moon"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-light"><use href="#svg-sun"></use></svg> Toggle light / dark / auto colour theme </button> </header> <article> <section id="pep-content"> <h1 class="page-title">PEP 708 – Extending the Repository API to Mitigate Dependency Confusion Attacks</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author:</dt> <dd class="field-odd">Donald Stufft <donald at stufft.io></dd> <dt class="field-even">PEP-Delegate:</dt> <dd class="field-even">Paul Moore <p.f.moore at gmail.com></dd> <dt class="field-odd">Discussions-To:</dt> <dd class="field-odd"><a class="reference external" href="https://discuss.python.org/t/24179">Discourse thread</a></dd> <dt class="field-even">Status:</dt> <dd class="field-even"><abbr title="Provisionally accepted but additional feedback needed">Provisional</abbr></dd> <dt class="field-odd">Type:</dt> <dd class="field-odd"><abbr title="Normative PEP with a new feature for Python, implementation change for CPython or interoperability standard for the ecosystem">Standards Track</abbr></dd> <dt class="field-even">Topic:</dt> <dd class="field-even"><a class="reference external" href="../topic/packaging/">Packaging</a></dd> <dt class="field-odd">Created:</dt> <dd class="field-odd">20-Feb-2023</dd> <dt class="field-even">Post-History:</dt> <dd class="field-even"><a class="reference external" href="https://discuss.python.org/t/23414/" title="Discourse thread">01-Feb-2023</a>, <a class="reference external" href="https://discuss.python.org/t/24179" title="Discourse thread">23-Feb-2023</a></dd> <dt class="field-odd">Resolution:</dt> <dd class="field-odd"><a class="reference external" href="https://discuss.python.org/t/24179/72">Discourse message</a></dd> </dl> <hr class="docutils" /> <section id="contents"> <details><summary>Table of Contents</summary><ul class="simple"> <li><a class="reference internal" href="#provisional-acceptance">Provisional Acceptance</a></li> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#motivation">Motivation</a></li> <li><a class="reference internal" href="#rationale">Rationale</a></li> <li><a class="reference internal" href="#specification">Specification</a><ul> <li><a class="reference internal" href="#repository-tracks-metadata">Repository “Tracks” Metadata</a><ul> <li><a class="reference internal" href="#json">JSON</a></li> <li><a class="reference internal" href="#html">HTML</a></li> </ul> </li> <li><a class="reference internal" href="#alternate-locations-metadata">“Alternate Locations” Metadata</a><ul> <li><a class="reference internal" href="#id1">JSON</a></li> <li><a class="reference internal" href="#id2">HTML</a></li> </ul> </li> </ul> </li> <li><a class="reference internal" href="#recommendations">Recommendations</a><ul> <li><a class="reference internal" href="#file-discovery-algorithm">File Discovery Algorithm</a></li> <li><a class="reference internal" href="#explicit-configuration-for-end-users">Explicit Configuration for End Users</a></li> </ul> </li> <li><a class="reference internal" href="#how-to-communicate-this">How to Communicate This</a><ul> <li><a class="reference internal" href="#what-is-changing">What is Changing?</a></li> <li><a class="reference internal" href="#who-is-affected">Who is Affected?</a></li> <li><a class="reference internal" href="#what-do-i-need-to-do">What do I need to do?</a><ul> <li><a class="reference internal" href="#as-a-pip-user">As a pip User?</a></li> <li><a class="reference internal" href="#as-a-project-owner">As a Project Owner?</a></li> <li><a class="reference internal" href="#as-a-repository-operator">As a Repository Operator?</a></li> </ul> </li> </ul> </li> <li><a class="reference internal" href="#rejected-ideas">Rejected Ideas</a><ul> <li><a class="reference internal" href="#implicitly-allow-mirrors-when-the-list-of-files-are-the-same">Implicitly allow mirrors when the list of files are the same</a></li> <li><a class="reference internal" href="#provide-a-mechanism-to-order-the-repositories">Provide a mechanism to order the repositories</a></li> <li><a class="reference internal" href="#rely-on-repository-proxies">Rely on repository proxies</a></li> <li><a class="reference internal" href="#rely-only-on-hash-checking">Rely only on hash checking</a></li> <li><a class="reference internal" href="#require-all-projects-to-exist-in-the-default-repository">Require all projects to exist in the “default” repository</a></li> <li><a class="reference internal" href="#move-to-globally-unique-names">Move to Globally Unique Names</a></li> <li><a class="reference internal" href="#only-recommend-that-installers-offer-explicit-configuration">Only recommend that installers offer explicit configuration</a></li> <li><a class="reference internal" href="#scopes-a-la-npm">Scopes à la npm</a></li> <li><a class="reference internal" href="#define-and-standardize-the-explicit-configuration">Define and Standardize the “Explicit Configuration”</a></li> </ul> </li> <li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> </details></section> <section id="provisional-acceptance"> <h2><a class="toc-backref" href="#provisional-acceptance" role="doc-backlink">Provisional Acceptance</a></h2> This PEP has been provisionally accepted, with the following required conditions before the PEP is made Final: <ol class="arabic simple"> <li>An implementation of the PEP in PyPI (Warehouse) including any necessary UI elements to allow project owners to set the tracking data.</li> <li>An implementation of the PEP in at least one repository other than PyPI, as you can’t really test merging indexes without at least two indexes.</li> <li>An implementation of the PEP in pip, which supports the intended semantics and can be used to demonstrate that the expected security benefits are achieved. This implementation will need to be “off by default” initially, which means that users will have to opt in to testing it. Ideally, we should collect explicit positive reports from users (both project owners and project users) who have successfully tried out the new feature, rather than just assuming that “no news is good news”.</li> </ol> </section> <section id="abstract"> <h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2> Dependency confusion attacks, in which a malicious package is installed instead of the one the user expected, are an <a class="reference external" href="https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610">increasingly common supply chain threat</a>. Most such attacks against Python dependencies, including the <a class="reference external" href="https://pytorch.org/blog/compromised-nightly-dependency/">recent PyTorch incident</a>, occur with multiple package repositories, where a dependency expected to come from one repository (e.g. a custom index) is installed from another (e.g. PyPI). To help address this problem, this PEP proposes extending the <a class="reference external" href="https://packaging.python.org/en/latest/specifications/simple-repository-api/#simple-repository-api" title="(in Python Packaging User Guide)">Simple Repository API</a> to allow repository operators to indicate that a project found on their repository “tracks” a project on different repositories, and allows projects to extend their namespaces across multiple repositories. These features will allow installers to determine when a project being made available from a particular mix of repositories is expected and should be allowed, and when it is not and should halt the install with an error to protect the user. </section> <section id="motivation"> <h2><a class="toc-backref" href="#motivation" role="doc-backlink">Motivation</a></h2> There is a long-standing class of attacks that are called “dependency confusion” attacks, which roughly boil down to an individual user expected to get package <code class="docutils literal notranslate">A</code>, but instead they got <code class="docutils literal notranslate">B</code>. In Python, this almost always happens due to the configuration of multiple repositories (possibly including the default of PyPI), where they expected package <code class="docutils literal notranslate">A</code> to come from repository <code class="docutils literal notranslate">X</code>, but someone is able to publish package <code class="docutils literal notranslate">B</code> to repository <code class="docutils literal notranslate">Y</code> under the same name. Dependency Confusion attacks have long been possible, but they’ve recently gained press with <a class="reference external" href="https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610">public examples of cases where these attacks were successfully executed</a>. A specific example of this is the recent case where the PyTorch project had an internal package named <code class="docutils literal notranslate">torchtriton</code> which was only ever intended to be installed from their repositories located at <code class="docutils literal notranslate">https://download.pytorch.org/</code>, but that repository was designed to be used in conjunction with PyPI, and the name of <code class="docutils literal notranslate">torchtriton</code> was not claimed on PyPI, which allowed the attacker to use that name and publish a malicious version. There are a number of ways to mitigate against these attacks today, but they all require that the end user go out of their way to protect themselves, rather than being protected by default. This means that for the vast bulk of users, they are likely to remain vulnerable, even if they are ultimately aware of these types of attacks. Ultimately the underlying cause of these attacks come from the fact that there is no globally unique namespace that all Python package names come from. Instead, each repository is its own distinct namespace, and when given an “abstract” name such as <code class="docutils literal notranslate">spam</code> to install, an installer has to implicitly turn that into a “concrete” name such as <code class="docutils literal notranslate">pypi.org:spam</code> or <code class="docutils literal notranslate">example.com:spam</code>. Currently the standard behavior in Python installation tools is to implicitly flatten these multiple namespaces into one that contains the files from all namespaces. This assumption that collapsing the namespaces is what was expected means that when packages with the same name in different repositories are authored by different parties (such as in the <code class="docutils literal notranslate">torchtriton</code> case) dependency confusion attacks become possible. This is made particularly tricky in that there is no “right” answer; there are valid use cases both for wanting two repositories merged into one namespace and for wanting two repositories to be treated as distinct namespaces. This means that an installer needs some mechanism by which to determine when it should merge the namespaces of multiple repositories and when it should not, rather than a blanket always merge or never merge rule. This functionality could be pushed directly to the end user, since ultimately the end user is the person whose expectations of what gets installed from what repository actually matters. However, by extending the repository specification to allow a repository to indicate when it is safe, we can enable individual projects and repositories to “work by default”, even when their project naturally spans multiple distinct namespaces, while maintaining the ability for an installer to be secure by default. On its own, this PEP does not solve dependency confusion attacks, but what it does do is provide enough information so that installers can prevent them without causing too much collateral damage to otherwise valid and safe use cases. </section> <section id="rationale"> <h2><a class="toc-backref" href="#rationale" role="doc-backlink">Rationale</a></h2> There are two broad use cases for merging names across repositories that this PEP seeks to enable. The first use case is when one repository is not defining its own names, but rather is extending names defined in other repositories. This commonly happens in cases where a project is being mirrored from one repository to another (see <a class="reference external" href="https://pypi.org/project/bandersnatch/">Bandersnatch</a>) or when a repository is providing supplementary artifacts for a specific platform (see <a class="reference external" href="https://www.piwheels.org/">Piwheels</a>). In this case neither the repositories nor the projects that are being extended may have any knowledge that they are being extended or by whom, so this cannot rely on any information that isn’t present in the “extending” repository itself. The second use case is when the project wants to publish to one “main” repository, but then have additional repositories that provide binaries for additional platforms, GPUs, CPUs, etc. Currently wheel tags are not sufficiently able to express these types of binary compatibility, so projects that wish to rely on them are forced to set up multiple repositories and have their users manually configure them to get the correct binaries for their platform, GPU, CPU, etc. This use case is similar to the first, but the important difference that makes it a distinct use case on its own is who is providing the information and what their level of trust is. When a user configures a specific repository (or relies on the default) there is no ambiguity as to what repository they mean. A repository is identified by an URL, and through the domain system, URLs are globally unique identifiers. This lack of ambiguity means that an installer can assume that the repository operator is trustworthy and can trust metadata that they provide without needing to validate it. On the flip side, given an installer finds a name in multiple repositories it is ambiguous which of them the installer should trust. This ambiguity means that an installer cannot assume that the project owner on either repository is trustworthy and needs to validate that they are indeed the same project and that one isn’t a dependency confusion attack. Without some way for the installer to validate the metadata between multiple repositories, projects would be forced into becoming repository operators to safely support this use case. That wouldn’t be a particularly wrong choice to make; however, there is a danger that if we don’t provide a way for repositories to let project owners express this relationship safely, they will be incentivized to let them use the repository operator’s metadata instead which would reintroduce the original insecurity. </section> <section id="specification"> <h2><a class="toc-backref" href="#specification" role="doc-backlink">Specification</a></h2> This specification defines the changes in version 1.2 of the simple repository API, adding new two new metadata items: Repository “Tracks” and “Alternate Locations”. <section id="repository-tracks-metadata"> <h3><a class="toc-backref" href="#repository-tracks-metadata" role="doc-backlink">Repository “Tracks” Metadata</a></h3> To enable one repository to host a project that is intended to “extend” a project that is hosted at other repositories, this PEP allows the extending repository to declare that a particular project “tracks” a project at another repository or repositories by adding the URLs of the project and repositories that it is extending. This is exposed in JSON as the key <code class="docutils literal notranslate">meta.tracks</code> and in HTML as a meta element named <code class="docutils literal notranslate">pypi:tracks</code> on the project specific URLs, (<code class="docutils literal notranslate">$root/$project/</code>). There are a few key properties that MUST be preserved when using this metadata: <ul class="simple"> <li>It MUST be under the control of the repository operators themselves, not any individual publisher using that repository.<ul> <li>“Repository Operator” can also include anyone who managed the overall namespace for a particular repository, which may be the case in situations like hosted repository services where one entity operates the software but another owns/manages the entire namespace of that repository.</li> </ul> </li> <li>All URLs MUST represent the same “project” as the project in the extending repository.<ul> <li>This does not mean that they need to serve the same files. It is valid for them to include binaries built on different platforms, copies with local patches being applied, etc. This is purposefully left vague as it’s ultimately up to the expectations that the users have of the repository and its operators what exactly constitutes the “same” project.</li> </ul> </li> <li>It MUST point to the repositories that “own” the namespaces, not another repository that is also tracking that namespace.</li> <li>It MUST point to a project with the exact same name (after normalization).</li> <li>It MUST point to the actual URLs for that project, not the base URL for the extended repositories.</li> </ul> It is NOT required that every name in a repository tracks the same repository, or that they all track a repository at all. Mixed use repositories where some names track a repository and some names do not are explicitly allowed. <section id="json"> <h4><a class="toc-backref" href="#json" role="doc-backlink">JSON</a></h4> <div class="highlight-JSON notranslate"><div class="highlight"><pre>{ "meta": { "api-version": "1.2", "tracks": ["https://pypi.org/simple/holygrail/", "https://test.pypi.org/simple/holygrail/"] }, "name": "holygrail", "files": [ { "filename": "holygrail-1.0.tar.gz", "url": "https://example.com/files/holygrail-1.0.tar.gz", "hashes": {"sha256": "...", "blake2b": "..."}, "requires-python": ">=3.7", "yanked": "Had a vulnerability" }, { "filename": "holygrail-1.0-py3-none-any.whl", "url": "https://example.com/files/holygrail-1.0-py3-none-any.whl", "hashes": {"sha256": "...", "blake2b": "..."}, "requires-python": ">=3.7", "dist-info-metadata": true } ] } </pre></div> </div> </section> <section id="html"> <h4><a class="toc-backref" href="#html" role="doc-backlink">HTML</a></h4> <div class="highlight-HTML notranslate"><div class="highlight"><pre><!DOCTYPE html> <html> <head> <meta name="pypi:repository-version" content="1.2"> <meta name="pypi:tracks" content="https://pypi.org/simple/holygrail/"> <meta name="pypi:tracks" content="https://test.pypi.org/simple/holygrail/"> </head> <body> <a href="https://example.com/files/holygrail-1.0.tar.gz#sha256=..."> <a href="https://example.com/files/holygrail-1.0-py3-none-any.whl#sha256=..."> </body> </html> </pre></div> </div> </section> </section> <section id="alternate-locations-metadata"> <h3><a class="toc-backref" href="#alternate-locations-metadata" role="doc-backlink">“Alternate Locations” Metadata</a></h3> To enable a project to extend its namespace across multiple repositories, this PEP allows a project owner to declare a list of “alternate locations” for their project. This is exposed in JSON as the key <code class="docutils literal notranslate">alternate-locations</code> and in HTML as a meta element named <code class="docutils literal notranslate">pypi-alternate-locations</code>, which may be used multiple times. There are a few key properties that MUST be observed when using this metadata: <ul class="simple"> <li>In order for this metadata to be trusted, there MUST be agreement between all locations where that project is found as to what the alternate locations are.</li> <li>When using alternate locations, clients MUST implicitly assume that the url the response was fetched from was included in the list. This means that if you fetch from <code class="docutils literal notranslate">https://pypi.org/simple/foo/</code> and it has an <code class="docutils literal notranslate">alternate-locations</code> metadata that has the value <code class="docutils literal notranslate">["https://example.com/simple/foo/"]</code>, then you MUST treat it as if it had the value <code class="docutils literal notranslate">["https://example.com/simple/foo/", "https://pypi.org/simple/foo/"]</code>.</li> <li>Order of the elements within the array does not have any particular meaning.</li> </ul> When an installer encounters a project that is using the alternate locations metadata it SHOULD consider that all repositories named are extending the same namespace across multiple repositories. <div class="admonition note"> Note This alternate locations metadata is project level metadata, not artifact level metadata, which means it doesn’t get included as part of the core metadata spec, but rather it is something that each repository will have to provide a configuration option for (if they choose to support it). </div> <section id="id1"> <h4><a class="toc-backref" href="#id1" role="doc-backlink">JSON</a></h4> <div class="highlight-JSON notranslate"><div class="highlight"><pre>{ "meta": { "api-version": "1.2" }, "name": "holygrail", "alternate-locations": ["https://pypi.org/simple/holygrail/", "https://test.pypi.org/simple/holygrail/"], "files": [ { "filename": "holygrail-1.0.tar.gz", "url": "https://example.com/files/holygrail-1.0.tar.gz", "hashes": {"sha256": "...", "blake2b": "..."}, "requires-python": ">=3.7", "yanked": "Had a vulnerability" }, { "filename": "holygrail-1.0-py3-none-any.whl", "url": "https://example.com/files/holygrail-1.0-py3-none-any.whl", "hashes": {"sha256": "...", "blake2b": "..."}, "requires-python": ">=3.7", "dist-info-metadata": true } ] } </pre></div> </div> </section> <section id="id2"> <h4><a class="toc-backref" href="#id2" role="doc-backlink">HTML</a></h4> <div class="highlight-HTML notranslate"><div class="highlight"><pre><!DOCTYPE html> <html> <head> <meta name="pypi:repository-version" content="1.2"> <meta name="pypi:alternate-locations" content="https://pypi.org/simple/holygrail/"> <meta name="pypi:alternate-locations" content="https://test.pypi.org/simple/holygrail/"> </head> <body> <a href="https://example.com/files/holygrail-1.0.tar.gz#sha256=..."> <a href="https://example.com/files/holygrail-1.0-py3-none-any.whl#sha256=..."> </body> </html> </pre></div> </div> </section> </section> </section> <section id="recommendations"> <h2><a class="toc-backref" href="#recommendations" role="doc-backlink">Recommendations</a></h2> This section is non-normative; it provides recommendations to installers in how to interpret this metadata that this PEP feels provides the best tradeoff between protecting users by default and minimizing breakages to existing workflows. These recommendations are not binding, and installers are free to ignore them, or apply them selectively as they make sense in their specific situations. <section id="file-discovery-algorithm"> <h3><a class="toc-backref" href="#file-discovery-algorithm" role="doc-backlink">File Discovery Algorithm</a></h3> <div class="admonition note"> Note This algorithm is written based on how pip currently discovers files; other installers may adapt this based on their own discovery procedures. </div> Currently the “standard” file discovery algorithm looks something like this: <ol class="arabic simple"> <li>Generate a list of all files across all configured repositories.</li> <li>Filter out any files that do not match known hashes from a lockfile or requirements file.</li> <li>Filter out any files that do not match the current platform, Python version, etc.</li> <li>Pass that list of files into the resolver where it will attempt to resolve the “best” match out of those files, irrespective of which repository it came from.</li> </ol> It is recommended that installers change their file discovery algorithm to take into account the new metadata, and instead do: <ol class="arabic simple"> <li>Generate a list of all files across all configured repositories.</li> <li>Filter out any files that do not match known hashes from a lockfile or requirements file.</li> <li>If the end user has explicitly told the installer to fetch the project from specific repositories, filter out all other repositories and skip to 5.</li> <li>Look to see if the discovered files span multiple repositories; if they do then determine if either “Tracks” or “Alternate Locations” metadata allows safely merging ALL of the repositories where files were discovered together. If that metadata does NOT allow that, then generate an error, otherwise continue.<ul class="simple"> <li>Note: This only applies to remote repositories; repositories that exist on the local filesystem SHOULD always be implicitly allowed to be merged to any remote repository.</li> </ul> </li> <li>Filter out any files that do not match the current platform, Python version, etc.</li> <li>Pass that list of files into the resolver where it will attempt to resolve the “best” match out of those files, irrespective of what repository it came from.</li> </ol> This is somewhat subtle, but the key things in the recommendation are: <ul class="simple"> <li>Users who are using lock files or requirements files that include specific hashes of artifacts that are “valid” are assumed to be protected by nature of those hashes, since the rest of these recommendations would apply during hash generation. Thus, we filter out unknown hashes up front.</li> <li>If the user has explicitly told the installer that it wants to fetch a project from a certain set of repositories, then there is no reason to question that and we assume that they’ve made sure it is safe to merge those namespaces.</li> <li>If the project in question only comes from a single repository, then there is no chance of dependency confusion, so there’s no reason to do anything but allow.</li> <li>We check for the metadata in this PEP before filtering out based on platform, Python version, etc., because we don’t want errors that only show up on certain platforms, Python versions, etc.</li> <li>If nothing tells us merging the namespaces is safe, we refuse to implicitly assume it is, and generate an error instead.</li> <li>Otherwise we merge the namespaces, and continue on.</li> </ul> This algorithm ensures that an installer never assumes that two disparate namespaces can be flattened into one, which for all practical purposes eliminates the possibility of any kind of dependency confusion attack, while still giving power throughout the stack in a safe way to allow people to explicitly declare when those disparate namespaces are actually one logical namespace that can be safely merged. The above algorithm is mostly a conceptual model. In reality the algorithm may end up being slightly different in order to be more privacy preserving and faster, or even just adapted to fit a specific installer better. </section> <section id="explicit-configuration-for-end-users"> <h3><a class="toc-backref" href="#explicit-configuration-for-end-users" role="doc-backlink">Explicit Configuration for End Users</a></h3> This PEP avoids dictating or recommending a specific mechanism by which an installer allows an end user to configure exactly what repositories they want a specific package to be installed from. However, it does recommend that installers do provide some mechanism for end users to provide that configuration, as without it users can end up in a DoS situation in cases like <code class="docutils literal notranslate">torchtriton</code> where they’re just completely broken unless they resolve the namespace collision externally (get the name taken down on one repository, stand up a personal repository that handles the merging, etc). This configuration also allows end users to pre-emptively secure themselves during what is likely to be a long transition until the default behavior is safe. </section> </section> <section id="how-to-communicate-this"> <h2><a class="toc-backref" href="#how-to-communicate-this" role="doc-backlink">How to Communicate This</a></h2> <div class="admonition note"> Note This example is pip specific and assumes specifics about how pip will choose to implement this PEP; it’s included as an example of how we can communicate this change, and not intended to constrain pip or any other installer in how they implement this. This may ultimately be the actual basis for communication, and if so will need be edited for accuracy and clarity. This section should be read as if it were an entire “post” to communicate this change that could be used for a blog post, email, or discourse post. </div> There’s a long-standing class of attacks that are called “dependency confusion” attacks, which roughly boil down to an individual expected to get package <code class="docutils literal notranslate">A</code>, but instead they got <code class="docutils literal notranslate">B</code>. In Python, this almost always happens due to the end user having configured multiple repositories, where they expect package <code class="docutils literal notranslate">A</code> to come from repository <code class="docutils literal notranslate">X</code>, but someone is able to publish package <code class="docutils literal notranslate">B</code> with the same name as package <code class="docutils literal notranslate">A</code> in repository <code class="docutils literal notranslate">Y</code>. There are a number of ways to mitigate against these attacks today, but they all require that the end user explicitly go out of their way to protect themselves, rather than it being inherently safe. In an effort to secure pip’s users and protect them from these types of attacks, we will be changing how pip discovers packages to install. <section id="what-is-changing"> <h3><a class="toc-backref" href="#what-is-changing" role="doc-backlink">What is Changing?</a></h3> When pip discovers that the same project is available from multiple remote repositories, by default it will generate an error and refuse to proceed rather than make a guess about which repository was the correct one to install from. Projects that natively publish to multiple repositories will be given the ability to safely “link” their repositories together so that pip does not error when those repositories are used together. End users of pip will be given the ability to explicitly define one or more repositories that are valid for a specific project, causing pip to only consider those repositories for that project, and avoiding generating an error altogether. See TBD for more information. </section> <section id="who-is-affected"> <h3><a class="toc-backref" href="#who-is-affected" role="doc-backlink">Who is Affected?</a></h3> Users who are installing from multiple remote (e.g. not present on the local filesystem) repositories may be affected by having pip error instead of successfully install if: <ul class="simple"> <li>They install a project where the same “name” is being served by multiple remote repositories.</li> <li>The project name that is available from multiple remote repositories has not used one of the defined mechanisms to link those repositories together.</li> <li>The user invoking pip has not used the defined mechanism to explicitly control what repositories are valid for a particular project.</li> </ul> Users who are not using multiple remote repositories will not be affected at all, which includes users who are only using a single remote repository, plus a local filesystem “wheel house”. </section> <section id="what-do-i-need-to-do"> <h3><a class="toc-backref" href="#what-do-i-need-to-do" role="doc-backlink">What do I need to do?</a></h3> <section id="as-a-pip-user"> <h4><a class="toc-backref" href="#as-a-pip-user" role="doc-backlink">As a pip User?</a></h4> If you’re using only a single remote repository you do not have to do anything. If you’re using multiple remote repositories, you can opt into the new behavior by adding <code class="docutils literal notranslate">--use-feature=TBD</code> to your pip invocation to see if any of your dependencies are being served from multiple remote repositories. If they are, you should audit them to determine why they are, and what the best remediation step will be for you. Once this behavior becomes the default, you can opt out of it temporarily by adding <code class="docutils literal notranslate">--use-deprecated=TBD</code> to your pip invocation. If you’re using projects that are not hosted on a public repository, but you still have the public repository as a fallback, consider configuring pip with a repository file to be explicit where that dependency is meant to come from to prevent registration of that name in a public repository to cause pip to error for you. </section> <section id="as-a-project-owner"> <h4><a class="toc-backref" href="#as-a-project-owner" role="doc-backlink">As a Project Owner?</a></h4> If you only publish your project to a single repository, then you do not have to do anything. If you publish your project to multiple repositories that are intended to be used together at the same time, configure all repositories to serve the alternate repository metadata to prevent breakages for your end users. If you publish your project to a single repository, but it is commonly used in conjunction with other repositories, consider preemptively registering your names with those repositories to prevent a third party from being able to cause your users <code class="docutils literal notranslate">pip install</code> invocations to start failing. This may not be available if your project name is too generic or if the repositories have policies that prevent defensive name squatting. </section> <section id="as-a-repository-operator"> <h4><a class="toc-backref" href="#as-a-repository-operator" role="doc-backlink">As a Repository Operator?</a></h4> You’ll need to decide how you intend for your repository to be used by your end users and how you want them to use it. For private repositories that host private projects, it is recommended that you mirror the public projects that your users depend on into your own repository, taking care not to let a public project merge with a private project, and tell your users to use the <code class="docutils literal notranslate">--index-url</code> option to use only your repository. For public repositories that host public projects, you should implement the alternate repository mechanism and enable the owners of those projects to configure the list of repositories that their project is available from if they make it available from more than one repository. For public repositories that “track” another repository, but provide supplemental artifacts such as wheels built for a specific platform, you should implement the “tracks” metadata for your repository. However, this information MUST NOT be settable by end users who are publishing projects to your repository. See TBD for more information. </section> </section> </section> <section id="rejected-ideas"> <h2><a class="toc-backref" href="#rejected-ideas" role="doc-backlink">Rejected Ideas</a></h2> Note: Some of these are somewhat specific to pip, but any solution that doesn’t work for pip isn’t a particularly useful solution. <section id="implicitly-allow-mirrors-when-the-list-of-files-are-the-same"> <h3><a class="toc-backref" href="#implicitly-allow-mirrors-when-the-list-of-files-are-the-same" role="doc-backlink">Implicitly allow mirrors when the list of files are the same</a></h3> If every repository returns the exact same list of files, then it is safe to consider those repositories to be the same namespace and implicitly merge them. This would possibly mean that mirrors would be automatically allowed without any work on any user or repository operator’s part. Unfortunately, this has two failings that make it undesirable: <ul class="simple"> <li>It only solves the case of mirrors that are exact copies of each other, but not repositories that “track” another one, which ends up being a more generic solution.</li> <li>Even in the case of exact mirrors, multiple repositories mirroring each other is a distributed system will not always be fully consistent with each other, effectively an eventually consistent system. This means that repositories that relied on this implicit heuristic to work would have sporadic failures due to drift between the source repository and the mirror repositories.</li> </ul> </section> <section id="provide-a-mechanism-to-order-the-repositories"> <h3><a class="toc-backref" href="#provide-a-mechanism-to-order-the-repositories" role="doc-backlink">Provide a mechanism to order the repositories</a></h3> Providing some mechanism to give the repositories an order, and then short circuiting the discovery algorithm when it finds the first repository that provides files for that project is another workable solution that is safe if the order is specified correctly. However, this has been rejected for a number of reasons: <ul class="simple"> <li>We’ve spent 15+ years educating users that the ordering of repositories being specified is not meaningful, and they effectively have an undefined order. It would be difficult to backpedal on that and start saying that now order matters.</li> <li>Users can easily rearrange the order that they specify their repositories in within a single location, but when loading repositories from multiple locations (env var, conf file, requirements file, cli arguments) the order is hard coded into pip. While it would be a deterministic and documented order, there’s no reason to assume it’s the order that the user wants their repositories to be defined in, forcing them to contort how they configure pip so that the implicit ordering ends up being the correct one.</li> <li>The above can be mitigated by providing a way to explicitly declare the order rather than by implicitly using the order they were defined in; however, that then means that the protections are not provided unless the user does some explicit configuration.</li> <li>Ordering assumes that one repository is always preferred over another repository without any way to decide on a project by project basis.</li> <li>Relying on ordering is subtle; if I look at an ordering of repositories, I have no way of knowing or ensuring in advance what names are going to come from what repositories. I can only know in that moment what names are provided by which repositories.</li> <li>Relying on ordering is fragile. There’s no reason to assume that two disparate repositories are not going to have random naming collisions—what happens if I’m using a library from a lower priority repository and then a higher priority repository happens to start having a colliding name?</li> <li>In cases where ordering does the wrong thing, it does so silently, with no feedback given to the user. This is by design because it doesn’t actually know what the wrong or right thing is, it’s just hoping that order will give the right thing, and if it does then users are protected without any breakage. However, when it does the wrong thing, users are left with a very confusing behavior coming from pip, where it’s just silently installing the wrong thing.</li> </ul> There is a variant of this idea which effectively says that it’s really just PyPI’s nature of open registration that causes the real problems, so if we treat all repositories but the “default” one as equal priority, and then treat the default one as a lower priority then we’ll fix things. That is true in that it does improve things, but it has many of the same problems as the general ordering idea (though not all of them). It also assumes that PyPI, or whatever repository is configured as the “default”, is the only repository with open registration of names. However, projects like <a class="reference external" href="https://www.piwheels.org/">Piwheels</a> exist which users are expected to use in addition to PyPI, which also effectively have open registration of names since it tracks whatever names are registered on PyPI. </section> <section id="rely-on-repository-proxies"> <h3><a class="toc-backref" href="#rely-on-repository-proxies" role="doc-backlink">Rely on repository proxies</a></h3> One possible solution is to instead of having the installer have to solve this, to instead depend on repository proxies that can intelligently merge multiple repositories safely. This could provide a better experience for people with complex needs because they can have configuration and features that are dedicated to the problem space. However, that has been rejected because: <ul class="simple"> <li>It requires users to opt into using them, unless we also remove the facilities to have more than one repository in installers to force users into using a repository proxy when they need multiple repositories.<ul> <li>Removing facilities to have more than one repository configured has been rejected because it would be too disruptive to end users.</li> </ul> </li> <li>A user may need different outcomes of merging multiple repositories in different contexts, or may need to merge different, mutually exclusive repositories. This means they’ll need to actually set up multiple repository proxies for each unique set of options.</li> <li>It requires users to maintain infrastructure or it requires adding features in installers to automatically spin up a repository for each invocation.</li> <li>It doesn’t actually change the requirement to need to have a solution to these problems, it just shifts the responsibility of implementation from installers to some repository proxy, but in either case we still need something that figures out how to merge these disparate namespaces.</li> <li>Ultimately, most users do not want to have to stand up a repository proxy just to safely interact with multiple repositories.</li> </ul> </section> <section id="rely-only-on-hash-checking"> <h3><a class="toc-backref" href="#rely-only-on-hash-checking" role="doc-backlink">Rely only on hash checking</a></h3> Another possible solution is to rely on hash checking, since with hash checking enabled users cannot get an artifact that they didn’t expect; it doesn’t matter if the namespaces are incorrectly merged or not. This is certainly a solution; unfortunately it also suffers from problems that make it unworkable: <ul class="simple"> <li>It requires users to opt in to it, so users are still unprotected by default.</li> <li>It requires users to do a bunch of labor to manage their hashes, which is something that most users are unlikely to be willing to do.</li> <li>It is difficult and verbose to get the protection when users are not using a <code class="docutils literal notranslate">requirements.txt</code> file as the source of their dependencies (this affects build time dependencies, and dependencies provided at the command line).</li> <li>It only sort of solves the problem, in a way it just shifts the responsibility of the problem to be whatever system is generating the hashes that the installer would use. If that system isn’t a human manually validating hashes, which it’s unlikely it would be, then we’ve just shifted the question of how to merge these namespaces to whatever tool implements the maintenance of the hashes.</li> </ul> </section> <section id="require-all-projects-to-exist-in-the-default-repository"> <h3><a class="toc-backref" href="#require-all-projects-to-exist-in-the-default-repository" role="doc-backlink">Require all projects to exist in the “default” repository</a></h3> Another idea is that we can narrow the scope of <code class="docutils literal notranslate">--extra-index-url</code> such that its only supported use is to refer to supplemental repositories to the default repository, effectively saying that the default repository defines the namespace, and every additional repository just extends it with extra packages. The implementation of this would roughly be to require that the project MUST be registered with the default repository in order for any additional repositories to work. This sort of works if you successfully narrow the scope in that way, but ultimately it has been rejected because: <ul class="simple"> <li>Users are unlikely to understand or accept this reduced scope, and thus are likely to attempt to continue to use it in the now unsupported fashion.<ul> <li>This is complicated by the fact that with the scope now narrowed, users who have the excluded workflow no longer have any alternative besides setting up a repository proxy, which takes infrastructure and effort that they previously didn’t have to do.</li> </ul> </li> <li>It assumes that just because a name in an “extra” repository is the same as in the default repository, that they are the same project. If we were starting from scratch in a brand new ecosystem then maybe we could make this assumption from the start and make it stick, but it’s going to be incredibly difficult to get the ecosystem to adjust to that change.<ul> <li>This is a fundamental issue with this approach; the underlying problem that drives dependency confusion is that we’re taking disparate namespaces and flattening them into one. This approach essentially just declares that OK, and attempts to mitigate it by requiring everyone to register their names.</li> </ul> </li> <li>Because of the above assumption, in cases where a name in an extra repository collides by accident with the default repository, it’s going to appear to work for those users, but they are going to be silently in a state of dependency confusion.<ul> <li>This is made worse by the fact that the person who owns the name that is allowing this to work is going to be completely unaware of the role that they’re playing for that user, and might possibly delete their project or hand it off to someone else, potentially allowing them to inadvertently allow a malicious user to take it over.</li> </ul> </li> <li>Users are likely to attempt to get back to a working state by registering their names in their default repository as a defensive name squat. Their ability to do this will depend on the specific policies of their default repository, whether someone already has that name, whether it’s too generic, etc. As a best case scenario it will cause needless placeholder projects that serve no purpose other than to secure some internal use of a name.</li> </ul> </section> <section id="move-to-globally-unique-names"> <h3><a class="toc-backref" href="#move-to-globally-unique-names" role="doc-backlink">Move to Globally Unique Names</a></h3> The main reason this problem exists is that we don’t have globally unique names, we have locally unique names that exist under multiple namespaces that we are attempting to merge into a single flat namespace. If we could instead come up with a way to have globally unique names, we could sidestep the entire issue. This idea has been rejected because: <ul class="simple"> <li>Generating globally unique but secure names that are also meaningful to humans is a nearly impossible feat without piggybacking off of some kind of centralized database. To my knowledge the only systems that have managed to do this end up piggybacking off of the domain system and refer to packages by URLs with domains etc.</li> <li>Even if we come up with a mechanism to get globally unique names, our ability to retrofit that into our decades old system is practically zero without burning it all to the ground and starting over. The best we could probably do is declare that all non globally unique names are implicitly names on the PyPI domain name, and force everyone with a non PyPI package to rename their package.</li> <li>This would upend so many core assumptions and fundamental parts of our current system it’s hard to even know where to start to list them.</li> </ul> </section> <section id="only-recommend-that-installers-offer-explicit-configuration"> <h3><a class="toc-backref" href="#only-recommend-that-installers-offer-explicit-configuration" role="doc-backlink">Only recommend that installers offer explicit configuration</a></h3> One idea that has come up is to essentially just implement the explicit configuration and don’t make any other changes to anything else. The specific proposal for a mapping policy is what actually inspired the explicit configuration option, and created a file that looked something like: <div class="highlight-JSON notranslate"><div class="highlight"><pre>{ "repositories": { "PyTorch": ["https://download.pytorch.org/whl/nightly"], "PyPI": ["https://pypi.org/simple"] }, "mapping": [ { "paths": ["torch*"], "repositories": ["PyTorch"], "terminating": true }, { "paths": ["*"], "repositories": ["PyPI"] } ] } </pre></div> </div> The recommendation to have explicit configuration pushes the decision on how to implement that onto each installer, allowing them to choose what works best for their users. Ultimately only implementing some kind of explicit configuration was rejected because by its nature it’s opt in, so it doesn’t protect average users who are least capable to solve the problem with the existing tools; by adding additional protections alongside the explicit configuration, we are able to protect all users by default. Additionally, relying on only explicit configuration also means that every end user has to resolve the same problem over and over again, even in cases like mirrors of PyPI, Piwheels, PyTorch, etc. In each and every case they have to sit there and make decisions (or find some example to cargo cult) in order to be secure. Adding extra features into the mix allows us to centralize those protections where we can, while still giving advanced end users the ability to completely control their own destiny. </section> <section id="scopes-a-la-npm"> <h3><a class="toc-backref" href="#scopes-a-la-npm" role="doc-backlink">Scopes à la npm</a></h3> There’s been some suggestion that <a class="reference external" href="https://docs.npmjs.com/cli/v9/using-npm/scope">scopes similar to how npm has implemented them</a> may ultimately solve this. Ultimately scopes do not change anything about this problem. As far as I know scopes in npm are not globally unique, they’re tied to a specific registry just like unscoped names are. However what scopes do enable is an obvious mechanism for grouping related projects and the ability for a user or organization on npm.org to claim an entire scope, which makes explicit configuration significantly easier to handle because you can be assured that there’s a whole little slice of the namespace that wholly belongs to you, and you can easily write a rule that assigns an entire scope to a specific non public registry. Unfortunately, it basically ends up being an easier version of the idea to only use explicit configuration, which works ok in npm because its not particularly common for people to use their own registries, but in Python we encourage you to do just that. </section> <section id="define-and-standardize-the-explicit-configuration"> <h3><a class="toc-backref" href="#define-and-standardize-the-explicit-configuration" role="doc-backlink">Define and Standardize the “Explicit Configuration”</a></h3> This PEP recommends installers to have a mechanism for explicit configuration of which repository a particular project comes from, but it does not define what that mechanism is. We are purposefully leave that undefined, as it is closely tied to the UX of each individual installer and we want to allow each individual installer the ability to expose that configuration in whatever way that they see fit for their particular use cases. Further, when the idea of defining that mechanism came up, none of the other installers seemed particularly interested in having that mechanism defined for them, suggesting that they were happy to treat that as part of their UX. Finally, that mechanism, if we did choose to define it, deserves it’s own PEP rather than baking it as part of the changes to the repository API in this PEP and it can be a future PEP if we ultimately decide we do want to go down the path of standardization for it. </section> </section> <section id="acknowledgements"> <h2><a class="toc-backref" href="#acknowledgements" role="doc-backlink">Acknowledgements</a></h2> Thanks to Trishank Kuppusamy for kick starting the discussion that lead to this PEP with his <a class="reference external" href="https://discuss.python.org/t/proposal-preventing-dependency-confusion-attacks-with-the-map-file/23414">proposal</a>. Thanks to Paul Moore, Pradyun Gedam, Steve Dower, and Trishank Kuppusamy for providing early feedback and discussion on the ideas in this PEP. Thanks to Jelle Zijlstra, C.A.M. Gerlach, Hugo van Kemenade, and Stefano Rivera for copy editing and improving the structure and quality of this PEP. </section> <section id="copyright"> <h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2> This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. </section> </section> <hr class="docutils" /> Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0708.rst">https://github.com/python/peps/blob/main/peps/pep-0708.rst</a> Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0708.rst">2024-08-17 01:15:14 GMT</a> </article> <nav id="pep-sidebar"> <h2>Contents</h2> <ul> <li><a class="reference internal" href="#provisional-acceptance">Provisional Acceptance</a></li> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#motivation">Motivation</a></li> <li><a class="reference internal" href="#rationale">Rationale</a></li> <li><a class="reference internal" href="#specification">Specification</a><ul> <li><a class="reference internal" href="#repository-tracks-metadata">Repository “Tracks” Metadata</a><ul> <li><a class="reference internal" href="#json">JSON</a></li> <li><a class="reference internal" href="#html">HTML</a></li> </ul> </li> <li><a class="reference internal" href="#alternate-locations-metadata">“Alternate Locations” Metadata</a><ul> <li><a class="reference internal" href="#id1">JSON</a></li> <li><a class="reference internal" href="#id2">HTML</a></li> </ul> </li> </ul> </li> <li><a class="reference internal" href="#recommendations">Recommendations</a><ul> <li><a class="reference internal" href="#file-discovery-algorithm">File Discovery Algorithm</a></li> <li><a class="reference internal" href="#explicit-configuration-for-end-users">Explicit Configuration for End Users</a></li> </ul> </li> <li><a class="reference internal" href="#how-to-communicate-this">How to Communicate This</a><ul> <li><a class="reference internal" href="#what-is-changing">What is Changing?</a></li> <li><a class="reference internal" href="#who-is-affected">Who is Affected?</a></li> <li><a class="reference internal" href="#what-do-i-need-to-do">What do I need to do?</a><ul> <li><a class="reference internal" href="#as-a-pip-user">As a pip User?</a></li> <li><a class="reference internal" href="#as-a-project-owner">As a Project Owner?</a></li> <li><a class="reference internal" href="#as-a-repository-operator">As a Repository Operator?</a></li> </ul> </li> </ul> </li> <li><a class="reference internal" href="#rejected-ideas">Rejected Ideas</a><ul> <li><a class="reference internal" href="#implicitly-allow-mirrors-when-the-list-of-files-are-the-same">Implicitly allow mirrors when the list of files are the same</a></li> <li><a class="reference internal" href="#provide-a-mechanism-to-order-the-repositories">Provide a mechanism to order the repositories</a></li> <li><a class="reference internal" href="#rely-on-repository-proxies">Rely on repository proxies</a></li> <li><a class="reference internal" href="#rely-only-on-hash-checking">Rely only on hash checking</a></li> <li><a class="reference internal" href="#require-all-projects-to-exist-in-the-default-repository">Require all projects to exist in the “default” repository</a></li> <li><a class="reference internal" href="#move-to-globally-unique-names">Move to Globally Unique Names</a></li> <li><a class="reference internal" href="#only-recommend-that-installers-offer-explicit-configuration">Only recommend that installers offer explicit configuration</a></li> <li><a class="reference internal" href="#scopes-a-la-npm">Scopes à la npm</a></li> <li><a class="reference internal" href="#define-and-standardize-the-explicit-configuration">Define and Standardize the “Explicit Configuration”</a></li> </ul> </li> <li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> <a id="source" href="https://github.com/python/peps/blob/main/peps/pep-0708.rst">Page Source (GitHub)</a> </nav> </section> <script src="../_static/colour_scheme.js"></script> <script src="../_static/wrap_tables.js"></script> <script src="../_static/sticky_banner.js"></script> </body> </html>