Python Weekly #5: Python 3.15.1 widerruft kompromittierte CA, PEP 850 für Hardware-Beschleunigung, PEP 836 zurückgezogen

Willkommen zur 5. Ausgabe der Python-Kolumne im Tuanzi Tech Digest. In dieser Woche (19.10.2026 bis 26.10.2026) veröffentlichte das offizielle Python-Team mehrere Notfall-Wartungsversionen zur Abwehr kompromittierter CA-Zertifikate. Die Packaging-Arbeitsgruppe reichte gemeinsam PEP 850 zur Standardisierung hardwarebeschleunigter Wheels ein, das CPython-Kernteam zog PEP 836 zurück, um die JIT-Entwicklung in externe Prototypen auszulagern, und eine Schwachstelle im Brotli-Decoder bedrohte Netzwerk-Abhängigkeitsketten. Hier ist unser Überblick über die verifizierten technischen Meilensteine der vergangenen sieben Tage.

📦 Release- und Versionsdynamik

Offizielle Notfall-Sicherheitsupdates und Schutz der Transportschicht

Der aktuelle offizielle Hauptzweig ist Python 3.15.1 (veröffentlicht am 21. Oktober 2026, signiert von Release Manager Hugo van Kemenade). Eine detaillierte Übersicht über die Neuerungen der 3.15-Serie finden Sie in unserem Hintergrundbericht: Python 3.15 im Detail.

In den vergangenen sieben Tagen reagierte das CPython-Team auf den Diebstahl privater Schlüssel von Zwischenzertifikaten der vertrauenswürdigen Zertifizierungsstelle eMudhra mit zwei aufeinanderfolgenden Notfall-Releases und beseitigte im Hauptzweig eine Deadlock-Regression beim Modulimport. Die wichtigsten technischen Änderungen umfassen:

1. Zertifikatsvalidierungs-Sperre (gh-160040 / CVE-2026-115557): Als Reaktion auf den kompromittierten privaten Schlüssel der Zwischenzertifizierungsstelle eMudhra erhielten die am 21. Oktober veröffentlichten Versionen Python 3.15.1, 3.14.9 und 3.13.17 ein Upgrade des gebündelten pip auf Version 26.2.2 (inklusive certifi 2026.10.19). Am 25. Oktober folgten Versionen 3.13.18, 3.12.16 und 3.11.18, die eine hartcodierte Blacklist basierend auf SubjectPublicKeyInfo (SPKI)-Hashes direkt in das Kernmodul _ssl integrieren. Sobald die Client-Validierung aktiv ist, blockiert der TLS-Handshake betroffene Zertifikatsketten sofort, ohne auf verzögerte Updates der Betriebssystem-Zertifikatsspeicher warten zu müssen.
2. Stabilitäts- und Wartungs-Patches in Python 3.15.1: Als erstes Wartungsupdate für 3.15.0 integriert Version 3.15.1 rund 330 Fehlerbehebungen von 117 Mitwirkenden. Zu den wichtigsten Punkten zählen: Behebung einer Schwachstelle bei negativen Versionsnummern in http.cookiejar (gh-160300), Beseitigung einer Race Condition beim parallelen Bereinigen in tempfile.TemporaryDirectory (gh-157579), Abwehr von Path-Traversal-Risiken durch Symlinks in tarfile.tar_filter (CVE-2026-114583) sowie die Deaktivierung des automatischen Ladens von mimetypes.knownfiles unter Windows (CVE-2024-3220).
3. Behebung von Pseudo-Deadlocks bei parallelem Erstimport (gh-159963 / gh-159965): Der in 3.15.0 eingeführte _HierarchicalLockManager führte dazu, dass der Lock des übergeordneten Pakets während der Ausführung des Submoduls gehalten wurde, was beim Multithreading-Kaltstart zu falschen _DeadlockError-Ausnahmen führte. Das Kernteam hob diese Bindung auf dem Hauptzweig und dem 3.15-Wartungszweig auf, sodass der Lock des Elternpakets unmittelbar vor der Ausführung des Submodul-Codes freigegeben wird.

Übersicht über den Status der offiziellen Wartungszweige:

