OpenSSL-Kompatibilität

Unter diesem Vorschlag kann OpenSSL in Python 2.7 Wartungs-Releases auf neuere Feature-Releases aktualisiert werden. Unter Linux und den meisten anderen POSIX-Systemen variiert die spezifische Version von OpenSSL bereits, da CPython standardmäßig dynamisch mit der vom System bereitgestellten OpenSSL-Bibliothek verknüpft ist.

Für die Windows-Binär-Installer sind die Module _ssl und _hashlib statisch mit OpenSSL verknüpft und die entsprechenden Symbole werden nicht exportiert. Marc-Andre Lemburg gibt an, dass die Aktualisierung auf neuere OpenSSL-Releases in den egenix-pyopenssl Binärdateien zu keinen gemeldeten Kompatibilitätsproblemen geführt hat [3].

Die Mac OS X Binär-Installer folgten historisch der gleichen Politik wie andere POSIX-Installationen und verknüpften dynamisch mit den von Apple bereitgestellten OpenSSL-Bibliotheken. Apple hat jedoch die Aktualisierung dieser plattformübergreifenden Bibliotheken eingestellt und verlangt nun, dass selbst plattformübergreifende Entwickler Mac OS X-spezifische Schnittstellen verwenden, um auf aktuelle Sicherheitsinfrastruktur auf ihrer Plattform zuzugreifen. Dementsprechend und unabhängig von diesem PEP werden die Mac OS X Binär-Installer bereits auf die statische Verknüpfung neuerer OpenSSL-Versionen umgestellt [4].

Wartbarkeit

Eine Reihe von Entwicklern, darunter Alex Gaynor und Donald Stufft, haben Interesse daran bekundet, die von dieser Richtlinie abgedeckten Feature-Backports durchzuführen und bei zusätzlichen Wartungsaufwänden zu helfen, die sich daraus für die Python 2-Serie ergeben.

Steve Dower und Brian Curtin haben angeboten, bei der Erstellung der Windows-Installer zu helfen, was Martin von Löwis die Möglichkeit gibt, sich von der Aufgabe der Wartung des 2.7 Windows-Installers zurückzuziehen.

Dieses PEP dient in erster Linie dazu, den Konsens zu schaffen, der es ihnen ermöglicht, diese Arbeit auszuführen. Für andere Kernentwickler sollte diese Richtlinienänderung keine zusätzlichen Anstrengungen über das potenzielle Überprüfen der resultierenden Patches hinaus erfordern, und das nur für die Entwickler, die sich speziell für die betroffenen Module interessieren.

Sicherheits-Releases

Dieses PEP schlägt keine Änderungen an der Handhabung von Sicherheits-Releases vor – diese werden weiterhin ausschließlich als Quellcode-Releases veröffentlicht, die nur kritische Sicherheitspatches enthalten.

Die Empfehlungen für Bibliotheks- und Anwendungsentwickler sind jedoch bewusst so gestaltet, dass sie kommerzielle Wiederverkäufer unterstützen, die diese Änderungen auf zusätzliche Python-Release-Serien anwenden, die sich entweder im Modus "nur Sicherheitspatches" befinden oder vom Kernentwicklungsteam als "End-of-Life" erklärt wurden.

Ob Wiederverkäufer diese Option nutzen, bleibt jedem einzelnen Wiederverkäufer überlassen.

Integrationstests

Drittanbieter-Integrationstestdienste sollten den Nutzern die Möglichkeit bieten, gegen mehrere Python 2.7 Wartungs-Releases (mindestens 2.7.6 und 2.7.7+) zu testen, um sicherzustellen, dass Bibliotheken, Frameworks und Anwendungen ihre Handhabung der Legacy-Sicherheitsinfrastruktur weiterhin korrekt testen können (entweder mit Fehler oder mit graceful Degradation, je nach Sicherheitskritikalität der Software), auch nachdem die in diesem Vorschlag behandelten Funktionen in die Python 2.7-Serie zurückportiert wurden.

Umgang mit Umgebungen mit geringerer Sicherheit und geringer Risikotoleranz

