Vertrauenswürdige Update-Bezugsquellen mit der Befriedigung von Grundbedürfnissen zu vergleichen

Eines der großartigen Dinge bei Freier Software ist, dass Menschen einfach ein funktionsfähiges Programm oder eine Programmbibliothek hernehmen und für sich anpassen können, wenn sie es für erforderlich halten. Jeder kann dazukommen, Fehler korrigieren sowie Verbesserungen einreichen und diese können leicht mit vielen Leuten, Projekten und Organisationen geteilt werden. Mit Vertriebssystemen wie Pythons pypi, gibt es einen Update-Kanal, über den zuverlässige Vertreiber Lösungen bereitstellen können, damit Abnehmer der Bibliothek leicht Aktualisierungen erhalten können. Spricht man über Update-Wege und Code, ist es unvermeidlich, auch über Menschen und Vertrauen zu sprechen. Ein Schlüsselelement ist die vertrauensvolle Beziehung zwischen dem Konsumenten und dem Maintainer. Das ideale Software-Verteilungssystem wäre eine verdeckte, zuverlässige Rohrleitung zwischen den Software-Vertreibern und jedem Endverbraucher.

Wenn wir über Code-Bibliotheken sprechen, stellt sich heraus, dass sich das natürliche Verhältnis vom Vertrauensverhältnis unterscheidet: Es besteht zwischen dem Konsumenten und der Bibliothek selbst, nicht den Maintainern. Ich nutze zur Bearbeitung von HTTP „Requests“, nicht @nateprewitt’s Fork. Mein setup.py beinhaltet eine Referenz zu 'requests', nicht zu den Maintainern, denen ich vertraue, die Bibliothek auf dem neusten Stand zu halten.

Es gab Fälle, in denen Bibliotheken übernommen und dazu verwendet wurden, Malware zu verbreiten. Oder ein weiterer Fall, in dem sich jemand anbot, eine populäre Library zu übernehmen und dann Malware in sie einschleuste. Wenn es wirklich einfach für Vertreiber ist, eine Bibliothek an Andere weiterzugeben, dann wird diese mißbraucht werden. Ist es zu schwer, sie weiterzugeben, dann werden viele wertvolle Bibliotheken aufgegeben werden oder es entstehen Forks. Die Notwendigkeit, nach Forks zu suchen, ist ein zusätzlicher Aufwand für den Verbraucher, idealerweise sollte es also immer einen vertrauenswürdigen Vertreiber geben.

Bei großen Projekten wie Requests oder Distributionen wie Debian gibt es Prozesse, die sicherstellen, dass neue Maintainer das Richtige tun. Es gibt auch viele kleine Programmbibliotheken, die sehr wertvoll sind. Zum Beispiel, apache_log_parser oder pymtp. In diesen Fällen ist der Aufwand ziemlich groß, einen sauberen Übergabeprozess an einen neuen Maintainer zu schaffen, verglichen mit der Gesamtleistung, die der Autor in diese Bibliothek steckte. Sonst könnte ein einzelner Maintainer entstehen, der nun mit weiterer Arbeit überhäuft wird.

In F-Droid geht es bei der Überprüfung von App Merge Requests, auch bekannt als fdroiddata, auch darum, zu überprüfen, ob sich die Vertrauensbeziehung ändert. Dies geschieht zusätzlich zum Sicherstellen, dass der neue Code funktioniert, es immer noch freie Software ist und alle Anti-Features ordnungsgemäß gekennzeichnet sind. Diese Überprüfung richtig zu gestalten ist wichtig, besonders wenn man bedenkt, dass in F-Droid viele Apps automatisch aktualisiert werden, ohne dass die Kernmitwirkenden sie überprüfen.

Alle Entwickler müssen sich dieser Fragen nach der Vertrauenswürdigkeit bei einer Reihe von Schlüsselstellen im Software-Entwicklungsprozess bewusst sein:

  • bei Ergänzung einer Bibliothek in einem Softwareteil
  • bei der Unterstützung eines neuen Maintainer, der vorhandene Software übernimmt
  • bei der Überprüfung von URL-Änderungen des Quellcode-Repositorys

Es gibt auch einige Überlegungen dazu, wie wir besser ausarbeiten, wem wir im Software-Aufnahmeverfahren vertrauen müssen. Ein interessantes Beispiel ist cargo-crev für das Rust-Ökosystem. Es bietet ein System zur Beschreibung und kryptographischen Verknüpfung mit vertrauenswürdigen Entwicklern und deren Überprüfung von Software-Paketen.