Datenschutz im digitalen Alltag

Damit Privates privat bleibt

Bild von 3dman_eu via pixabay / Lizenz: CC0 Creative Commons

Kommentar: Open Source Realitäten - Fallbeispiel EncFS

Wenn man eine Diskussion über die Vorteile von Open Source diskutiert kommt zuverlässig ein Beitrag, der die Möglichkeit zur Mitarbeit preist. Wenn man einen Vorschlag hat oder der ursprüngliche Autor keine Lust/Zeit mehr hat, kann einfach jemand anderes übernehmen. Faktisch entstehen aber viele Open Source Projekte in Gutsherrenmanier und in der Realität entstehen eher neue Projekte oder ein Forks.

Ein sehr gutes Beispiel für diese Probleme der Open Source Entwicklung ist EncFS. Dabei handelt es sich um eine - zeitweilig sogar mal "die" - Verschlüsselungslösung für Dateien, die besonders durch den massiven Ausbau von Cloudspeichern an Popularität gewonnen hat. Die dateibasierte Verschlüsselungslösung eignete sich nämlich hervorragende für den Cloudeinsatz. Das kommerziell höchst erfolgreiche Boxcryptor integrierte den EncFS-Menchamismus in seine Windows-Lösung, weshalb man auch von Linux aus auf mittels Boxcryptor verschlüsselte Ordner zugreifen konnte.

Diese Erfolgsgeschichte endete mit einem Audit im Januar 2014, der gravierende Sicherheitsmängel, vor allem im Cloudeinsatz aufzeigte. Der Entwickler sieht sich momentan (und das sind nun auch schon mehr als 4 Jahre) außerstande die immer noch bestehenden Sicherheitslücken zu schließen.

EncFS war 2014 eine wichtige Software mit einem hohen Verbreitungsgrad. Nach dem verbreiteten Open Source Argument hätten sich nun Entwickler finden müssen, die dem Originalautor beispringen und die Probleme beheben. Das ist jedoch nicht geschehen. Stattdessen wurden zahllose Alternativen aus der Taufe gehoben. Die populärsten freien Projekte heoßen CryFS, Cryptomator und Gocrypt. Letzteres empfiehlt quasi sogar der EncFS-Entwickler.

Jetzt könnte man sagen, dass doch alles gut sein. Die Open Source Gemeinschaft hätte doch alternative und sichere Projekte aus der Taufe gehoben. Dabei unterschätzt die Gemeinschaft aber permanent zwei wichtige Punkte. Erstens möchten die meisten nicht dutzende Alternativen mit dem gleichen Zweck ("Cloud-Verschlüsselung") haben. Sie möchten eine gut funktionierende Variante, die ihnen durch eine Suchmaschine ihrer Wahl als Lösung angeboten wird, ohne tagelange Recherche nach Audits und Vor- und Nachteilen. Zweitens unterschätzt die Open Source Gemeinschaft permanent die Bedeutung eines etablierten Namens für das Marketing. Spätestens durch Boxcryptor kannten viele EncFS und es war leicht dazu Tutorials und ähnliches zu finden. Es funktionierte außerdem betriebssystemübergreifend und integrierte sich durch Drittprojekte in alle Desktopumgebungen. EncFS erschien als seriöse Lösungen. Die zahllosen alternativen Nachfolgeprojekte müssen alle wieder Bekanntheit erreichen, teilen den bereits relativ kleinen Markt unter sich auf und funktionieren meist nur auf einem Betriebssystem.

Open Source schafft es nur dann Entwickler für bestehende Projekte zu gewinnen, wenn diese professionell organisiert sind (z. B. in einem Verein oder einer Foundation) und das Projekt zu groß ist um eine Neuentwicklung sinnvoll erscheinen zu lassen. Bestehende Projektentwickler bemühen sich aber auch zu selten aktiv um einen Nachfolger, weil sie in Gutsherrenmentalität ihr Projekt als Eigentum begreifen. Man lässt das Projekt lieber sterben als es wegzugeben.

Die Partizipationsmöglichkeit und Nachhaltigkeit ist somit eher Theorie als Praxis. Letztlich müssen die Anwender bei Open Source die Entwicklersprünge meistens mit vollziehen. Der permanente Wechsel von einem sterbenden Projekt zum nächsten totgeweihten Unterfangen ist jedoch ermüdend.


Bilder:
Einleitungs- und Beitragsbild von 3dman_eu via pixabay / Lizenz: CC0 Creative Commons

"

Tags: Open Source, Verschlüsselung, Cloud, EncFS

Die Kommentarfunktion auf [Mer]Curius soll allen interessierten Leserinnen und Lesern einen Austausch ermöglichen. Kritische Meinungen zum Artikel selbst oder anderen Kommentaren sind ausdrücklich erwünscht. Gleichwohl werden Kommentare vor ihrer Veröffentlichung geprüft. Sie erscheinen daher nicht im unmittelbaren Anschluss nach dem Verfassen.


Die Angabe einer E-Mail Adresse ist optional und lediglich notwendig, wenn ein Abonnement zukünftiger Kommentare gewünscht ist.


