Rechtslage Patriot Act und Hintertüren

Soweit ich verstanden habe, können Patriot Act und, oder national security letter Anbieter unter US Recht zur Öffnung von Verschlüsselung zwingen, wobei der betroffene Anbieter zum Stillschweigen verpflichtet werden kann.

Was mich dabei besonders interessiert sind Linux Projekte, die zwar OSS sind, aber unter US Jurisdiktion fallen.

Dazu zählt sicher Red Hat, aber auch openSUSE. IIRC wird in der openSUSE Leap EULA darauf hingewiesen, dass die Distribution der Jurisdiktion des Staates Kalifornien unterliegt.

Bei diesem Projekt nachzufragen bzgl. eventueller staatlicher Eingriffe macht aber wenig Sinn, wegen der möglichen Auferlegung von Stillschweigen, s. national security letter…

Beim Patriot Act usw. wird ja meist an MS oder Apple gedacht, aber Linux Projekte unterliegen dem ja auch…

Gibt es da irgendeine Erfahrung oder Meinung bzgl. OSS Projekten, die US Recht unterliegen?

Für meine Begriffe beißen sich die Konzepte „open source“ und „backdoor“ - also sollte es eigentlich egal sein, wo auf der Welt der Sourcecode geschrieben und veröffentlicht wurde. Vorausgesetzt natürlich, Du kannst kontrollieren, ob die Binary, die Du verwendest, tatsächlich aus den angegebenen Sourcen stammt. Aber vielleicht ist das auch alles zu idealistisch gedacht :thinking:

Einige Projekte vermelden regelmäßig dass sie zu nichts gezwungen wurden. Bleibt die Meldung aus, dann weiss man Bescheid. Die dürfen zwar nichts von Zwangsmaßnahmen sagen, aber Schweigen dürfen sie.

Man muss auch zwischen Dienstanbietern und Software unterscheiden. Nutzt du einen Mail Anbieter, kann der gezwungen werden. Nutzt du DeltaChat mit dem Anbieter dann hat der nur die von DeltaChat verschlüsselten Daten. Und Delta hat nur den eigenen Code, und der ist offen :grin:

@nick Dein Wunsch wird doch von F-Droid erfüllt. Was du bei denen runterlädst, da stimmen Source und .apk überein. Leider verstehen das zu wenige Leute.

Stimmt - wird in deren eigener Doku gut erklärt:

https://f-droid.org/docs/Security_Model/

Um auf @Holzmichl als Threadstarter zurückzukommen: Intransparente Offenlegung scheint eher ein closed-source-typisches Problem zu sein, während es Lücken in jeder Art von Code geben kann, egal ob „closed“ oder „open“.

Das ist dann eine Frage geeigneter Gegenmaßnahmen, wie in dem Link oben beschrieben (Signierung usw.) oder eine Frage des Auditings. Ob die beschriebenen Gegenmaßnahmen Lücken à la Log4J oder XZ tatsächlich effektiv verhindern können, das steht auf einem anderen Blatt.