Ob zum Guten oder Schlechten (meistens zum Schlechten), es gibt einige Umgebungen, in denen das Risiko latenter Sicherheitsmängel stärker toleriert wird als ein leicht erhöhtes Risiko von Regressionen in Wartungs-Releases. Dieser Vorschlag schließt diese Umgebungen weitgehend aus, was die betroffenen Module betrifft – dieser Ansatz ist für Software, die mit dem öffentlichen Internet verbunden ist, völlig ungeeignet, und Prinzipien der "Defense in Depth"-Sicherheit legen nahe, dass er auch für die meisten privaten Netzwerke nicht angemessen ist.

Downstream-Wiederverkäufer können sich weiterhin für solche Umgebungen entscheiden, müssen dann aber selbst für das Downgrading der sicherheitsbezogenen Module und die damit verbundenen Regressionstests sorgen. Die CPython Continuous Integration-Infrastruktur deckt dieses Szenario nicht ab.

Warum diese spezifischen Änderungen?

Die Kernanforderung für eine Funktion, um in diesem Vorschlag berücksichtigt zu werden, war, dass sie Sicherheitsimplikationen *über* die spezifische in Python geschriebene Anwendung und das System, auf dem die Anwendung läuft, hinaus haben muss. Daher der Fokus auf Netzwerksicherheitsprotokolle, Passwortspeicherung und verwandte kryptografische Infrastruktur – Python ist eine beliebte Wahl für die Entwicklung von Webdiensten und Clients, und daher haben die Fähigkeiten weit verbreiteter Python-Versionen Auswirkungen auf das Sicherheitsdesign anderer Dienste, die möglicherweise neuere Versionen von Python oder andere Programmiersprachen verwenden, aber mit Clients oder Servern interagieren müssen, die mit älteren Python-Versionen geschrieben wurden.

Die Absicht hinter dieser Anforderung war, die Auswirkungen, die die Einführung dieser Richtlinie auf die Stabilität und Kompatibilität von Wartungs-Releases haben könnte, zu minimieren und gleichzeitig einige wichtige Sicherheitsbedenken im Zusammenhang mit den spezifischen Aspekten von Python 2.7 zu adressieren. Es wäre zutiefst kontraproduktiv, wenn Endbenutzer bei der Aktualisierung auf neue Python 2.7 Wartungs-Releases genauso vorsichtig wären wie bei der Aktualisierung auf neue Feature-Releases innerhalb derselben Release-Serie.

Die Änderungen am ssl-Modul sind in diesem Vorschlag enthalten, um die Python 2-Serie auf den Stand der letzten 4 Jahre der Entwicklung von Netzwerksicherheitsstandards zu bringen und die breite Einführung dieser Standards sowohl in Servern als auch in Clients zu erleichtern. Ebenso sind die Indikatoren für die Verfügbarkeit von Hash-Algorithmen in hashlib enthalten, um Anwendungen die Erkennung und Verwendung geeigneter Hash-Definitionen in Python 2 und 3 zu erleichtern.

Die Funktionen hmac.compare_digest() und hashlib.pbkdf2_hmac() sind enthalten, um die Hürden für die sichere Speicherung und Überprüfung von Passwörtern in Python 2-Serveranwendungen zu senken.

Die Änderung an os.urandom() wurde in diesen Vorschlag aufgenommen, um Benutzer weiter zu ermutigen, die Aufgabe der Bereitstellung hochwertiger Zufallszahlen für kryptografische Anwendungsfälle den Betriebssystemanbietern zu überlassen. Die Verwendung unzureichend zufälliger Zahlen kann *jedes* kryptografische System kompromittieren, und Betriebssystementwickler verfügen über mehr Werkzeuge, um dieses Problem angemessen zu lösen, als die typische Python-Anwendungsumgebung.

Abgelehnte Alternative: Entwickler nur anweisen, auf Python 3 zu migrieren

Diese Alternative repräsentiert den Status quo. Leider hat sich dieser als praktisch unbrauchbar erwiesen, da die Abwärtskompatibilitätsprobleme bedeuten, dass dies ein nicht trivialer Migrationsprozess für große Anwendungen und Integrationsprojekte ist. Obwohl die Werkzeuge für die Migration sich zu einem Punkt entwickelt haben, an dem es möglich ist, selbst große Anwendungen opportunistisch und inkrementell zu migrieren (anstatt alles auf einmal), indem der Code aktualisiert wird, um in der großen gemeinsamen Teilmenge von Python 2 und Python 3 zu laufen, ist die Verwendung der neuesten Technologie in kommerziellen Umgebungen oft keine Priorität.