Version	Veröffentlichungsdatum	Wartungszweig-Kategorie	Wichtigste Fehlerbehebungen & Relevanz
Python 3.15.1	2026-10-21	Aktueller stabiler Hauptzweig (Bugfix)	Enthält pip 26.2.2 ohne kompromittierte CA; rund 330 Stabilitäts-Fixes
Python 3.14.9	2026-10-21	Vorheriger stabiler Zweig (Bugfix)	Aktualisiert pip und synchronisiert Zertifikatsketten im macOS-Installer
Python 3.13.18	2026-10-25	Sicherheits-Supportzweig (Security)	Hartcodierte SPKI-Sperre in _ssl für eMudhra; Upgrade auf Expat 2.9.0
Python 3.12.16	2026-10-25	Sicherheits-Supportzweig (Security)	Backport des SPKI-Sperrpatches und Fix für tarfile-Pfadumgehungen
Python 3.11.18	2026-10-25	Sicherheits-Supportzweig (Security)	Blockiert Zertifikats-Fingerprints; schützt Altsysteme und Container

Ein Blick in die Release Notes verdeutlicht, dass die Aktualisierung des systemweiten Python-Binärpakets bestehende virtuelle Umgebungen unberührt lässt. Entwickler müssen in allen aktiven virtualenvs explizit python -m pip install --upgrade certifi pip ausführen, um den Schutz lückenlos zu gewährleisten.

---

📝 Vertiefende Berichte

PEP 850 offiziell eingereicht: Wheel Variants schaffen Standard für heterogene Hardware

• Was ist geschehen: Am 19. Oktober 2026 reichten Michał Górny (Quansight), Jonathan Dekhtiar, Konstantin Schütze (Astral/uv) und Ralf Gommers offiziell PEP 850 (Wheel Variants: Providers) ein, der die Vorgänger PEP 817 und PEP 825 bündelt und grundlegend überarbeitet. Der Vorschlag wird von Carol Willing gesponsert und gemeinsam von Astral, Meta und Quansight getragen.
• Warum es wichtig ist: Bibliotheken für wissenschaftliches Rechnen wie PyTorch und JAX waren bislang durch statische Plattform-Tags eingeschränkt und mussten auf lokale Versionssegmente (wie +cu124) oder proprietäre Extra Indexes ausweichen, um Builds für spezialisierte Beschleuniger bereitzustellen. PEP 850 führt einen Mechanismus für Variant Provider ein, der es Paket-Resolvern erlaubt, während der Installation Hardware-Beschleuniger auf dem Zielsystem dynamisch zu erkennen (CUDA Compute Capability, ROCm, AVX-512, Metal). Damit können beschleunigte Wheels automatisch über den regulären PyPI-Index aufgelöst werden, was zersplitterte Eigenlösungen überflüssig macht.
• Wer betroffen ist: Maintainer von Deep-Learning-Frameworks, Paketierer wissenschaftlicher Bibliotheken, Entwickler von Python-Paketierungstools (uv, pip) sowie Administratoren automatisierter CI/CD-Container-Pipelines.

CPython zieht PEP 836 und PEP 774 zurück: JIT-Architektur wechselt auf externe Prototypen

• Was ist geschehen: Am 19. Oktober 2026 gaben die Kernentwickler des CPython-JIT, Savannah Ostrowski, Ken Jin und Brandt Bucher, den offiziellen Rückzug von PEP 836 (“JIT Go Brrr: The Path to a Supported JIT Compiler for CPython”) bekannt. Am 20. Oktober folgte der Rückzug von PEP 774, der die LLVM-Build-Abhängigkeit beseitigen sollte. Im Discourse-Forum erläuterten die Autoren, dass aufgrund begrenzter Entwicklerressourcen und der hohen Stabilitätsanforderungen des Steering Councils für 3.16 die Arbeiten an einem methodenbasierten JIT vorerst in einem externen Fork (openai-oss-forks:cpython:public/pep-836) weitergeführt werden.
• Warum es wichtig ist: Diese Entscheidung markiert eine strategische Abkehr von der in Version 3.13 eingeführten Trace-basierten JIT-Architektur hin zu Methoden-JITs. Der Proof of Concept zeigte in den Benchmarks pyperformance und Pyston Geschwindigkeitszuwächse von 5 bis 6 Prozent und reduzierte etwa 3.100 Zeilen generierten sowie 4.300 Zeilen nicht-generierten Code. Allerdings erwies sich die Reife für den Tier-1-Produktionseinsatz über verschiedene Plattformen hinweg in Kombination mit Free-Threading kurzfristig als unerreichbar. Der offizielle Zeitplan, den JIT in 3.16 zum Standard-Feature zu erheben, wurde daher vorerst verlangsamt.
• Wer betroffen ist: Systemarchitekten mit Fokus auf CPython-Laufzeitperformance, Entwickler im Bereich Free-Threading sowie Compiler- und Interpreter-Forscher.

