OpenSource per P2P

Weitgehend alle Linux-Distributionen und BSD-Projekte verfügen über die Möglichkeit, Installationen und Updates diekt online durchzuführen. Hierfür werden idR projektspezifisch FTP-Mirror-Strukturen aufgebaut und verwaltet. Es gibt verschiedene Gründe, warum FTP-Mirrors nicht mehr zeitgemäß erscheinen oder vielleicht sogar eine Schwachstelle für die Verbreitung von Open Source Software darstellen könnte.

Aktuelle Situation

Die traditionelle Verbreitung von Sourcen und Binärpaketen sind FTP-Server, die jedes Projekt (z.B. Debian mit ftp://ftp.debian.org) anbietet. Um eine Lastverteilung und verbesserte Erreichbarkeit zu gewährleisten, werden FTP-Mirros gepflegt und meistens von öffentlichen Einrichtungen wie etwa Universitäten bzw. deren Rechenzentren (z.B. ftp://ftp.gwdg.de/, ftp://ftp.leo.org/) angeboten.

Aktuelles

ftp.leo.org

Der obige Absatz wurde am 27.11.2006 verfasst. Am 4.12.2006 berichtet intern.de über die Abschaltung von ftp.leo.org, nachdem dieser aufgrund von Personal- und Hardwaremangel geschlossen hat.

Artikel zum Thema:

• http://blog.xwolf.de/2006/12/04/rip-ftpleoorg/
• http://weblog.internet-pro.de/2006/12/aus_fr_ftpleoor.html

Risiken und Probleme

Es gibt verschiedene Schwachpunkte in diesem System, die sich aktuell noch nicht, aber vielleicht mittel- oder langfristig zu echten Problemen entwickeln könnten. Das könnten finanzielle, juristische oder technische Probleme sein.

Finanzielle Risiken

FTP-Mirrors werden oftmals durch die öffentliche Hand (indirekt) finanziert. Da OpenSource ansich gerade im akademischen Umfeld einen guten Ruf genießt, gibt es hier derzeit keine Probleme zu erwarten, denn die Infrastruktur ist "eh da".

Juristische Risiken

Auch wenn es derzeit noch harmlos scheint, durch Softwarepatente gäbe es erstmals ein unkalkulierbares juristisches und damit auch finanzielles Risiko:

In einer Rede auf einem Treffen der »Professional Association for SQL Server«

in der vergangenen Woche stellte Microsofts Chief-Executive-Officer Steve Ballmer klar:

Jedes Unternehmen, das in seinem Rechenzentrum Linux einsetze, verletzte Rechte von Microsoft.

Das scheinen erstmal markige Worte zu sein und FUD. Aber spinnt man den Gedanken weiter, könnte im Rahmen von Softwarepatenten folgendes Szenario entstehen:

Ein Böser Mensch, der die liebe OpenSource nicht mag, beginnt damit, diese systematisch anzugreifen. Man beginnt also damit im Kleinen, einzelne kleine Programme auf scheinbare Patentverletzungen hin zu untersuchen. Angenommen es werden bei der Aktion 100 kritische Pakete entdeckt, könnte eine Abmahnwelle starten, die sich gegen die Verbreitung der fraglichen Pakete richtet. Ein Anwalt wird beauftragt, alle Anbieter der 100 Pakete mit einer Abmahnung zu beglücken. Dank Suchmaschinen ist es kein Problem, alle Stellen zu finden.

Abgemahnt werden nun zB auch die Betreiber großer (öffentlicher) Mirrors. Die jeweiligen FTP-Admins bekommen einen Satz heiße Ohren und fangen an, ihre Mirror-Listen mit Filtern zu versehen. Vielleicht finden Prozesse statt, vielleicht wird dabei dem großen Bruder echt gegeben. Aushöhlungstaktik. Es wird vielleicht im Verlauf von Monaten eine Klagewelle laufen und die Anbieter von FTP-Mirrors müssen befürchten, dass sie die nächsten sein könnten.

Kein FTP-Admin kennt alle Softwarepakete, Lizenzen und Patente. Ein Anwalt muss nur eine Handvoll finden, der FTP-Admin müsste aber ALLE kennen. Daraus folgt ein potentiell unkalkulierbares Risiko. In dem Moment, wo mit einem lauten Knall der erste FTP-Mirror vom Netz geht, werden weitere folgen.

Technische Risiken

Ein Wurm könnte einen DDoS auslösen, der gezielt nach dem Muster ftp<nummer>.<laendercode>.<projektname>.org die Mirrorhierachie angreift, indem z.B. fortlaufend nutzlose Downloads gestartet werden. Die Folge wäre eine massive Überlastung aller/einzelner Mirrors, was zu Problemen bei der jeweiligen Infrastruktur führen kann und letztlich im Rahmen einer Schadensbegrenzung zur Abschaltung des/der Dienste führen könnte. EIne Risikoabschätzlung könnte mittelfristig ergeben, dass aus vorgenannten Gründen eine Wiederinbetriebnahme nur teilweise oder garnicht stattfindet.

Fazit

Durch seine hierachische Struktur ist die Verteilung und Verbreitung von OpenSource mehreren potenziellen Risiken (in der Zukunft) ausgesetzt. Im folgenden soll daher Überlegt werden, wie man verfügbare Technologien für alternative Verbreitungswege verwenden kann.

Anforderungen an ein alternatives System

Ziel soll sein, dass ein beliebiges Source oder Binärpaket schnell aufgefunden und mit der verfügbaren Bandbreite geholt werden kann.

• Schnelle Identifizierung
• Schnelle Auffindbarkeit
• Schneller Download

Identifizierung

Es ist heute gemeinhin üblich, dass Binärpakete wenn nicht mit SHA256, dann doch wenigstens mit MD5 geprüft werden. SHA256 ist verbreitet und die Gefahr einer Kollision ist nach heutigem Ermessen sehr gering. Durch Kombi[...]

Tools und Technologien

• RfC 6249: Metalink/HTTP: Mirrors and Hashes, Juni 2011
• Offizielle Webpräsenz „aria2”