Zuvor wurde dies als akzeptabler Schaden angesehen, da, obwohl es ein unglückliches Problem für die betroffenen Entwickler war, es als eine Angelegenheit zwischen ihnen und ihrer Managementkette betrachtet wurde, den Fall für die Modernisierung der Infrastruktur darzulegen, und dieser Fall mit der Weiterentwicklung der Python 3-Serie natürlich überzeugender wurde.

Nachdem wir nun jedoch die Auswirkungen, die die Einschränkungen der Python 2-Standardbibliothek auf die Entwicklung von Internetsicherheitsstandards haben könnten, vollständig kennen, glaube ich nicht mehr, dass es zumutbar ist, von Plattform- und Anwendungsentwicklern zu erwarten, alle latenten Mängel bei der Unicode-Korrektheit einer Anwendung ausschließlich zu beheben, nur um Zugang zu den Netzwerk-Sicherheitsverbesserungen zu erhalten, die bereits in Python 3 verfügbar sind.

Während Ubuntu (und in gewissem Maße auch Debian) sich verpflichtet haben, alle Standard-Systemdienste und Skripte auf Python 3 zu portieren und Python 2 aus seinen Standard-Distributionsbildern zu entfernen (aber nicht aus seinen Archiven), ist dies eine Mammutaufgabe und wird nicht für die Ubuntu 14.04 LTS-Version abgeschlossen sein (zumindest für das Desktop-Bild – für Mobil- und Server-Bilder mag es erreicht werden).

Fedora hat noch mehr Arbeit zu tun, um zu migrieren, und es wird eine nicht unerhebliche Zeit dauern, die relevanten Infrastrukturkomponenten zu migrieren. Während Red Hat auch aktiv daran arbeitet, es Benutzern zu erleichtern, neuere Python-Versionen auf unseren stabilen Plattformen zu verwenden, wird es einige Zeit dauern, bis diese Bemühungen beginnen, die Wahl der Version von Endbenutzern zu beeinflussen, und solche Änderungen kommen auch der Kernplattform-Infrastruktur zugute, die aus Notwendigkeit im integrierten System-Python läuft.

Die Migration von OpenStack auf Python 3 steht ebenfalls noch am Anfang, und obwohl dies ein Projekt mit einer umfangreichen und relativ robusten automatisierten Testsuite ist, dauert es immer noch so lange, bis es vollständig auf eine Python 2/3-kompatible Codebasis migriert ist.

Und das sind nur drei der prominentesten Open-Source-Projekte, die Python intensiv nutzen. Angesichts der wahrscheinlichen Existenz großer Mengen an Legacy-Code, dem die Art von automatisierten Regressionstestsuiten fehlt, die zur Unterstützung einer Migration von Python 2 auf Python 3 erforderlich sind, gibt es wahrscheinlich viele Fälle, in denen eine Neuentwicklung (vielleicht sogar in Python 3) einfacher ist als eine Migration. Der Kernpunkt dieses PEP ist, dass diese Situationen mehr Menschen betreffen als nur die Entwickler und Benutzer der betroffenen Anwendung: Die Existenz von Clients und Servern mit veralteter Netzwerksicherheitsinfrastruktur wird zu etwas, das Entwickler von sicheren vernetzten Diensten bei ihrem Sicherheitsdesign berücksichtigen müssen, und das ist ein Problem, das die Einführung besserer Sicherheitsstandards behindert.

Wie Terry Reedy bemerkte, wenn wir versuchen, am Status quo festzuhalten, wird das wahrscheinliche Ergebnis sein, dass kommerzielle Wiederverkäufer versuchen werden, so etwas im Namen ihrer Kunden *sowieso* zu tun, aber auf eine potenziell inkonsistente und ad-hoc- Weise. Indem wir den Prozess der Definition des Umfangs in das Upstream-Projekt einbeziehen, sind wir besser positioniert, um den Ansatz zur Bewältigung der Situation zu beeinflussen und eine gewisse Konsistenz zwischen den Wiederverkäufern zu gewährleisten.