CVE-2026-111497 (Broccoli2Shell): Out-of-Bounds-Write in Brotli trifft Python-Netzwerkstack

• Was ist geschehen: Am 24. Oktober 2026 machten Sicherheitsforscher eine schwerwiegende Schwachstelle im C-basierten Brotli-Decoder von Google öffentlich (CVE-2026-111497, CVSS 4.0 Score 9.2 Critical), die die Versionen 1.0.3 bis 1.2.0 betrifft. Die auf PyPI bereitgestellten C-Erweiterungen Brotli und brotlicffi sind gleichermaßen anfällig.
• Warum es wichtig ist: Wenn Brotli im Python-Umfeld installiert ist, senden Bibliotheken wie urllib3 und requests standardmäßig den Header Accept-Encoding: br und dekomprimieren Antworten automatisch; das asynchrone Framework aiohttp verhält sich identisch. Selbst wenn eine Anwendung keine expliziten Dekodierungsfunktionen aufruft, genügt der Empfang eines bösartig konstruierten Payloads (ca. 23 MB) bei ausgehenden HTTP-Anfragen, um einen Speicher-Überlauf auszulösen. Dies kann zu Denial-of-Service oder Remote Code Execution (RCE) führen. In Produktionsumgebungen muss umgehend auf Brotli>=1.2.1 oder brotlicffi>=1.2.1.0 aktualisiert werden. Falls kein Update möglich ist, führt die Deinstallation der Bibliotheken dazu, dass Clients sicher auf gzip zurückfallen.
• Wer betroffen ist: Backend-Entwickler, die requests, urllib3 oder aiohttp für externe API-Aufrufe nutzen, Entwickler von Web-Scrapern sowie Security-Teams.

Python 3.15 behebt Deadlock beim parallelen Submodul-Import (gh-159963)

• Was ist geschehen: Am 25. Oktober 2026 führte das CPython-Kernteam Pull Request gh-159965 im Hauptzweig zusammen (und portierte gh-160630 auf Version 3.15 zurück), um das Einfrieren beim parallelen Erstimport von Submodulen (gh-159963) zu beheben, das durch den in 3.15.0 eingeführten _HierarchicalLockManager ausgelöst wurde.
• Warum es wichtig ist: Unter 3.15.0 hielten Threads bei gleichzeitigen ersten Modulimporten über Paketgrenzen hinweg die Sperre des übergeordneten Pakets während der gesamten Ausführung des Submoduls. Dies führte dazu, dass unverdächtiger Code ohne zyklische Abhängigkeiten fälschlicherweise _DeadlockError oder irreführende ImportError-Meldungen auslöste. Grundlegende Bibliotheken wie cryptography und protobuf froren beim Multithreading-Kaltstart regelmäßig ein. Der Patch überarbeitet das Lock-Lebenszyklusmanagement grundlegend und stellt sicher, dass der Paketlock vor dem Ausführen des Modulkörpers freigegeben wird.
• Wer betroffen ist: Teams, die Multithreaded-Microservices auf Python 3.15.0 betreiben oder Worker unter FastAPI, Gunicorn und Celery parallel starten.

---

🔥 Community-Diskussionen

Broccoli2Shell-Debatte: C-Sicherheit und implizite Inhaltsaushandlung

