Wie "Protestware" und sonstigen Verseuchungen bei abhängigen Paketen begegnen?

[buhtz]

Pakete und Komponenten von denen die eigene Software abhängig ist, können mit neuen Versionen "gewisse Probleme" mit sich bringen. Das kann Protestware (node-ipc.js) sein, bei der plötzlich politische Meinungen ähnlich wie Werbung eingeblendet werden. Es kann bösartiger Code drin sein, wie bei diesem politisch motivierten Beispiel (ebenfalls node-ipc.js), bei dem die Systeme eines bestimmten Landes lahm gelegt werden sollen. Oder eine Komponente wird einfach unbrauchbar gemacht (color.js) weil der Maintainer auf unfaire Behandlung aufmerksam machen möchte.

Es soll hier nicht um die Bewertung dieser Events und Phänomene und dessen Auswirkungen gehen, sondern darum, wie FOSS Enwickler*innen darauf reagieren, um die eigenen User davor zu schützen. Mir ist auch klar, dass es kein neues Thema ist, dass man sich mit neuen Versionen auch neue Probleme holt.

Meine Erfahrung im Deployment hält sich in Grenzen, weswegen ich auf eure Gedanken sehr gespannt bin.

Meine bisherige Idee wäre, nicht mehr die Version nach oben hin offen zu lassen (required = externes_paket >= 3.0), sondern die Version zu fixieren (required = externes_paket == 3.0).

So steht man aber natürlich vor der Notwendigkeit, selbst neue Versionen der abhängigen Komponenten im Auge zu behalten und ggf. zu "prüfen" oder wenigstens ein wenig abzuwarten, bis die neuste Version etwas "abgehangen" ist und keine schweren Fehler gemeldet wurden, bevor man diese in der eigenen Anwendung nutzt.

Der Vorgang ließe sich auch mit einem Script oder gar unittest automatisieren. Irgendwo in den Sourcen (bei Python z.B. setup.cfg oder älter in setup.py) stehen ja die gewünschten Versionen der abhängigen Pakete. Im unittest kann man diese mit externen Quellen, wie das upstream repo, PyPi & Co oder dem Debian repo abgleichen und ggf. eine Exception werfen, sobald eine neue Version verfügbar ist. Wenn ein unittest zu "hart" ist, kann man das auch mit einem Script machen, dass dann neu Meldung wirft oder ne Mail schreibt.

Was sind eure Gedanken dazu?

[eggy]

Meine bisherige Idee wäre, nicht mehr die Version nach oben hin offen zu lassen (required = externes_paket >= 3.0), sondern die Version zu fixieren (required = externes_paket == 3.0).

Danke, nein. Den Spaß hatten wir so ähnlich nämlich schon mal, auf Windows um die Jahrtausendwende, nannte sich dll-Hell.

[buhtz]

Die Verbindung zur dll-Hell erschließt sich mir nicht.

Ich will Nutzer ja nicht zwingen mehrere Versionen einer Bibliothek zu haben. Sondern es geht mehr darum den Entwickler über neue Versionen zu informieren, entweder durch fehlgeschlagene unittests oder durch Nutzer die ein Ticket öffnen, weil eine Abhängigkeit nicht erfüllt werden kann.

[eggy]

Stell Dir vor, Du hast A und B die jeweils C in Version "alt" erfordern.
Jetzt kommt ne neue Version von B, B will C in Version "neu"
Fall 1, es darf immer nur ein C geben:
Du installierst das neue B. C wird aktualisiert. A's zwingende Abhängigkeit auf C kann nicht mehr erfüllt werden. A kann nicht mehr installiert werden. Falls A bereits installiert ist, wird A entfernt, da es ohne C nicht laufen kann, und C.alt grade gelöscht wurde um C.neu zu installieren.
Fall 2, es darf mehrere C geben:
A ist installiert, C.alt auch. Du installierst B. B braucht C.neu, also wird auch C.neu installiert. Nun gibt es C.alt und C.neu. Jetzt kommt noch D dazu, das braucht C.neuer, und E C.nochneuer, F will dann C.nochvielmehrneuer. Innerhalb von nen paar Monaten hast Du x verschiedene Versionen von C auf dem Rechner, ein paar mit Sicherheitslücken, ein paar ohne, welche welche sind, keine Ahnung.
Beide Fälle waren "damals" nen riesen Problem: entweder hattest Du schrottige Libs rumfliegen und/oder konntest nicht A und B gleichzeitig auf der Kiste haben, weil C meinte, es darf nur einen geben.

