Joe User wrote:Vielleicht ist es auch nur ein ganz perverser PR-Gag um diesen ungeliebten Codebereich endlich mal auditen zu lassen? Theo ist ja einiges zuzutrauen...
da bin ich noch gar nicht drauf gekommen :lol: \:d/
Mal bei Licht betrachtet gibt es allerdings an der Geschichte durchaus Ungereimtheiten. So vermute ich, dass eine Organisation wie das FBI das Risiko scheut, bei den Bürgern der USA als Schnüffelorganisation dazustehen (vor 9/11 kam das in den Staaten nicht so gut an). Bei einem Open Source Produkt hätte zumindest das theoretische Risiko einer Entdeckung bestanden. Sodann glaube ich weiter, dass das FBI schlau genug wäre, ein NDA nicht nur über 10 Jahre laufen zu lassen - bei Dingen, die die nationale Sicherheit betreffen, gelten in den USA normalerweise 50 Jahre. Außerdem ist das FBI als Behörde nicht gerade plausibel - für's Code knacken und für den Schutz der Regierungs-Kommunikation ist da drüben die NSA zuständig, nicht das FBI.
Joe User wrote:Ernsthaft: Ja, ich glaube stark daran, dass es solche Hintertüren in allen Betriebsystemen gibt. Sei es in Kerneln, Crypto-Frameworks, Security-Frameworks, Firmware, Compiler oder gar in den BIOS oder Hardware.
Ich bin zumindest nicht abgeneigt, das bei Komponenten zu glauben, die blind zig-fach kopiert und ins eigene OS eingepflanzt werden (man denke da z. B. an den IPv6-Stack von FreeBSD, der es in nahezu jedes OS geschafft hat). Auch Software, die von regierungsnahen Organisationen bereitgestellt oder "gespendet" wird (ich verweise hier noch mal auf SELinux) sind IMHO per se verdächtig, genauso wie nicht quelloffene Software mit hohem Verbreitungsgrad (wie etwa Windows) - hier wäre durchaus denkbar, dass die Regierung Deals mit dem Hersteller schließt.
Andererseits installieren sich viele User ohne mit der Wimper zu zucken lustig Trojaner und bestätigen das sogar noch mit akzeptieren der EULA (Beispiel
SecuRom).
Bei Hardware wiederum glaube ich das eher nicht - eine Implementierung wäre recht aufwändig, und bei der schnell fortschreitenden Entwicklung müsste da ständig nachgelegt werden (zumal Hardware-Komponenten eben nicht nur aus einem Staat, sondern mittlerweile aus vielen verschiedenen Ländern kommen). Nee, auf der Software-Seite geht das billiger und ist leichter zu verbergen.
Joe User wrote:Welche Regierungsorganisationen auf wessen Anordnungen in welchen Formen mit welchen Mitteln jeweils dahinter stecken, ist mir letztendlich so gar egal.
So weit würde ich jetzt nicht gehen - in einigen Produkten dürften die Backdoors gar nicht durch Regierungsorganisationen reingeraten sein, sondern eher durch den Marktforschungstrieb des Herstellers.
Joe User wrote:Open-Source schützt jedenfalls in keinster Form davor, sonst würden es ja erstrecht deutlich harmlosere Bugs nicht schaffen über Jahrzehnte hinweg unentdeckt zu bleiben...
Einerseits ja, andererseits gibt es bei Closed Source überhaupt keine Möglichkeit der Überprüfung. Bei Open Source sehe ich eher das Problem, dass ein Gutteil der heute produktiv genutzten FOSS-Software aus einer Spielerei oder Hobby-Bastelei entstanden ist, ohne Coding Guidelines, ohne Reviews und ohne Anspruch an gute Qualität.
Die wenigsten Projekte, die wirklich stark gewachsen sind, hatten den A... in der Hose, sich das Herz (sprich: die ursprüngliche Code Base) rauszureißen und alles richtig sauber aufzuziehen. Bei bestimmten Programmiersprachen (insbesondere C/C++) ist dann eben verbuggter Code die Strafe für die Bequemlichkeit.
Und dann wäre da noch das Problem, dass Hobby- und Freizeit-Programmierer (in vielen Projekten immer noch die treibenden Entwickler) sich eben lieber mit der Implementierung neuer Features beschäftigen, als sich mit Code Reviews, Unit Tests, Memory Profiling und ähnlich langweiligem Kram zu befassen.
Kurzum: Viele FOSS-Projekte haben kein ordentliches Qualitätsmanagement, teils, weil sie so gewachsen sind, teils, weil sich einfach wenig Freiwillige für solche Aufgaben finden lassen. Um wieder auf das ursprüngliche Thema zurück zu kommen: Gerade OpenBSD ist für mich eines der wenigen Projekte, die relativ viel in Sachen Code-Qualität tun (durchgängiger Style Guide, Peer Reviews sind Pflicht, Dokumentation ist Pflicht). Sollte denen tatsächlich was durchgerutscht sein, dann gilt das mit großer Wahrscheinlichkeit auch für alle anderen großen FOSS-Projekte.