• Resonanz: Der Hauptthread auf Hacker News erzielte 390 Punkte / 209 Kommentare (HN #50219177), begleitet von einer Nebendiskussion mit 186 Punkten / 95 Kommentaren (HN #50216791).
• Zentrale Streitpunkte:
  1. Müssen Basiskomponenten zwingend nach Rust portiert werden?: Viele Systementwickler argumentierten, dass ein kritischer CVSS-9.2-Speicherfehler in einer allgegenwärtigen Bibliothek wie Brotli zeige, dass C-Code durch Rust ersetzt werden müsse. Dem hielten andere entgegen, dass die C-Codebasis über ein Jahrzehnt lang für spezifische SIMD-Befehlssätze optimiert wurde. Da Spitzen-Durchsatz auf Edge-Systemen unverzichtbar sei, lasse sich eine solche Performance kurzfristig kaum in einer Neuentwicklung replizieren.
  2. Sollten HTTP-Clients auf implizite Inhaltsaushandlung verzichten?: Ingenieure kritisierten das Verhalten von urllib3 und requests, Accept-Encoding: br automatisch zu aktivieren, sobald ein passendes Paket vorhanden ist. Dies vergrößere unbemerkt die Angriffsfläche, weshalb ein explizites Opt-in gefordert wurde. Die Maintainer entgegneten, dass automatische Kompressionsaushandlung ein fundamentaler Standard des modernen Webs sei; eine manuelle Aktivierungspflicht würde den weltweiten Bandbreitenverbrauch drastisch erhöhen.

Daniel Lemire testet fastpybase64: SIMD-Optimierung vs. Rolle der Standardbibliothek

• Resonanz: Diskussion auf Hacker News (HN #50154972) und Blogbeitrag von Daniel Lemire.
• Zentrale Streitpunkte: Auf einem einzelnen Kern eines Intel Xeon Gold 6548N erreichte fastpybase64 (basierend auf simdutf) bei 64-KiB-Blöcken einen Dekodierungsdurchsatz von 13,3 GB/s – 4-mal schneller als pybase64 (3,1 GB/s) und 27-mal schneller als das base64-Modul der Standardbibliothek (0,49 GB/s).
  1. Sollte CPython SIMD-Vektorisierung nativ integrieren?: Performance-Befürworter plädierten dafür, dass Flaschenhälse bei der Daten-Serialisierung (Base64, JSON) eine direkte Integration von Assembly-Befehlssätzen wie simdutf in die CPython-Standardbibliothek rechtfertigen. Maintainer betonten dagegen, dass Portabilität das oberste Ziel von CPython bleibe. Die Pflege plattformspezifischer SIMD-Matrizen im Compiler-Baum treibe die Wartungskosten enorm in die Höhe; schlanke Standardmodule und spezialisierte Third-Party-Wheels seien architektonisch sauberer.
  2. Grenzen der Speicherbandbreite unter Free-Threading: In einer Multithread-Umgebung stößt ein einzelner Kern mit 13 GB/s Durchsatz rasch an die Grenzen des Speicherbusses. Diskutiert wurde daher der abnehmende Grenznutzen weiterer Vektorisierung bei stark parallelen Workloads.

Sicherheitsrisiken im PyPI-Binär-Ökosystem: Diskrepanz zwischen Source und Prebuilt Wheels

• Resonanz: Hacker News-Thread (HN #50154823) und Analyse des Sicherheitsforschers Artem Golubin.
• Zentrale Streitpunkte: Die Diskussion beleuchtete eine strukturelle Schwachstelle in aktuellen Paketierungsabläufen: Die meisten PyPI-Sicherheitsprüfungen scannen ausschließlich den Quellcode in Quellpaketen (sdist). Angreifer können daher auf GitHub harmlosen Quelltext präsentieren, in die auf PyPI hochgeladenen Binär-Wheels (.whl) jedoch manipulierten Maschinencode einbetten.
  1. Verpflichtung zu reproduzierbaren Builds und Hosted CI?: Befürworter strengerer Sicherheitsstandards regten an, das direkte Hochladen lokal kompilierter Wheels schrittweise zu untersagen und stattdessen reproduzierbare Builds in vertrauenswürdigen CI-Pipelines mit kryptografischen Signaturen zu verlangen. Vertreter des Ökosystems wandten ein, dass Python auf extrem komplexe Cross-Compilation-Matrizen (C, C++, Fortran, Rust) angewiesen sei. PyPI verfüge nicht über die Infrastruktur, weltweite Build-Ressourcen kostenlos bereitzustellen, weshalb ein Verbot das Erscheinen wissenschaftlicher Pakete massiv gefährden würde.

---

🔭 Vorschau auf nächste Woche

• CPython 3.16.0 Entwicklung und WASI-Anpassung: Beobachtung der Code-Merges im Rahmen von PEP 11 für den Wechsel des WebAssembly-Ziels von wasip1 auf wasip3.
• Python Steering Council Wahlen 2026: Beginn des Wahlzeitplans gemäß PEP 8107; Nominierungsphase für die neuen Mitglieder des Leitungsgremiums.