Das Problem ist real, also *muss* sich etwas ändern, und dieses PEP beschreibt meinen bevorzugten Ansatz, die Situation zu lösen.

Abgelehnte Alternative: Python 2.8 erstellen und veröffentlichen

Mit ausreichender Unterstützung durch Unternehmen wäre es wahrscheinlich *möglich*, Python 2.8 zu erstellen und zu veröffentlichen (es ist sehr unwahrscheinlich, dass ein solches Projekt genug Interesse wecken würde, um nur mit Freiwilligen realisierbar zu sein). Dies würde das Problem jedoch nicht lösen, da das Ziel darin besteht, eine *relativ geringfügige* Möglichkeit zu schaffen, verbesserte Sicherheitsfunktionen in integrierte Produkte und Deployments zu integrieren, die Python 2 verwenden.

Ein Upgrade auf eine neue Python Feature-Release würde sowohl mehr Arbeit für das Kernentwicklungsteam bedeuten, als auch ein disruptiveres Update, das die meisten potenziellen Endbenutzer wahrscheinlich einfach überspringen würden.

Der Versuch, eine Python 2.8-Release zu erstellen, würde auch Vorschläge für die Zurückportierung vieler zusätzlicher Funktionen von Python 3 mit sich bringen (wie z.B. tracemalloc und die verbesserte Coroutine-Unterstützung), was die Migration von Python 2.7 zu dieser hypothetischen 2.8-Release noch riskanter und disruptiver macht.

Dies ist kein empfohlener Ansatz, da er erheblich zusätzlichen Aufwand für ein Ergebnis bedeuten würde, das tatsächlich weniger effektiv bei der Erreichung des ursprünglichen Ziels ist (nämlich die derzeit weit verbreitete Nutzung der veralteten Netzwerksicherheitsinfrastruktur in der Python 2-Serie zu eliminieren).

Darüber hinaus kann ich, obwohl ich keine Verpflichtungen eingehen kann, diese Frage für Red Hat-Plattformen tatsächlich zu lösen, die Idee eines Python 2.8 kategorisch ausschließen, um auch nur den Versuch zu unternehmen, sie anzugehen.

Abgelehnte Alternative: Sicherheitsverbesserungen über PyPI verteilen

Obwohl dies zunächst wie ein attraktiverer und leichter zu handhabender Ansatz erscheint, leidet er tatsächlich unter mehreren signifikanten Problemen.

Erstens handelt es sich um komplexen, Low-Level-, plattformübergreifenden Code, der über eine Vielzahl von POSIX-Plattformen (einschließlich Mac OS X) und Windows mit dem zugrunde liegenden Betriebssystem interagiert. Die CPython BuildBot-Flotte ist bereits für die kontinuierliche Integration in diesem Kontext eingerichtet, aber die meisten frei verfügbaren kontinuierlichen Integrationsdienste bieten nur Linux und vielleicht bezahlten Zugriff auf Windows an. Diese Dienste funktionieren einigermaßen gut für Software, die größtenteils auf den Abstraktionsebenen von Python und anderen dynamischen Sprachen sowie der umfassenderen Abstraktion der JVM läuft, sind aber für die Art von Code, die hier behandelt wird, nicht ausreichend.

Die OpenSSL-Abhängigkeit für die Netzwerksicherheitsunterstützung qualifiziert sich auch als die Art von "komplexer Binärabhängigkeit", die vom pip-basierten Softwareverteilungs-Ökosystem noch nicht gut gehandhabt wird. Die Abhängigkeit von einer Drittanbieter-Binärdatei schafft auch potenzielle Kompatibilitätsprobleme für pip, wenn es auf anderen Interpretern wie PyPy ausgeführt wird.

Ein weiteres praktisches Problem mit der Idee ist die Tatsache, dass pip selbst auf die ssl-Unterstützung in der Standardbibliothek angewiesen ist (mit zusätzlicher Unterstützung durch eine gebündelte Kopie von requests, die wiederum backport.ssl_match_hostname bündelt) und daher ein Ersatzmodul ebenfalls innerhalb von pip gebündelt werden müsste. Dies würde keine unüberwindbaren Schwierigkeiten darstellen (es ist nur eine weitere Abhängigkeit zum Vormerken), würde aber bedeuten, dass eine weitere Kopie von OpenSSL aktuell gehalten werden müsste.