Du brauchst die Entwickler nicht auf die Art wegen neuer Abhängigkeiten zu informieren, es reicht schon, dass der Maintainer der Lib das auf dem Schirm hat. Und dafür gibt's "watch"-Files (siehe Maintainer Guide). Fast alle anderen brauchen sich nicht kümmern, weil eine der Regeln in Debian ist, wenn immer es geht: nicht statisch linken! Ein paar Sachen sind davon ausgenommen, aber da wissen die Leute auch warum sie das machen, und welche Implikationen das hat.

Für alle, denen "statisch linken"/"dynamisch linken" nichts sagt, vereinfacht gesagt bedeutet
statisch: der Code aus anderen Projekten wird beim Compilieren einmal fest in das fertige Produkt übertragen, es bleibt also für immer in dem Zustand, in dem es zu dem Zeitpunkt des Bauens war. Aktualisiert Du die Lib, musst Du neu bauen, damit die Änderungen auch im Programm ankommen.
dynamisch: beim Start des Programms wird die Lib mit dem Code dynamisch nachgeladen, immer in dem Zustand, in dem die Lib gerade auf dem System rumliegt. Aktualisierst Du die Lib, brauchst nichts weiter tun als das Programm neu zu starten (vorausgesetzt, API/ABI ändern sich nicht zu sehr, und das passiert selten ohne Majorversionssprung und darauf wird häufig von den Maintainern geprüft, das fällt schnell auf).

[TRex]

Also wenn dein Setup ausreichend groß ist, und das ist jedes Projekt mit react (js) automatisch, kannst du nicht mehr jedes Paket einzeln überprüfen. Was du dann tun kannst, ist wahlweise nur noch Pakete aus ner Distribution verwenden oder:

1. deine direkten Abhängigkeiten nur noch exakt einbinden, wie du es vorgeschlagen hast (npm: kein ^ in der Versionsangabe)
2. renovate oder ähnliches konfigurieren (https://github.com/renovatebot/renovate, falls es jemand übersehen hat - man kann das selbst betreiben - erfordert aber n bisschen mehr als ein git-Verzeichnis - evt kennt noch jemand was kleineres), um die Versionen kontrolliert hochzuziehen
3. jedes Update überprüfen (eyeballing, Unit-Tests, Oberflächentests...)

Was das Problem mit dem Ansatz ist: dank UAParser und Konsorten wissen wir, wie fragil die NPM-Welt mit ihren drölfmillionen Paketen ist, und ein Ansatz wie renovate zieht eben immer das neueste. Was du jetzt als Nahrungsergänzungsmittel dazustellen kannst, ist irgendein Tool zum Überprüfen von CVEs und renovate so konfigurieren, dass er ein paar Tage wartet, bevor er ein Paket installiert. Das hilft aber nicht, wenn a) deine transitiven Abhängigkeiten den Mist automatisch reinziehen oder b) du den Updateprozess lokal umgehst.

Ist modernes Frontend nicht spaßig?

@eggy: https://docs.npmjs.com/cli/v6/configuri ... rs#example npm kann mit dem Problem umgehen, auch wenns nicht schön ist.

[JTH]

Ist modernes Frontend nicht spaßig?

Da lobe ich mir doch die C- und C++-Welt, in der es einfach keinen allgegenwärtigen Paketmanager gibt und man seine Abhängigkeiten noch gepflegt und unkompliziert komplett von Hand verwaltet (nicht ganz ernst gemeint)

[TRex]

Zähl mal durch. Kommst du auf vierstellig?

[wanne]

Da lobe ich mir doch die C- und C++-Welt, in der es einfach keinen allgegenwärtigen Paketmanager gibt und man seine Abhängigkeiten noch gepflegt und unkompliziert komplett von Hand verwaltet (nicht ganz ernst gemeint)

Ich finde das trotz allem Gelächter richtig. Üblicherweise hängen meine Programme von der stl und libcurl+openssl oder so ab. Damit kann man extrem viel erreichen. Überall gibt es wenige feste Maintainer die die Gefahr für solche Aktionen massiv reduzieren. Ganz andere Sache wie bei javascript wo man mal eben für ein kleines Progrämmchen mehrere 100 unterschiedlichen Entwicklern abhängt. Gleiches gilt für Java vs. Java EE/mvn-Projekte.