Movatterモバイル変換

[0]ホーム
URL:

Following system colour schemeSelected dark colour schemeSelected light colour scheme

Python Enhancement Proposals

PEP 449 – Removal of the PyPI Mirror Auto Discovery and Naming Scheme

Author:
Donald Stufft <donald at stufft.io>
BDFL-Delegate:
Richard Jones <richard at python.org>
Discussions-To:
Distutils-SIG list
Status:
Final
Type:
Process
Topic:
Packaging
Created:
04-Aug-2013
Post-History:
04-Aug-2013
Replaces:
381
Resolution:
Distutils-SIG message
Table of Contents

Abstract

This PEP provides a path to deprecate and ultimately remove the auto discoveryof PyPI mirrors as well as the hard coded naming scheme which requiresdelegating a domain name under pypi.python.org to a third party.

Rationale

The PyPI mirroring infrastructure (defined inPEP 381) provides a means tomirror the content of PyPI used by the automatic installers. It also providesa method for auto discovery of mirrors and a consistent naming scheme.

There are a number of problems with the auto discovery protocol and thenaming scheme:

  • They give control over a *.python.org domain name to a third party,allowing that third party to set or read cookies on the pypi.python.org andpython.org domain name.
  • The use of a sub domain of pypi.python.org means that the mirror operatorswill never be able to get a SSL certificate of their own, and giving themone for a python.org domain name is unlikely to happen.
  • The auto discovery uses an unauthenticated protocol (DNS).
  • The lack of a TLS certificate on these domains means that clients can notbe sure that they have not been a victim of DNS poisoning or a MITM attack.
  • The auto discovery protocol was designed to enable a client to automaticallyselect a mirror for use. This is no longer a requirement because the CDNthat PyPI is now using a globally distributed network of servers which willautomatically select one close to the client without any effort on theclients part.
  • The auto discovery protocol and use of the consistent naming scheme has onlyever been implemented by one installer (pip), and its implementation, besidesbeing insecure, has serious issues with performance and is slated for removalwith its next release (1.5).
  • While there are provisions inPEP 381 that would solvesome of theseissues for a dedicated client it would not solve the issues that affect ausers browser. Additionally these provisions have not been implemented byany installer to date.

Due to the number of issues, some of them very serious, and the CDN whichprovides most of the benefit of the auto discovery and consistent naming schemethis PEP proposes to first deprecate and then remove the [a..z].pypi.python.orgnames for mirrors and the last.pypi.python.org name for the auto discoveryprotocol. The ability to mirror and the method of mirror will not be affectedand will continue to exist as written inPEP 381. Operators of existingmirrors are encouraged to acquire their own domains and certificates to use fortheir mirrors if they wish to continue hosting them.

Plan for Deprecation & Removal

Immediately upon acceptance of this PEP documentation on PyPI will be updatedto reflect the deprecated nature of the official public mirrors and willdirect users to external resources likehttp://www.pypi-mirrors.org/ todiscover unofficial public mirrors if they wish to use one.

Mirror operators, if they wish to continue operating their mirror, shouldacquire a domain name to represent their mirror and, if they are able, a TLScertificate. Once they have acquired a domain they should redirect theirassigned N.pypi.python.org domain name to their new domain. On Feb 15th, 2014the DNS entries for [a..z].pypi.python.org and last.pypi.python.org will beremoved. At any time prior to Feb 15th, 2014 a mirror operator may requestthat their domain name be reclaimed by PyPI and pointed back at the master.

Why Feb 15th, 2014

The most critical decision of this PEP is the final cut off date. If the dateis too soon then it needlessly punishes people by forcing them to dropeverything to update their deployment scripts. If the date is too far away thenthe extended period of time does not help with the migration effort and merelyputs off the migration until a later date.

The date of Feb 15th, 2014 has been chosen because it is roughly 6 months fromthe date of the PEP. This should ensure a lengthy period of time to enablepeople to update their deployment procedures to point to the new domains nameswithout merely padding the cut off date.

Why the DNS entries must be removed

While it would be possible to simply reclaim the domain names used in mirrorand direct them back at PyPI in order to prevent users from needing to updateconfigurations to point away from those domains this has a number of issues.

  • Anyone who currently has these names hard coded in their configuration hasthem hard coded as HTTP. This means that by allowing these names to continueresolving we make it simple for a MITM operator to attack users by rewritingthe redirect to HTTPS prior to giving it to the client.
  • The overhead of maintaining several domains pointing at PyPI has provedtroublesome for the small number of N.pypi.python.org domains that havealready been reclaimed. They oftentimes get mis-configured when thingschange on the service which often leaves them broken for months at a timeuntil somebody notices. By leaving them in we leave users of these domainsopen to random breakages which are less likely to get caught or noticed.
  • People using these domains have explicitly chosen to use them for one reasonor another. One such reason may be because they do not wish to deploy froma host located in a particular country. If these domains continue to resolvebut do not point at their existing locations we have silently removed thischoice from the existing users of those domains.

That being said, removing the entrieswill require users who have modifiedtheir configuration to either point back at the master (PyPI) or select a newmirror name to point at. This is regarded as a regrettable requirement toprotect PyPI itself and the users of the mirrors from the attacks outlinedabove or, at the very least, require them to make an informed decision aboutthe insecurity.

Public or Private Mirrors

The mirroring protocol will continue to exist as defined inPEP 381 andpeople are encouraged to host public and private mirrors if they so desire.The recommended mirroring client isBandersnatch.

Copyright

This document has been placed in the public domain.

Source:https://github.com/python/peps/blob/main/peps/pep-0449.rst

Last modified:2025-02-01 08:59:27 GMT

[8]ページ先頭
©2009-2025 Movatter.jp