Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python Enhancement Proposals

PEP 449 – Entfernung der automatischen Spiegelentdeckung und des Namensschemas von PyPI

Autor:
Donald Stufft <donald at stufft.io>
BDFL-Delegate:
Richard Jones <richard at python.org>
Discussions-To:
Distutils-SIG Liste
Status:
Final
Typ:
Prozess
Thema:
Packaging
Erstellt:
04-Aug-2013
Post-History:
04-Aug-2013
Ersetzt:
381
Resolution:
Distutils-SIG Nachricht
Inhaltsverzeichnis

Zusammenfassung

Diese PEP bietet einen Weg, die automatische Entdeckung von PyPI-Spiegeln sowie das fest kodierte Namensschema, das die Delegation eines Domainnamens unter pypi.python.org an einen Dritten erfordert, außer Betrieb zu nehmen und schließlich zu entfernen.

Begründung

Die PyPI-Spiegelinfrastruktur (definiert in PEP 381) bietet eine Möglichkeit, den Inhalt von PyPI zu spiegeln, der von den automatischen Installern verwendet wird. Sie bietet auch eine Methode zur automatischen Erkennung von Spiegeln und ein konsistentes Namensschema.

Es gibt eine Reihe von Problemen mit dem automatischen Erkennungsprotokoll und dem Namensschema

  • Sie übertragen die Kontrolle über einen *.python.org Domainnamen an einen Dritten, was es diesem Dritten ermöglicht, Cookies für die Domainnamen pypi.python.org und python.org zu setzen oder zu lesen.
  • Die Verwendung einer Subdomain von pypi.python.org bedeutet, dass die Spiegelbetreiber niemals ein eigenes SSL-Zertifikat erhalten können, und es ist unwahrscheinlich, dass ihnen eines für einen python.org Domainnamen zur Verfügung gestellt wird.
  • Die automatische Erkennung verwendet ein nicht authentifiziertes Protokoll (DNS).
  • Das Fehlen eines TLS-Zertifikats für diese Domains bedeutet, dass Clients nicht sicher sein können, dass sie nicht Opfer von DNS-Spoofing oder einem MITM-Angriff geworden sind.
  • Das automatische Erkennungsprotokoll wurde entwickelt, um es einem Client zu ermöglichen, automatisch einen Spiegel auszuwählen. Dies ist keine Anforderung mehr, da das CDN, das PyPI jetzt verwendet, ein global verteiltes Netzwerk von Servern ist, das automatisch einen Server in Kundennähe auswählt, ohne dass dies für den Client Aufwand erfordert.
  • Das automatische Erkennungsprotokoll und die Verwendung des konsistenten Namensschemas wurden bisher nur von einem Installer (pip) implementiert, und seine Implementierung ist abgesehen von der Unsicherheit mit ernsthaften Leistungsproblemen behaftet und soll mit der nächsten Version (1.5) entfernt werden.
  • Während es in PEP 381 Bestimmungen gibt, die *einige* dieser Probleme für einen dedizierten Client lösen würden, würden sie nicht die Probleme lösen, die den Browser eines Benutzers betreffen. Darüber hinaus wurden diese Bestimmungen bisher von keinem Installer implementiert.

Aufgrund der Anzahl der Probleme, von denen einige sehr schwerwiegend sind, und des CDNs, das den Großteil des Nutzens der automatischen Erkennung und des konsistenten Namensschemas bietet, schlägt diese PEP vor, zuerst die Namen [a..z].pypi.python.org für Spiegel und last.pypi.python.org für das automatische Erkennungsprotokoll außer Betrieb zu nehmen und dann zu entfernen. Die Möglichkeit zu spiegeln und die Methode des Spiegelns werden nicht beeinträchtigt und bleiben bestehen, wie in PEP 381 beschrieben. Betreiber bestehender Spiegel werden ermutigt, eigene Domains und Zertifikate für ihre Spiegel zu erwerben, falls sie diese weiterhin hosten möchten.

Plan zur Außerbetriebnahme & Entfernung

Unmittelbar nach Annahme dieser PEP werden die Dokumentation auf PyPI aktualisiert, um den veralteten Charakter der offiziellen öffentlichen Spiegel widerzuspiegeln, und die Benutzer werden auf externe Ressourcen wie http://www.pypi-mirrors.org/ verwiesen, um inoffizielle öffentliche Spiegel zu entdecken, falls sie einen nutzen möchten.