Informationen zu verarbeiteten personenbezogenen Daten entnehmen Sie bitte der Datenschutzerklärung. Mit dem Verfassen eines Kommentars akzeptieren Sie diese Datenschutzbedingungen.

Lade Kommentar... Das Kommentar wird neu geladen in 00:00.
  • Dieses Kommentar ist noch nicht freigegeben.
    alex1702 · Vor 12 Tagen
    Ich gebe es ungerne zu, aber leider ist es wirklich so. Habe schon viele kleinere Projekte gesehen.

    Die sind mega cool, aber dann merkt man: oh..da wird gar nicht mehr entwickelt, meistens existiert schon ein issue "project dead?“ oder ähnliche.

    Leider fühle ich mich außerstande da einzuspringen. Einerseits weil mein englisch viel zu schlecht ist, was doch meistens gut wäre bei so Projekten und ich habe halt keine Ahnung von dem Projekt. Habe aber oft dieses innere Verlangen, komm das muss unterstützt werden.


    Ein Gegenbeispiel ist aber z.b. MediathekView, wo sich Gott sei dank Entwickler gefunden haben..mich eingeschlossen ^^
    Aber alleine hätte ich das nicht gestemmt. Liegt aber auch daran, dass das Programm größtenteils deutschsprechende Nutzer hat
    Ich hoffe, dass sich eventuell mal Vereine oder ähnliches bilden, welche solche Fälle besser abfedern können, die dem Hauptentwickler helfen können.
    • Dieses Kommentar ist noch nicht freigegeben.
      Cruiz
      • Administrator
      · Vor 12 Tagen
      MediathekView ist aber auch ein Gegenbeispiel, bei dem - wenn mich meine Erinnerung nicht trügt - der Entwickler ziemlich die Werbetrommel gerührt hat um einen Nachfolger zu finden. Das passiert leider nicht oft, viele lassen die Projekte einfach langsam sterben.
  • Dieses Kommentar ist noch nicht freigegeben.
    Prov94 · Vor 12 Tagen
    Das kann ich bestätigen, es gibt einige tolle Projekte, wo aber entweder der Entwickler keinen Bock mehr hat, es an einer richtigen Dokumentation mangelt oder dieser einfach ein sozialer Arsch ist und mit anderen nicht zusammenarbeiten kann.
    Für Open Source braucht es auch Projektmanagement und Koordination, das bringen nur wenige Projekte mit und daher sind viele einfach unstrukturiert.


    Das Problem ist, wie soll man jedem Projekt helfen? Ich habe (hatte) mir vorgenommen jeden Freitag ein Projekt das mir zu sagt raus zu picken und dort für den Tag zu helfen; leider kommt immer was dazwischen und man kommt nicht dazu. Hinzu kommt dann der Aspekt, das es am Ende eh niemanden interessiert und man die Zeit auch mit sinnvolleren Sachen wie einer MOOC Weiterbildung verbringen könnte.
    Open Source soll ja allen Zugute kommen, aber Mensch, wenn der Staat mir wenigsten Mindestlohn oder pro Tag 10€ zahlen würde für den Einsatz (Als gebe es nicht genug Entwicklermangel in Deutschland), dann würde ich mehr Zeit dort investieren.
    Mein letzter Commit war für phpservermon, eine Web App um verschiedene Serverdienste zu überwachen. Leider gab es bis dato kein Update mechanismus, also habe ich selbst einen in bash script geschrieben, damit man nicht manuell eventuell was falsches löscht.
    Hier wurde die Lösung auch angenommen und der Pull request befindet sich in der review.

    Anders hingegen bei https://github.com/Pryx/server-status/, dort gibt es auch keinen Update mechanismus und ich habe mein script aus dem anderen Projekt vorgeschlagen, der Hauptentwickler wolle aber eine PHP Lösung haben, und da ich so tief in PHP noch nicht drin stecke, soll er es doch selbst machen. Wer sich ein Wunschkonzert wünscht, soll es selbst organisieren.
    Und da sieht man dann, wenn hilfe abgelehnt wird; klar, bash script in einer PHP Anwendung ist nicht wirklich nice, aber es ist eine Übergangslösung bis die richtige fertig ist.

    Bei den Forks ist das Problem das gleiche, man weiß nicht welcher jetzt aktuell wirklich weiter entwickelt oder nur modifiziert wurde.
  • Dieses Kommentar ist noch nicht freigegeben.
    dududu · Vor 11 Tagen
    Schön wären hier noch ein paar positive Beispiele, die es sicher gibt.
    • Dieses Kommentar ist noch nicht freigegeben.
      Cruiz
      • Administrator
      · Vor 11 Tagen
      Alle positiven Beispiele, die mir spontan einfallen, sind in größeren Projekten organisiert. Da funktioniert der Übergang zumindest meistens.
  • Dieses Kommentar ist noch nicht freigegeben.
    fatabbot · Vor 6 Tagen
    Jetzt stellt sich aber doch etwas die Frage, warum beim gewählten Beispiel EncFS gerade die Entwickler der Alternativen statt an ihrer offenbar funktionierenden Software am Fix einer Software, zu dem sich deren Autor selbst sich nicht nicht in der Lage sieht, mitarbeiten sollten.

    Das hat halt auch etwas mit effektiven Zeiteinsatz der Beteiligten zu tun.
    • Dieses Kommentar ist noch nicht freigegeben.
      Cruiz
      • Administrator
      · Vor 6 Tagen
      EncFS ist deutlich älter als jede der alternativen Softwareprodukte. Die Entwickler der Alternativen haben sich also immer bewusst zur Neuentwicklung entschlossen anstatt zur Mitarbeit an EncFS.
  • Dieses Kommentar ist noch nicht freigegeben.
    fatabot · Vor 6 Tagen
    Das Fazit des letzten Satz ist durch den ersten nicht belegbar. Woher genau weißt du, dass keiner dieser Entwickler sich vorher den Code von EncFS angesehen hat und ggfs. zu seinen eigenen Schlüssen gekommen ist?
    • Dieses Kommentar ist noch nicht freigegeben.
      Cruiz
      • Administrator
      · Vor 6 Tagen
      Ich habe nie behauptet, dass sie sich den Code nicht angesehen haben. Ich kann aber durch die Tatsache, dass diese neuen Softwareprojekte existieren belegen, dass sie anstelle an EncFS zu partizipieren lieber ihr eigenes Ding gemacht haben.
  • Dieses Kommentar ist noch nicht freigegeben.
    fatabbot · Vor 6 Tagen
    Nein, du kannst dadurch nur belegen, dass es die anderen Programme gibt. Du kannst durch deine Argumente genauso wenig belegen, dass die Entwickler nicht an EncFS partizipieren wollten, sondern ohne dies zu versuchen (aka sich den Code anzusehen), wie ich belegen kann, dass sie dies getan hätten.

    Das ist alles reine Spekulation, sowohl von dir wie auch von mir. Du stellst es aber als Tatsache hin.
    • Dieses Kommentar ist noch nicht freigegeben.
      Cruiz
      • Administrator
      · Vor 6 Tagen
      Wenn du den Artikel gelesen hast und den Link gefolgt wärst, hättest du eine Diskussion gefunden, in welcher der Entwickler von gocryptfs seine Motivation etwas neues zu schaffen darlegt: https://github.com/vgough/encfs/issues/314


      Dazu hat er sich natürlich EncFS angesehen, aber sich dann entschieden etwas neues unter einem neuen Namen mit ihm als Projektleiter.


      Dazu gab es sicher gute Gründe aber es zeigt mal wieder, dass Staffelübergaben in der Open Source Welt selten klappen. Die Idee irgendjemand würde sich eines toten Projektes annehmen nur weil der Code offen daliegt ist eher theoretischer Natur. Bestenfalls lässt man sich davon inspirieren.

      Das führt dann zu folgendem:
      "Letztlich müssen die Anwender bei Open Source die Entwicklersprünge meistens mit vollziehen. Der permanente Wechsel von einem sterbenden Projekt zum nächsten totgeweihten Unterfangen ist jedoch ermüdend."
  • Dieses Kommentar ist noch nicht freigegeben.
    fatabbot · Vor 2 Tagen
    Kurz gesagt: Er hat das gemacht, was ich vermutete. Code angesehen und entschieden, dass das nicht seins ist.

    Was sein gutes Recht ist, wofür soll er da seine Zeit verschwenden? Hat weder er etwas davon noch die User.
    • Dieses Kommentar ist noch nicht freigegeben.
      Cruiz
      • Administrator
      · Vor 2 Tagen
      Und es bestätigt das Grundproblem von Open Source bzw. widerlegt die alte Mär, dass der Code weiterentwickelt wird wenn der ursprünglich Projektleiter abtritt. Frei nach dem Motto: "Der Code ist ja offen und jeder kann mitarbeite..." Bestenfalls lässt man sich inspirieren, aber der Anwender muss so und so von einem Projekt zum nächsten hüpfen.
Schreibe etwas...
Sie sind Gast
oder als Gast schreiben
  • Betriebssystem wählen

    Das Betriebssystem mit dem Desktoprechner, Notebooks und Mobilgeräte wie Smartphones und Tablets betrieben werden, dient einerseits als Grundlage jeder weiteren Weiterlesen
  • Daten verschlüsseln

    Verschlüsselung von Daten ist eine der wichtigen Erstmaßnahmen um Datenabfluss zu vermeiden. Externe Festplatten oder Speichermedien kann man verlieren, Notebooks Weiterlesen
  • Kommunikation schützen

    Im Zuge der Digitalisierung haben sich auch die Kommunikations-Kanäle vervielfältigt. Videotelefonie, Instant Messenger, sowohl für den Desktop, als auch im Weiterlesen
  • Anonymisierung

    Anonymität gehört im Zeitalter von Werbetracking und Bestandsdatenabfragen der Vergangenheit an. Mit einigen speziellen Programmen wie TOR oder spezialisierten Systemen Weiterlesen
  • 1