Dieser Ansatz hat auch den gleichen Fehler wie alle anderen Ansätze zur "Sicherheitsverbesserung durch Umbenennung": Sie übersehen vollständig die Benutzer, die am meisten Hilfe benötigen, und schaffen erhebliche Hindernisse, um Benutzer dazu zu ermutigen, das Richtige zu tun, wenn ihre Infrastruktur dies unterstützt (da "verwende dieses andere Modul" eine weitaus größere Auswirkung hat als "aktiviere diese höhere Sicherheitseinstellung"). Die Veralterung der alten SSL-Infrastruktur in der Standardbibliothek zugunsten eines externen Moduls wäre für den Benutzer feindseliger als die Akzeptanz des leicht erhöhten Risikos von Regressionen, die mit der In-Place-Aktualisierung verbunden sind.

Nicht zuletzt leidet dieser Ansatz unter demselben Problem wie die Idee einer Python 2.8-Veröffentlichung: Er löst wahrscheinlich nicht das eigentliche Problem. Kommerzielle Weiterverteiler von Python sind darauf eingerichtet, Python und eine vordefinierte Sammlung zusätzlicher Pakete weiterzuverteilen. Neue Pakete in die vordefinierte Sammlung aufzunehmen, ist zwar möglich, erfordert aber, jeden einzelnen Weiterverteiler anzusprechen und ihn zu bitten, seinen Repackaging-Prozess entsprechend zu aktualisieren. Im Gegensatz dazu würde der in diesem PEP beschriebene Ansatz erfordern, dass Weiterverteiler sich bewusst von den Sicherheitsverbesserungen abmelden, indem sie die bereitgestellte Netzwerksicherheitsinfrastruktur bewusst downgraden, was die meisten von ihnen wahrscheinlich nicht tun werden.

Abgelehnte Variante: Einen "Legacy SSL Infrastruktur"-Zweig bereitstellen

Frühere Versionen dieses PEP enthielten das Konzept eines 2.7-legacy-ssl-Branches, der die exakte Funktionalität der Netzwerksicherheitsinfrastruktur von Python 2.7.6 beibehielt.

Meiner Meinung nach macht sich fast jeder, der dies tatsächlich wünscht, wahrscheinlich einen Fehler, und wenn er darauf besteht, dass er es in seiner spezifischen Situation wirklich will, kann er es entweder selbst machen oder einen Downstream-Weiterverteiler damit beauftragen.

Wenn sie öffentlich zugänglich gemacht werden, sollten solche Neuerstellungen als „Python 2.7 mit Legacy SSL“ bezeichnet werden, um sie klar von den offiziellen Python 2.7-Veröffentlichungen zu unterscheiden, die aktuellere Netzwerksicherheitsinfrastrukturen enthalten.

Nach der ersten Python 2.7-Wartungsfreigabe, die diesen PEP implementiert, wäre es auch angebracht, Python 2.7.6 und frühere Versionen als „Python 2.7 mit Legacy SSL“ zu bezeichnen.

Abgelehnte Variante: Bestimmte Module vollständig mit Python 3 synchronisieren

Frühere Versionen dieses PEP schlugen vor, die Module hmac, hashlib und ssl vollständig mit ihren Python 3-Gegenstücken zu synchronisieren.

Dieser Ansatz erwies sich als zu vage, um eine überzeugende Begründung für die Ausnahme zu liefern, und wurde daher durch den aktuellen expliziteren Vorschlag ersetzt.

Abgelehnte Variante: Offene Backport-Richtlinie

Frühere Versionen dieses PEP schlugen eine allgemeine Politikänderung in Bezug auf zukünftige Python 3-Verbesserungen vor, die die allgemeine Sicherheit des Internets beeinträchtigen.

Dieser Ansatz schuf unnötige Unsicherheit, daher wurde er vereinfacht, um eine spezifische, konkrete Reihe von Änderungen zurückportieren zu können. Zukünftige Vorschläge für Feature-Backports können sich auf diesen PEP als Präzedenzfall beziehen, aber es wird trotzdem notwendig sein, für jede Feature-Erweiterung der Python 2.7-Langzeitunterstützungsversion eine spezifische Begründung zu liefern.