PEP 543

PEP 543 definiert eine neue TLS-API für Python, die die Python-Sicherheit verbessern würde, indem sie Python-Anwendungen Zugriff auf die nativen TLS-Implementierungen unter Windows und macOS gibt, anstatt OpenSSL zu verwenden. Ein Nebeneffekt ist, dass sie Zugriff auf den systemeigenen Truststore und von Systemadministratoren lokal installierte Zertifikate ermöglicht, wodurch Python-Anwendungen „Firmenzertifikate“ verwenden können, ohne jede Anwendung ändern zu müssen, und somit TLS-Zertifikate korrekt validieren können (anstatt TLS-Zertifikatsvalidierung zu ignorieren oder zu umgehen).

Aus praktischen Gründen möchte Cory Benfield zunächst eine I/O-lose Klasse ähnlich wie ssl.MemoryBIO und ssl.SSLObject für PEP 543 implementieren und eine zweite Klasse bereitstellen, die auf der ersten basiert und Sockets oder Dateideskriptoren verwendet. Dieses Design würde helfen, den Code zu strukturieren, um mehr Backends zu unterstützen und Tests sowie Audits zu vereinfachen, ebenso wie die Implementierung. Später können für die Leistung optimierte Klassen hinzugefügt werden, die direkt Sockets oder Dateideskriptoren verwenden.

Während PEP 543 eine API definiert, macht die PEP nur Sinn, wenn sie mit mindestens einer vollständigen und guten Implementierung einhergeht. Die erste Implementierung wäre idealerweise auf dem Modul ssl der Python-Standardbibliothek basiert, da dieses standardmäßig an alle Benutzer ausgeliefert wird und als Fallback-Implementierung bei Fehlen einer gezielteren Lösung verwendet werden kann.

Wenn dieser Backport nicht durchgeführt wird, wäre die einzige Basisimplementierung, die verwendet werden könnte, pyOpenSSL. Dies ist jedoch problematisch aufgrund der Interaktion mit pip, das mit CPython in allen unterstützten Versionen ausgeliefert wird.

requests, pip und ensurepip

Es gibt Pläne, Requests auf ein eher ereignisschleifenorientiertes Modell umzustellen. Das Requests-Team glaubt derzeit nicht, dass es möglich ist, die Unterstützung für Python 2.7 aufzugeben, daher würde dies die Verwendung von Twisted oder Tornado oder das Schreiben einer eigenen asynchronen Abstraktion erfordern.

Für asynchronen Code bietet MemoryBIO erhebliche Vorteile gegenüber der Verwendung eines gewrappten Sockets. Es reduziert die Menge des zu puffenden Speichers, funktioniert auf IOCP-basierten Reaktoren ebenso wie auf select/poll-basierten und vereinfacht auch den Reaktions- und Implementierungscode erheblich. Aus diesem Grund ist Requests abgeneigt, eine auf gewrappten Sockets basierende Implementierung zu verwenden. Mangels eines Backports auf Python 2.7 ist Requests verpflichtet, dieselbe Lösung wie Twisted zu verwenden: nämlich eine obligatorische Abhängigkeit von pyOpenSSL.

Das Programm pip muss aus praktischen Gründen alle seine Abhängigkeiten einbetten: nämlich, dass es sich auf keine andere Installationsmethode verlassen kann. Da pip von requests abhängt, bedeutet dies, dass es eine Kopie von pyOpenSSL einbetten müsste. Das würde erhebliche Benutzerfreundlichkeitsprobleme bei der Installation von pip mit sich bringen. Derzeit unterstützt pip keine Einbettung von C-Erweiterungen, die auf jeder Plattform kompiliert werden müssen und daher einen C-Compiler erfordern.

Seit Python 2.7.9 bettet Python eine Kopie von pip sowohl für die Standardinstallation als auch für die Verwendung in virtuellen Umgebungen über das neue Modul ensurepip ein. Wenn pip letztendlich PyOpenSSL bündelt, dann wird CPython PyOpenSSL bündeln. Nur das Backporting von ssl.MemoryBIO und ssl.SSLObject würde die Notwendigkeit vermeiden, pyOpenSSL einzubetten, und würde das Bootstrap-Problem lösen (python -> ensurepip -> pip -> requests -> MemoryBIO).

Diese Situation ist weniger problematisch als die Hürde für die Einführung von PEP 543, da Requests natürlich nicht auf ein ereignisschleifenbasiertes Modell umsteigen muss, bevor es die Unterstützung für Python 2.7 einstellt. Es macht es jedoch für Requests (und pip) schmerzhaft, sowohl asyncio als auch die Schlüsselwörter async und await zu nutzen, solange es weiterhin Python 2 unterstützt.

Andere Vorteile

Die Einführung dieser PEP würde weitere kleinere Vorteile für das Ökosystem mit sich bringen. Zum Beispiel könnte Twisted seine Abhängigkeit von Drittanbieter-C-Erweiterungen reduzieren. Darüber hinaus möchte das PyOpenSSL-Entwicklungsteam das Modul einstellen, und dieser Backport würde ihnen ermöglichen, dies auf anmutige Weise zu tun, ohne ihre Benutzer im Stich zu lassen.

Jeder dieser Randvorteile, obwohl klein, bietet auch Wert für das breitere Python-Ökosystem.

Was ist mit altem Python 2?

Eine Reihe von Python-2-Benutzern weltweit halten nicht mit den Python-2-Releases Schritt. Dies liegt meist daran, dass sie LTS-Releases verwenden, die nicht mit den Minor-Releases von Python 2 Schritt halten. Diese Benutzer könnten MemoryBIO nicht verwenden, und so könnten Projekte, die sich mit der Python-2-Kompatibilität befassen, nicht darauf vertrauen, dass MemoryBIO auf den Systemen der meisten ihrer Benutzer vorhanden ist.

Diese Sorge ist berechtigt. Wie kritisch sie ist, hängt von der Wahrscheinlichkeit ab, dass aktuelle Benutzer von Python 2 zu Python 3 migrieren oder einfach die aktuellste Python-2-Version verwenden. Anders ausgedrückt, irgendwann werden Bibliotheken die Unterstützung für Python 2 einstellen wollen: Die Frage ist nur, ob eine signifikante Mehrheit ihrer Python-2-Benutzer zu einer Python-2-Version migriert ist, die diesen Backport enthält, bevor sie dies tun.

Letztendlich glauben die Autoren dieser PEP, dass die Belastung dieses Backports ausreichend gering ist, um ihn trotz dieser Bedenken zu rechtfertigen. Wenn sich herausstellt, dass die Migration zu neueren 2.7-Versionen zu langsam ist, wird der Wert der Arbeit minimal sein, aber wenn die Migration zu neueren 2.7-Versionen auch nur annähernd vernünftig ist, wird ein erheblicher Wert erzielt.