Zusammenfassung

Wheels verarbeiten Symlinks derzeit nicht gut und kopieren den Inhalt anstelle der Erstellung von Symlinks bei der Installation. Um Bibliotheken in Wheels ordnungsgemäß zu verteilen, schlagen wir eine neue Metadatendatei LINKS vor, um Symlinks auf plattformübergreifende Weise zu handhaben. Diese Spezifikation erfordert eine neue Hauptversion von Wheels, wie in PEP 777 diskutiert.

PEP Verschiebung

Dieser PEP wurde aufgeschoben, bis eine bessere Kompatibilitätsstory für größere Änderungen am Wheel-Format etabliert ist. Sobald eine Kompatibilitätsstory für Wheels etabliert ist, die abwärtskompatible Verhaltensweisen auf unauffällige Weise ermöglicht, sollten die folgenden Punkte in diesem PEP behandelt werden

• Fokussieren Sie dieses Thema erneut nur auf Symlinks für gemeinsame Bibliotheken auf POSIX-Plattformen, vielleicht gebunden an Plattform-Tags?
• Sollen die Symlinks als Dateiattribute im Archiv oder als LINKS-Datei materialisiert werden? Könnte es in RECORD kodiert werden?
• Klären Sie, dass dieser PEP nicht ausreicht, um für PEP 660 editierbare Installationen nützlich zu sein, da er nicht mehr plattformübergreifend sein wird.
• Beschreiben Sie das Fallback-Verhalten in Fällen, in denen Symlinks auf POSIX-Plattformen nicht verfügbar sind.

Motivation

Heute werden Symlinks in Wheels als Kopien von Dateien erstellt, da das zipfile-Modul in CPython aus Sicherheitsgründen keine Unterstützung für die In-Place-Bearbeitung von Symlinks bietet.

Dies stellt Probleme für Projekte dar, die große kompilierte Bibliotheken in Wheels versenden möchten, da sie entweder die Installationsgröße des Projekts auf der Festplatte erheblich erhöhen oder den Symlink weglassen und möglicherweise einige nachgelagerte Anwendungsfälle beeinträchtigen müssen.

Um eine Bibliothek zu versenden, die für die Laufzeitnutzung oder die Linker-Zeit-Bindung auf POSIX ordnungsgemäß geladen werden kann, sollte eine Bibliothek die Konventionen des POSIX-Stil-Loaders und Linker-Suchpfads befolgen. Die beiden Hauptdateinamen, die der Loader verwendet, sind der „soname“ und der „echte Name“. Der „soname“ ist eine Datei wie libfoo.so.3, wobei 3 eine Zahl ist, die erhöht wird, wenn sich die Schnittstelle der Bibliothek ändert. Der „echte Name“ ist eine Datei wie libfoo.so.3.1.4, wobei die zusätzliche Versionsinformation den Loader findet eine bestimmte Version einer Bibliothek ermöglicht. Schließlich sucht der Linker beim Kompilieren von Code, der gegen eine Bibliothek gelinkt wird, nach einem „Linkernamen“, der wie libfoo.so benannt ist. Eine detailliertere Beschreibung finden Sie in dieser Linux-Dokumentation zu Shared Libraries. Um alle Laufzeit- und Linker-Zeit-Anwendungsfälle vollständig zu unterstützen, muss ein Projekt alle 3 Dateien versenden. Normalerweise wird dies auf POSIX-Plattformen durch die Verwendung von Symlinks gehandhabt, sodass die Bibliothek nicht dreimal auf der Festplatte dupliziert wird.

Zurück zur Python-Paketierung: Es gibt viele beliebte Projekte, die Binärbibliotheken versenden, wie z. B. numpy, scipy und pyarrow. Andere dlopen-Bibliotheken in anderen Wheels, wie z. B. pytorch und jax. Diese Projekte verlassen sich derzeit auf eine einzelne Bibliothek im Wheel, aber dies kann dazu führen, dass der Linker die falsche Bibliothek findet, wenn Systembibliotheken mit einer verfügbaren „echten Namen“-Bibliotheksversion vorhanden sind.

Es gibt auch den potenziellen Vorteil, dass Symlinks in Wheels einfachere editierbare Installationen ermöglichen würden, indem einfach ein Symlink im Verzeichnis site-packages des Benutzers platziert wird, aber dieser PEP belässt dies als offene Frage, die in einem zukünftigen PEP untersucht werden soll.

Begründung