Spiegelbetreiber sollten, falls sie ihren Spiegel weiterhin betreiben möchten, einen Domainnamen zur Darstellung ihres Spiegels und, falls möglich, ein TLS-Zertifikat erwerben. Sobald sie eine Domain erworben haben, sollten sie ihre zugewiesene N.pypi.python.org Domain auf ihre neue Domain umleiten. Am 15. Februar 2014 werden die DNS-Einträge für [a..z].pypi.python.org und last.pypi.python.org entfernt. Zu jedem Zeitpunkt vor dem 15. Februar 2014 kann ein Spiegelbetreiber beantragen, dass seine Domain von PyPI zurückgefordert und wieder auf den Master verwiesen wird.

Warum 15. Februar 2014

Die kritischste Entscheidung dieser PEP ist das endgültige Stichtagsdatum. Wenn das Datum zu früh ist, bestraft es unnötigerweise Leute, indem es sie zwingt, alles fallen zu lassen, um ihre Bereitstellungsskripte zu aktualisieren. Wenn das Datum zu weit in der Ferne liegt, hilft die verlängerte Zeitspanne nicht bei der Migration und verschiebt die Migration lediglich auf einen späteren Zeitpunkt.

Das Datum des 15. Februar 2014 wurde gewählt, da es ungefähr 6 Monate nach dem Datum der PEP liegt. Dies sollte eine lange Zeitspanne gewährleisten, um es den Leuten zu ermöglichen, ihre Bereitstellungsverfahren zu aktualisieren und auf die neuen Domainnamen zu verweisen, ohne einfach nur das Stichtagsdatum zu verlängern.

Warum die DNS-Einträge entfernt werden müssen

Während es möglich wäre, die für Spiegel verwendeten Domainnamen einfach zurückzufordern und sie wieder auf PyPI umzuleiten, um zu verhindern, dass Benutzer Konfigurationen aktualisieren müssen, um von diesen Domains wegzuleiten, hat dies eine Reihe von Problemen.

  • Jeder, der diese Namen derzeit fest in seiner Konfiguration hat, hat sie als HTTP fest codiert. Das bedeutet, dass wir, indem wir diese Namen weiterhin auflösen lassen, es einem MITM-Betreiber leicht machen, Benutzer anzugreifen, indem er die Weiterleitung zu HTTPS umschreibt, bevor er sie an den Client weitergibt.
  • Der Verwaltungsaufwand für die Wartung mehrerer Domains, die auf PyPI verweisen, hat sich für die geringe Anzahl von N.pypi.python.org Domains, die bereits zurückgefordert wurden, als problematisch erwiesen. Sie werden oft falsch konfiguriert, wenn sich Dinge am Dienst ändern, was sie oft monatelang kaputt lässt, bis jemand es bemerkt. Indem wir sie belassen, setzen wir die Benutzer dieser Domains zufälligen Ausfällen aus, die unwahrscheinlicher entdeckt oder bemerkt werden.
  • Leute, die diese Domains nutzen, haben sich aus einem oder anderen Grund ausdrücklich dafür entschieden. Ein solcher Grund kann sein, dass sie nicht von einem Host in einem bestimmten Land aus bereitstellen möchten. Wenn diese Domains weiterhin auflösen, aber nicht auf ihre ursprünglichen Standorte verweisen, haben wir diese Wahl für die bestehenden Benutzer dieser Domains stillschweigend entfernt.

Das bedeutet, dass die Entfernung der Einträge Benutzer, die ihre Konfiguration geändert haben, zwingen wird, entweder zurück zum Master (PyPI) zu verweisen oder einen neuen Spiegelnamen auszuwählen, auf den verwiesen werden soll. Dies wird als bedauerliche Notwendigkeit angesehen, um PyPI selbst und die Benutzer der Spiegel vor den oben genannten Angriffen zu schützen oder sie zumindest zu einer informierten Entscheidung über die Unsicherheit zu zwingen.

Öffentliche oder private Spiegel

Das Spiegelprotokoll wird weiterhin wie in PEP 381 definiert bestehen und die Leute werden ermutigt, öffentliche und private Spiegel zu hosten, wenn sie dies wünschen. Der empfohlene Spiegel-Client ist Bandersnatch.

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

Zuletzt geändert: 2025-02-01 08:59:27 GMT