Um die 3 Hauptbenennungen einer Bibliothek zu unterstützen, die beim Laden und Verlinken von Bibliotheken auf POSIX verwendet werden, schlagen wir vor, die Unterstützung für Symlinks in Python Wheels hinzuzufügen. Um die erstellten Symlinks verfolgen zu können und potenziell andere Plattformen zu unterstützen, die POSIX-Symlinks möglicherweise nicht direkt unterstützen, schlagen wir die Verwendung einer neuen Wheel-Metadatendatei LINKS vor, die sich im Verzeichnis .dist-info neben METADATA, RECORD und anderen Metadatendateien befindet.

Die Verwendung einer LINKS-Datei ermöglicht eine plattformübergreifendende Nutzung von Symlink-ähnlicher Funktionalität. Unter Windows erfordern Symlinks entweder eine Gruppenrichtlinie, die dem Benutzer erlaubt, Symlinks zu erstellen (z. B. durch Aktivieren von Dev-Modus) oder Administratorrechte. Das bedeutet, dass Symlinks auf einigen Benutzersystemen möglicherweise nicht unterstützt werden. Durch die Verwendung einer LINKS-Datei können Installierer potenziell andere Methoden zur Handhabung von Symlinks verwenden, wie z. B. Junctions unter Windows, wo der Installer andernfalls fehlschlagen müsste.

Dieser PEP beschreibt auch Prüfungen, die Installierer beim Installieren eines aktualisierten Wheels durchführen müssen. Diese Prüfungen dienen dazu, Sicherheitsrisiken zu bewältigen, die durch die Erlaubnis von Wheels zur Installation von Symlinks entstehen. Weitere Informationen zur Bedeutung dieser Prüfungen finden Sie unter Sicherheitsimplikationen.

Spezifikation

my_package/libfoo.so.3.1.4,my_package/libfoo.so.3
my_package/libfoo.so.3,my_package/libfoo.so

Abwärtskompatibilität

Die Einführung von Symlinks würde eine Erhöhung der Hauptversion des Wheel-Formats erfordern. Das bedeutet, dass neue Wheels, die das neue Wheel-Format verwenden, bei älteren Installer-Tools einen Fehler auslösen würden, gemäß der Wheel-Spezifikation.

Bitte siehe PEP 777 zu „Wheel 2.0“.

Sicherheitsimplikationen

Symlinks können ziemlich gefährlich sein, wenn sie nicht sorgfältig behandelt werden. Ein einfaches Beispiel wäre, wenn ein Benutzer sudo pip install malicious ausführt und keine Schutzmaßnahmen vorhanden sind, dann könnte das bösartige Paket /etc/shadow überschreiben und den Passwort-Hash auf dem System ersetzen, was bösartige Anmeldungen ermöglicht.

Dieser PEP listet mehrere Anforderungen an Prüfungen auf, die von Installern für Symlinks in Wheels durchgeführt werden müssen, um sicherzustellen, dass Angriffe wie der oben beschriebene nicht stattfinden können. Das bedeutet, dass es **entscheidend** ist, dass Installierer diese Sicherheitsvorkehrungen sorgfältig implementieren und bösartige Nutzung bei der Paketinstallation verhindern.

Insbesondere **MÜSSEN** die folgenden Prüfungen von Installern durchgeführt werden:

1. Dass die Symlinks nicht außerhalb von Paketen oder Namespaces, die aus dem Wheel stammen, zeigen.
2. Dass die Symlinks nicht hängen (das Ziel existiert zum Zeitpunkt der Installation).
3. Dass die Symlinks nicht zyklisch sind, wobei nach einer bestimmten Prüftiefe angehalten wird, um Denial-of-Service-Anfragen zu vermeiden.

Beim Entfernen keine Symlinks folgen.

Wie man das lehrt

Endbenutzer sollten, sobald die Änderungen im Ökosystem angekommen sind, transparent die Vorteile von Symlinks in Wheels erfahren. Es ist wichtig, dass Installierer klare Fehlermeldungen liefern, wenn Symlinks auf der Plattform nicht unterstützt werden, und erklären, warum die Installation fehlgeschlagen ist.

Für Personen, die Bibliotheken erstellen, sollte die Dokumentation auf packaging.python.org die Anwendungsfälle und Vorbehalte (insbesondere Plattformunterstützung) von Symlinks in Wheels beschreiben. Andernfalls sollte dies transparent von Build-Backends genauso gehandhabt werden wie jeder normale Dateiname.

Referenzimplementierung

TODO

Abgelehnte Ideen

Offene Fragen

Frühere Diskussion

https://discuss.python.org/t/symbolic-links-in-wheels/1945/25

Urheberrecht

Dieses Dokument wird in die Public Domain oder unter die CC0-1.0-Universal-Lizenz gestellt, je nachdem, welche Lizenz permissiver ist.