Ich begrüße die Freundinnen und Freunde der Diskussionsrunde !!

Mit seinem Threat »Passwortmanager gesucht (Alternative zu 1Password)« hat penumbra eine ganz andere Frage gestartet. System 6.0.1 stellte jedoch folgende Frage aufgegriffen – siehe unten. Ich dachte mir, damit das nicht OffTopic bleibt und zumal auch mich das wirklich interessiert, ich mach das anders und schreibe nicht darein. Damit da nicht alles durcheinander gewürfelt wird und es inhaltlich bei »Passwortmanager Alternativen« belibt.

Also. Ist OpenSource sicherer – oder bedankt sich die »Dunkle Macht« , dass ihr der SourceCode gleich komplett Freihaus geliefert wird?? Und wie läuft das ab, mit den ( angeblichen ) Revisionen?? Wer macht das? Kann nicht auch gerade durch »Revisionen« etwa Schadcode hinzugefügt werden??

Ich wünsche viel Spaß bei der Diskussion – und ein sonniges Wochenende, C.

Ein Angriffsvektor, welcher besonders in der Open-Source-Community SEHR populär ist, sind gekaperte Dependencies zu anderen Projekten. Wenn du dir mal anguckst, wie viele Abhängigkeiten ein z.B. PyTorch oder OpenCV hat, kann mir kein Mensch erzählen, dass da a ) noch irgendwer durchsteigt und b ) jede Änderung in jeder Abhängigkeit kontrolliert wird.

Wird EINE ABHÄNGIGKEIT gekapert im Paket-Manager, ist das ganze Projekt komplett kompromittiert. Man darf nie vergessen, dass das meist freiwillige Maintainer sind, die derartige Projekte verwalten – mit sehr unterschiedlichem Skill-Set und Sicherheitsbestreben.

Selbst wenn die Abhängigkeiten nicht das Problem sind greift natürlich das was Mendel Kucharzeck schon schrieb, nämlich unterschiedliches Skill-Set und Sicherheitsbestreben. Als ein Maintainer eines nicht genannten Projektes, passieren nunmal Dinge, die man in dem Moment einfach nicht im Blick hat. Da kann es, selbst wenn man immer versucht die Sicherheit im Blick zu haben, zu Fehlern kommen, die ein Außenstehender als "Dumm" bezeichnen würde. Wenn man ein Projekt in der Gruppe betreut, ist dies wieder eine andere Sache, weil es hier auch interne Feedbackkanäle gibt.
Und wenn man nun sein kleines Projekt hat, kann es natürlich sein, dass der eine oder andere User mal "dagegen tritt" und dich über ein Sicherheitsproblem informiert. Es liegt dann am Maintainer, ob er es totschweigt oder beseitigt und veröffentlicht.

Bei ClosedSource hat der User, der dagegen tritt, weniger Möglichkeiten, dem Hersteller zu kommunizieren, dass das Produkt unsicher ist, ohne die Angst im Rücken, von den Anwälten des Herstellers zu hören.

@Mendel: Da hast Du 100% recht. Aber das betrifft leider auch kommerzielle Closed Source Produkte und Projekte.
Niemand entwickelt alles in House, fast alle binden irgendwelche Libraries ein, und es waren in meiner Vergangenheit oft gerade kommerzielle Produkte für die es irgendwann keine Updates mehr gab oder wo eine im Hintergrund eingesetzte Library einfach vergessen wurde upzudaten.

Ich würde daher auf die Original Frage antworten: It depends.

Mendel
Das gleiche Problem hast du aber auch bei closed source. Die bedienen sich auch großzügig bei Open-Source und darüber hinaus kann man externe Dylibs auch spoofen (auch wenn CodeSigning das etwas aufwändiger gemacht hat). Wenn man sich beliebte Frameworks anschaut, wird das gut sichtbar. Da gibt es .Net, NodeJS, Electron (JS/TS) mit nativen Backends und auch in Swift wäre das denkbar.
Der Unterschied ist, dass in der Regel die OpenSource-Community sehr schnell auf solche Probleme reagiert und Abhilfe schafft. Bei ClosedSource kann das schon mal eine Weile dauern - oder es passiert nie. Es gab im Dezember ja erst so einen Fall in NodeJS. Updates zu OpenSource-Projekten kamen deutlich schneller als die für CloseSource - und auch die waren potentiell betroffen.
Das ist also kein Argument gegen OpenSource - der Umgang mit Bugs und Sicherheitsrisiken ist aber bei OpenSource deutlich besser.
Bei manchen Projekten beteilige ich mich auch und kann daher so manches abschätzen. Für VLC hatte ich einen Bugfix geteilt (Memory Leak bei Untertiteln), bei anderen Projekten (Scribus, Siril, ...) habe ich Bug-Analysen geteilt und mit den Entwicklern diskutiert oder wie bei Siril Erweiterungen erstellt, die natürlich dann auch OpenSource sind. Teilweise bekommt man Feedback innerhalb weniger Stunden - da ist von kommerziellen Anbietern noch nicht mal die "Vielen Dank für ihre Nachricht" angekommen.

Man darf aber FOSS (Free and Open Source Software) nicht als Selbstbedienungsladen verstehen. Ja, man muss nichts bezahlen (aber man kann), aber man sollte sich doch auch an solchen Projekten beteiligen. Jeder eben in dem Maß, das er kann.

Auf der anderen Seite ist aber Transparenz bei FOSS überwiegend geboten. Natürlich nicht immer - siehe Visual Studio Code, welches ja sehr beliebt ist. Da steckt die Telemetrie nicht im OpenSource-Teil sondern in den Frameworks, die Microsoft beim Bauen verwendet. Also die Code-Basis ist sauber, aber die Binaries, die man bei Microsoft laden kann, sind "verseucht". Zum Glück gibt es da aber Codium. Gleiche Code-Basis aber eben ohne das Telemetrie-Zeug von Microsoft gebaut.

Das Risiko bei ClosedSource ist daher, dass man nie kontrollieren kann, was die Software im Hintergrund macht, weil man den Code nicht prüfen kann. Man nehme das beliebte Affinity. Alle freuen sich, dass es nach der Übernahme durch Canva kostenlos ist. Da läuft aber im Hintergrund das "Snowplow"-Framework, dass stetig Daten an Canva schicken will. Ich hatte das bei mir mit LuLu blockiert und Hoppla - Affinity stürzte dann beim Beenden ab. Was da gesammelt wird, habe ich nicht weiter untersucht, aber es ist möglich, dass alle Daten und Dateien verarbeitet und übertragen werden, auf die Affinity Zugriff hat. Das Recht räumt sich Canva zumindest selbst ein - um ihre KI zu trainieren - ohne Opt-Out Möglichkeit. Affinity mag kostenlos sein, aber dieser Preis ist mir zu hoch.

Also das sind Sicherheitslücken und datenschutzrelevante Probleme, die in gleichem Maße besorgniserregend sind. ClosedSource hat also erstens die gleichen Sicherheitslücken und zweitens ist nicht überprüfbar, ob die Software selbst "sauber" ist. Wenigstens letzteres spricht für OpenSource.

Grundsätzlich ist OpenSource Software weder sicherer noch weniger sicher als ClosedSource - bei OpenSource kann ich aber, zumindest theoretisch, den Sourcecode kontrollieren und mir selbst ein Binary erstellen - ohne Sourcecode bin ich auf den Hersteller angewiesen. Ich arbeite seit über 20 Jahren in der Softwareentwicklung - was ich da an kommerziellen Produkte gesehen habe, die ohne Sinn und Verstand externe Abhängigkeiten einbinden... Es ist halt unglaublich einfach irgendwelche Libraries über NPM, Maven, Nuget, etc. einzubinden.

Nicht zu vergessen: das moderne "Vibe-Coding". Klar klappert die KI das im Internet gesammelte Wissen (meist OpenSource Projekte) ab und schreibt dann den Code - nur wird das dann oft von "Entwicklern" benutzt, die keine Ahnung haben, was die KI da produziert (und welche Dependencies da drin stecken).
Traurig - aber ich hatte einen Fall, wo ein Kollege mit AI ein Feature einbauen sollte - also AI war Teil der Aufgabe (die Firma will das so - kopfschüttel). Ich hatte da dann im Code-Review was entdeckt und kommentiert (inkl. Lösungsvorschlag). Leider hatte der Kollege entweder den AI-Code oder meinen Kommentar nicht verstanden. Er hat einen Rollback gemacht...

Was allerdings mittlerweile relativ gut funktioniert ist der "BugBot", der jetzt in unserer Git-Umgebug zur Verfügung steht und bei Code-Reviews/Pull-Requests helfen kann.

Die Fragestellung ist so nicht sinnvoll, denn es wird suggeriert, es würde auf für einen komplizierten Sachverhalt eine einfache Antwort geben.

Die Grundidee ist: Da Open Source in der Regel von viel mehr Leuten begutachtet werden kann, als andere Software, ist die Wahrscheinlichkeit höher, dass Fehler, inklusive Sicherheitsfehler, gefunden werden. Deshalb ist Open Source im Mittelwert sicherer.

Das hat aber überhaupt keine Aussagekraft für einen konkreten Einzelfall. Im Mittel rentiert es sich auch niemals, an einem Glücksspiel teilzunehmen. Trotzdem gibt es Lottomillionäre.

Ein Punkt der gerne bei ClosedSource vergessen wird: Stirbt die Firma, stirbt das Programm/Resourcen.

Ich habe diese Woche einige alte Software-Lizenzen überprüfen wollen (gängige Programme im Mac-Bereich aus den letzten 20 Jahren) und unbeschädigte Installer gesucht. Erschreckend viele Firmen oder Einzelkämpfer sind nicht mehr zu finden. Aus finanziellen oder biologischen Gründen.

Vielen Dank! (Hätte ich eigentlich auch so machen können.)

Die Fragestellung sollte noch präzisiert bzw. die Ausgangslage / das Ausgangsverständnis klarer gemacht werden. Denn der Begriff Open Source ist schon länger verwässert und wird inflationär (im Sinne von Marketing-Gelaber) genutzt.

Das originale Verständnis bzw. Grundgedanke sollte nachwievor die Auslegung des FSF sein: , welche sich durch genutzte Abkürzungen im Alltag
wie FOSS (alternativ auch FLOSS ) manifestiert hat.

Hierzu auch ein Artikel vom FSF: "Warum „Open Source“ das Ziel Freie Software verfehlt"

Es gibt Projekte / Firmen, die nur einen Teil opensourcen (und das sich marketingtechnisch auf die Fahne schreiben), aber (relevante) Bestandteile auslassen, die zum Betrieb insgesamt erforderlich sind. So was ist dann nicht wirklich Open Source.

Dann die wichtige Frage der Lizenzen. Einige opensourcen - teils ohne Nennung einer Lizenz (und sind damit streng genommen auch wertlos) - teils gegenüber dem FSF-Gedanken mit inkompatiblen Lizenz-Arten - das ist dann auch nicht Open Source. Die in den letzten Jahren aufgekommenen BSL-artigen Lizenzen werden auch nicht als solche vom FSF anerkannt.

Wenn also ein Projekt / Produkt noch aus proprietären Bestandteilen aufgebaut ist, sollten solche Software-Lösungen aus dem Kontext der Fragestellung rausfallen bzw. gänzlich als proprietär angesehen werden.

Zusätzlich zu Marcels Punkt:

"KI" in der Softwareentwicklung ist ein ziemlich kontroverses Thema, ich persönlich neige dazu, mich solchem Code äußerst skeptisch zu nähern. Ohne gründliche Prüfung betrachte ich "KI"-Code wie solchen von bislang unbekannten menschlichen Programmierern: Bis zum Beweis der Unschuld als schuldig zu betrachten.

"KI" in der Schwachstellenanalyse hingegen ist ein ganz anderes paar Schuhe: Hier ist der breit gestreute Ansatz, den Machine Learning-Systeme prinzipbedingt fahren können, ein echter Vorteil. Code auf Schwachstellen zu untersuchen ist eine der Stärken von ML, und das sowohl von außen (also am fertigen System, im Sinne von Pentests) als auch, wenn die Sourcen vorliegen, von innen, eben auf Basis des Sourcecodes.

Hier liegt also zumindest das Potential gründlicher maschineller Auditierung, und die kann allemal umfassender und schneller sein als manuelle Codeeinsicht. Und da genau ist zumindest eine Chance gegeben, Open Source deutlich besser zu auditieren als Closed Source. Wenn das denn ordentlich passiert - denn die Geschichte hat auch eine Schattenseite.

Vor etwa einem Jahr beendete der Hauptentwickler von curl, Daniel Stenberg, sein Bug Bounty-Programm aufgrund zahlreicher fehlerhafter ("AI Slop") Fehlermeldungen von "KI"-Systemen, die ihn sinnlos beschäftigten:

In einem Update hierzu hat er bestätigt, daß die "KI"-Fehlermeldungen an Qualität zugelegt haben, aber die schiere Anzahl ihn vor die Herausforderung stellt, jeder einzelnen nachgehen zu müssen, was einen erheblichen Zeitaufwand darstelle. Prinzipiell also eine gute Entwicklung, die aber einen Einzelentwickler immer noch an die Grenzen der Belastbarkeit bringen und das Projekt so gefährden kann.

Langfristig sehe ich das durchaus positiv, zumal das Ausmerzen von Sicherheitslücken ohne Frage Priorität vor anderen Aufgaben in der Softwareentwicklung hat.

Wenn sich Deine Antwort auf meine Eingangsfragestellung bezieht, sehe ich das anders. Ich habe die Grundthematik von System 6.0.1 aufgegriffen. Mir ging und geht es einfach darum selbiges mal zu beleuchten – daher auch mein ( fiktives ) Beispiel der »Dunklen Macht« die mitliest, verändert etc.

An Deinem Einwand stört mich jedoch konkret, dass er im übertragenden, verallgemeinten Sinn jedes Handeln abdeckt – und gutheißt. Ja, im Mittelwert ist Lottospielen »umschlau« und ja, es gibt Lottomillionäre. Die gleiche Argumentation könntest Du umgedreht auf Tesla und autonomes Fahren anwenden und ebenfalls mit einer »übergeordneten Sichtweise« argumentieren. Aus der heraus sind die tödlichen Unfälle durch Fehlfunktionen der Computer des autonomen Fahrens bei Tesla, bezogen auf das Gesamt-Konstrukt aller autonomen Fahrten, zwar die Ausnahme und tragisch, aber eben bezogen auf alle Fahrten ( oder die Summe aller Menschen ) nur eine Randerscheinung. Das löst ja aber nicht das Problem!
( Das Tesla-Beispiel kommt hier her . SEHR SEHR SEHENSWERT !!! )

Ja, die Idee, dass durch viele Auge Fehler schneller und besser erkannt werden ( können, wie Du selbst schreibst ) und eine Möglichkeit besteht diese zu beheben ( beheben zu können ), sehe ich ebenso wie Du ( oder dem Gedanken, der OpenSource zu Grunde liegt ). Aber ob es so geschieht, ist ja nicht gesagt: siehe ssb.

Und wer sagt denn, dass eben genau das nicht ausgenutzt wird?? Ich muss mühsames Decomplieren einer Software anstellen, wenn ich den kompletten Source Code durchlesen kann ?? Danke, aber Nein Danke.

Und ja, natürlich weiß niemand, was für Schindluder in den ( nicht ) kommerziellen Programmierbuden dieser Welt getrieben wird… Sind alle Apps im Apple App Store denn sicher ??? ) Weiß irgendwer, ob selbst Apple, Microsoft, SAP oder oder oder nicht auch bewußt – als Beispiel!! –  Spionagetools einbauen ??? Oder Oder Oder ??? Nein, keine Verschwörungstheorie, nur ein überzeichnetes Beispiel.

Ja, mit OpenSource habe ich die Möglichkeit das überhaupt zu überprüfen. Aber ich müsste letztendlich sogar selbst alles lesen, alles verstehen und alles kompilieren – in einer sicheren Umgebung, die keine Fehler einbaut . Ja, übertrieben ausgedrückt !!

Und daher, schlussendlich, bleibt die eben nicht triviale Frage ohne einfach Antwort… Also, meiner Meinung nach…

Die grundsätzliche Idee von OpenSource – bspw. ja auch bei wikipedia –, dass alle sehen dazu beitragen etc. ist super. Aber macht es das wirklich sicherer, wenn es um eine einzige App geht?? Benötigt man nicht einfach eine »kritische Masse« – bspw. Linux –, so dass aus der schieren Menge der mitlesenden Augen wirklich Fehler eliminiert werden? Damit wäre dann – zumindest bei kleinen Projekten – OpenSource »mehr Augenwischerei«??

Ach, herrlich kompliziert…

Happy Weekend schon mal, C.

Security by Obscurity gilt in der Sicherheitsbranche als nicht geeignetes Konzept, um Sicherheit herzustellen. Daher darf es keinerlei Rolle spielen, ob der Sourcecode frei verfügbar ist oder nicht.

Wenn man sich die Masse an Exploits anschaut sind es im wesentlichen immer die gleichen simplen Fehler, die passieren: Buffer over-/underflows, Zeigerfehler, Formatstringfehler, … . Durch KI wird man zukünftig automatisierte Audits durchführen können. Das Problem ist hier, dass einige Gruppen Vorteile habe, weil sie früher Zugriff auf diese Techniken haben, und so Audits durchführen können, um Exploits zu finden, und die eigentlichen Maintainer hier hinterher hinken.

Dann gibt es den Ansatz die Anzahl der Exploits durch geeignete Programmiersprachen strukturell zu verringern. Hier sei auf Rust verwiesen, oder auf das sehr viel längere existierende Ada mit der Teilsprache SPARK.

Das ist einer der Gründe, warum ich in meinen Kundenprojekten praktisch ausschließlich Open Source einsetze.

Neben dem Argument, daß ich bei Open Source gegebenenfalls im Sourcecode recherchieren kann, wenn es Fragen oder Probleme gibt, und wenn schnelle Lösungen gefragt sind eben auch Hand anlege und die Korrekturen wieder in das Projekt einfließen lasse, ist das das wichtigste.

Nein, Du bestätigst damit genau, was ich sage, nämlich dass der Anschein erweckt werden soll, es gäbe eine einfache Antwort.

Natürlich geschieht das sehr oft nicht, aber das ist ja in den Mittelwert eingerechnet. Deshalb ist die Frage unsinnig.

Niemand, deshalb musst Du die Frage anders stellen.

Nein, natürlich nicht. Das wird seit Jahren diskutiert und jeder, der sich informiert, weiß, dass das nur Marketing-Propaganda von Apple ist.

Genau das habe ich gesagt, aber Du hast es nicht verstanden.

Da bin ich mir eben auch nicht mehr sicher.
In einem professionellen Software-Unternehmen gibt es (hoffentlich) Testverfahren, automatisierte und manuelle Code-Reviews und einfach mehr Leute, die auf den Code schauen MÜSSEN. Bei Open-Source gibt es potentiell zwar mehr unabhängige Tester und Reviewer aber in der Regel machen diese das freiwillig und oft auch nebenberuflich. Und ich schließe eben nicht aus, daß sich besonders bei weniger sexy Modulen, Libraries oder Programmen mal genau niemand das anschaut, weil es eben niemand MUSS.

Natürlich überlappt es es zunehmend bei Unternehmen, die sich nicht nur an Open Source bedienen, sondern zu dieser auch beitragen.

Meine Tage in der Software-Entwicklung sind aber auch laaaaange her und seit dem hat sich viel verändert,

Und? Das stimmt doch. Es ist natürlich suggestiv, nämlich bewusst „kaltherzig“, formuliert, den Tod von Menschen als Randerscheinung zu bezeichnen, aber von der Sache her ist das ein Risikokalkül, das Gesellschaften immer und überall eingehen. Es kommt beispielsweise im Einzelfall sicher zu schlimmen Unfällen, weil Notarztwagen mit stark überhöhter Geschwindigkeit fahren dürfen, aber unter dem Strich werden dadurch mehr Menschen gerettet als sterben, also wird das so gehandhabt, auch wenn alle dadurch verursachten tödlichen Unfälle für sich genommen natürlich tragisch und für die Betroffenen schwer erträglich sind.

Wie der Stand der Dinge konkret bei Tesla ist, vermag ich nicht zu beurteilen, aber gegeben die (plausible) Hypothese, dass zumindest zukünftig autonomes Fahren unter dem Strich sicherer ist als menschlich gesteuertes, werden sich Gesellschaften zu Recht für das autonome Fahren entscheiden, auch wenn es in tragischen Einzelfällen dadurch zu Unfällen kommt, die menschlichen Fahrern nicht passiert wären.

Psychologisch ist das ein Problem, weil Menschen Schicksalsschläge merkwürdigerweise besser verkraften können, wenn sie einem Verantwortlichen die „Schuld“ dafür geben können; bloße Kontingenz scheint besonders unerträglich zu sein. Da Maschinen nicht schuldfähig sind, werden durch autonomes Fahren verursachte Unfälle als besonders schwerwiegend empfunden.
Welches Problem? Dass uns unsere Psyche bei statistischen Verteilungen und speziell beim autonomen Fahren einen Streich spielt, weil wir nur schwer einen „Schuldigen“ finden können?
Ich finde das einen unerträglich sensationslüsternden Beitrag, der auf ganz üble Art mit genau diesen Emotionen spielt, die tragische Einzelfälle auslösen, auch wenn sie statistisch gemittelt gerechtfertigt sind. Wie schön, dass man mit Elon Musk da jetzt den ultimativen Bösewicht als „Schuldigen“ präsentieren kann.

Du würdest also sagen, dass es für macOS (und andere proprietäre Betriebssysteme) überhaupt keine Open-Source-Software geben kann, da sie ja immer auf proprietären Bibliotheken aufbauen muss?

Ein paar Einwürfe aus der Sicht des Anwenders.

1. Open Source ist sicherer, weil „jeder“ den Code überprüfen kann.

Nein, nicht jeder. Ich — beispielsweise — kann das nicht. Und möglicherweise bin ich mit diesem Problem nicht alleine. Ich muss mich darauf verlassen, das fähige Entwickler sich das regelmäßig ansehen.

Viel wichtiger ist aber, die breite, im Brustton der Überzeugung, von den Cracks immer wieder betonte Aussage, Open Source sei sicher, wenn nicht gar sicherer als Closed Source, soll mich dazu verleiten denen zu glauben.

Common Sense ist: App X ist sicherer als App Y, weil es Open Source ist!

Und das ist ja nicht nur hier so. Selbst der CCC trötet in dieses Horn, sobald man denen ein Mikro vor die Nase hält. Die re:publica ist voll davon (wenn es ins Thema passt). Bei diesen Vorträgen geht es sogar so weit, dass der Eindruck erweckt wird, wer Closed-Source-Anwendungen verwendet, darf sich nicht über Sicherheitsprobleme wundern.

Aber, ist das so?

2. Es gab im Dezember ja erst so einen Fall in NodeJS. Updates zu OpenSource-Projekten kamen deutlich schneller als die für CloseSource - und auch die waren potentiell betroffen.
Das ist also kein Argument gegen OpenSource - der Umgang mit Bugs und Sicherheitsrisiken ist aber bei OpenSource deutlich besser.

Wie kann ich wissen, ob „mein“ Open-Source-Anbieter aktiv ist? Nehmen wir als Beispiel MenuBarUSB von Rafael Neuwirth Swierczynski Eine mir sehr hilfreiche kleine App um mir zu zeigen, was und wie meine USB-Anschlüsse so machen.

Laienhaft ausgedrückt: USB ist ja geradezu prädestiniert als Einfallstor in meinen Rechner. Updates muss ich aber manuell anstoßen? Das ist nicht schlimm. Kann man ja alle paar Wochen mal machen. Aber ich nutze locker 10 bis 20 Open-Source-Anwendungen und -Tools. Manche davon Faceless.

Was mache ich nun mit einer Aussage wie: der Umgang mit Bugs und Sicherheitsrisiken ist aber bei OpenSource deutlich besser.? Pro-Aktiv klingt für mich anders.

Mir ist klar, was dann als Antwort kommt: Man muss sich halt um seine Apps auch kümmern. Das stimmt genau so sehr, wie es nicht stimmt.

3. Das Risiko bei ClosedSource ist daher, dass man nie kontrollieren kann, was die Software im Hintergrund macht, weil man den Code nicht prüfen kann. Man nehme das beliebte Affinity. Alle freuen sich, dass es nach der Übernahme durch Canva kostenlos ist. Da läuft aber im Hintergrund das "Snowplow"-Framework, dass stetig Daten an Canva schicken will.

Das Risiko — für mich — ist bei Open- wie Closed-Source-Apps identisch. Ich kann den Code nicht prüfen. Ich muss mich also darauf verlassen, das Andere das machen. Darum ja meine Frage: Passiert das auch?

4. Bei Closed-Source wie Affinity ist mir der Hintergrund bekannt. Die wollen Geld verdienen. Jeder, mit sehr wenigen Ausnahmen, will das. Ich bin kein Coder, aber ich bin auch nicht blöd. Es wird also Wege geben, wie sich die Sache für Affinity einigermaßen lohnt: Bezahltes Upgrade und User-Daten sind die üblichen Wege.

Bei Open Source jedoch, wird ein Mantel der Rebellion über den Elefanten im Raum gelegt. Hat mir Rafael Neuwirth Swierczynski sein Hobby-Produkt „geschenkt“? Naja, er wünscht sich Bitcoin an bc1qvluxh224489mt6svp23kr0u8y2upn009pa546t, was ich ok finde.

Aber die Frage der Sicherheit wird auf diese Weise nicht beantwortet. MenuBarUSB ist Open Source. Warum sollte es, aus der Sicht eines Nicht-Coders, sicherer sein, als ein bezahltes Produkt? Ich muss in beiden Fällen vertrauen.


Ich weiß nicht, wie glaubwürdig it-welt.at ist. Ich halte mich auch von Kaspersky fern, aber eher aus emotionalen denn aus rationalen Gründen (Eine russische Sicherheitssoftware? Das ist doch ein Widerspruch in sich). Irgendwie traue ich dem Laden nicht. Egal.

Alles läuft auf diesen Punkt hinaus:

Warum sollte ich nicht mit demselben naiven Grundgefühl beispielsweise an Open-Source-Passwortmanager gehen? Weil sie „Open Source“ sind? Das kann nicht das Argument sein.

Bevor ich einem Open-Source-Passwortmanager vertraue, vertraue ich lieber Apple. Microsoft würde ich an dieser Stelle eher weniger trauen. Nicht weil die böse sind, sondern unzuverlässig. Und (polemisch ausgedrückt) irgendwelche Code-Kiddys schon gar nicht.

Disclaimer: Ich habe mich hier aus der Sicht eines Nutzers ausgedrückt. Meine Worte mögen ungenau sein, und sicher nicht immer im Wortlaut belegbar. Aber ich sage, wie ich darüber denke, wie sich das Thema für mich anfühlt, und hoffe auf eine hilfreiche Antwort.

Soweit die Theorie.

In der Praxis ist es heute so, daß gerade in der firmeninternen Softwareentwicklung in der Regel das erste, das den Bach heruntergeht, wenn Zeit und Geld knapp sind, die Qualitätssicherung ist. Dafür hat niemand mehr die Zeit.

Umgekehrt bieten Plattformen wie Github in ihren CI-Pipelines bereits standardmäßig Möglichkeiten, automatisiert einfache Reviews von Software zu fahren, angefangen beim leider durchaus notwendigen Check, ob irgendwelche Paßwörter in den Sourcen "vergessen" wurden bis zu automatischen Checks von Dependencies auf Schwachstellen. Das funktioniert so halbwegs ordentlich, aber es ist auf jeden Fall besser als nichts.

Wenn man dann noch selbst Dinge wie automatisierte Tests implementiert - durchaus eine ratsame Maßnahme - hat man schon ein Niveau erreicht, das kommerzielle Closed Source-Software oft gar nicht erreicht.

Und dann gibt es noch so schöne Beispiele wie Microsoft Edge ... . Besonders pikant daran: Chromium als Open Source-Grundlage hat die Schwachstelle nicht.

Weia,
das wäre nicht mein persönlicher Standpunkt.

Die FSF kann in der Tat hier und da sehr weitreichende (um nicht zu sagen extreme) Ansichten haben, die im Einzelfall ich selber für mich als weniger relevant erachten würde. Das Thema gelinkte Bibliotheken ist so ein Fall (und derzeit könnte ich nicht ohne erweiterte Recherche fundiert mitteilen, wie der FSF Standpunkt im konkreten Fall dazu wäre).
Der allgemeinen "Normal-User-Auffassung" nach gibt es natürlich zuhauf Open Source Software für macOS - und das wäre auch meine Ansicht

Wenn Du nicht selbst programmieren kannst, bist Du ohnehin darauf angewiesen anderen zu vertrauen.Schon einmal Software entwickelt? (Rhetorische Frage, da Du das vorher schon verneint hast.) Das erste was bei der kommerziellen Softwareentwicklung eingespart wird, ist die Qualitätssicherung, weil die viel Geld kostet, und keine neuen Features liefert. Sprich niemand will dafür zahlen.
Das ist ein reines Info Programm, welches selbst keinerlei sicherheitsrelevanten Funktionen umsetzt. Das was bei USB wichtig ist, sitzt im Kernel bzw. im Betriebssystem oberhalb des Kernels. Da kommen Updates automatisch von Apple.

So können die Meinungen auseinander gehen – diametral ( nicht diametral entgegengesetzt – aber die Diskussion hatten wir zwei ja schon einmal ).

Ja, natürlich hast Du Recht, dass aus einer übergeordneten Sichtweise das zwar tragisch ( hier tödlich ) für das Individuum, jedoch für die Menschheit in Gänze nicht relevant ist. Da stellt sich die Frage, ab wann dann die Relevanz anfängt – bei 10 Toten?? 100?? 1 Millionen?? Auf die evolutionäre Sicht der Erde wären selbst Milliarden Menschenleben irrelevant. Selbst der gesamte Planet – aus Sicht des Universums. Damit liesse sich dann so einiges rechtfertigen…

Oder andere Lebewesen – Insekten / Tiere. Gibt es eine bestimmte Größe oder ein anderes Kriterium, welches Leben schützenswerte macht ? Darf ich eine Mücke töten, eine Fliege oder einen Marienkäfer aber nicht ?

Es geht – was vielleicht meinerseits nicht so klargestellt wurde, so dass ich es hier nachhole – bei der Empfehlung die Reportage zu sehen nicht darum, dass Elon Musk als Bösewicht abgestempelt wird. Ich finde seine »Innovationswut« durchaus sehr bemerkenswert. Es geht darum zu zeigen, dass er durch sein Unternehmen mit dem Leben von Menschen leichtfertig umgeht, um des Profits Willen !! Und damit ist er der Formulierung nach vielleicht kein stigmatisierter »Bösewicht«, jedoch schuldig – denn er hat die Dinge angeordnet… – am Tod von Menschen. In meinen Augen sogar vorsätzlich, da die Fehler bekannt sind und bis dato noch nicht abgestellt werden konnten, eine Auslieferung der Fahrzeuge aber nicht gestoppt wird, sondern munter weiter geht !!! DAS kritisiere ich, also den Weg des Fortschritts, nicht den Fortschritt selbst.

Aber dieser Teil Diskussion ist eh bar unserer Realität – Gott sei Dank. Denn Du würdest durchaus anders reflektieren, wäre ein von Dir sehr geliebter Mensch ums Leben gekommen. Antizipiere ich zumindest mal.

Und außerdem sollte es um OpenSource gehen. Man könnte ja mal Tesla anbieten, die Software OpenSource zu machen, dann könnten mehr Fehler gefunden werden – um mal zum Thema zurück zu kommen. Dieses Thema können wir auch gerne via PM fortsetzen – oder jemand macht mal einen anderen Threat auf

Greetings, C.

Doch, Du kannst das, grundsätzlich gesprochen. Niemand hindert Dich daran, das ist mit können hier gemeint. Du musst Dir natürlich erst die Fähigkeiten dazu aneignen und selbst wenn Du die schon hast, brauchst Du noch die Zeit dazu, obwohl der Tag nur 24 Stunden hat. Aber die Möglichkeit ist da; das ist das Entscheidende.

Das ist mit allem im Leben so. In einer freien, demokratischen Gesellschaft kannst Du jeden Beruf ergreifen, den Du möchtest, kannst Dich politisch engagieren und am Gemeinwesen beteiligen, kannst zusammenleben, mit wem Du möchtest.

Damit ist doch aber nicht gemeint, dass Du für all das tatsächlich Zeit hast, Begabungen, Fähigkeiten und soziale Kompetenzen mitbringst, um das tatsächlich umzusetzen. Es geht immer um die grundsätzliche Möglichkeit, das Fehlen von Einschränkungen durch andere. Wenn diese Einschränkungen fehlen, kommt das Gesetz der großen Zahl zum Tragen, das z.B. auch für die Schwarmintelligenz verantwortlich ist. Nicht alle machen alles, aber für alles gibt es einige, die es machen. Davon leben freie Gesellschaften, demokratische Öffentlichkeiten und davon lebt Open-Source-Software.
Indem Du schaust, ob Updates erhältlich sind? Auch wenn Du nicht beurteilen kannst, ob darin die erforderlichen Fixes enthalten sind, andere können das, die sich in der Regel dann zu Wort melden werden. Ja, im Einzelfall kannst Du dir nie sicher sein (doch das kannst Du mit nichts im Leben). Aber der entscheidende, in diesem Thread mehrfach erwähnte Punkt ist, dass es hier um ein statistisches Phänomen geht. Ja, Du könntest theoretisch der eine statistische Pechvogel sein, der unentwegt verseuchte Open-Source-Software aufgetischt bekommt. Aber das ist nicht wahrscheinlich; darum geht es. Deine bohrenden Zweifel gehen an statistischen Phänomenen vorbei, und mehr Sicherheit als statistische gibt es nie.

Auch Schwarmintelligenz kann sich irren. Aber es ist vielfach empirisch belegt, dass es nicht wahrscheinlich ist, dass sie irrt.
Wo stimmt das denn nicht? Eigenverantwortung ist immer gefordert. Abgesehen davon gilt das für proprietäre Software doch genauso.
Ja, das passiert in der Regel = es ist in jedem Einzelfall [i]wahrscheinlich, dass das passiert[/i]. Deine ganz Argumentation ist von einer tiefen Skepsis gegen gesellschaftliche Öffentlichkeit und das Gesetz der großen Zahl geprägt. Wenn es nach dieser Sichtweise ginge, müssten alle demokratischen Gesellschaften längst zusammengebrochen sein, denn Du verlangst eine Sicherheit, die es schlicht nicht gibt.
Aber vertrauen auf ganz unterschiedliche Dinge. In einem Fall auf eine kleine Gruppe profitorientierter Menschen, im anderen Fall auf die gesamte Öffentlichkeit.
Deine Argumentation ist insgesamt eher emotional als rational.
Ganz im Gegenteil. Russland bringt traditionell fähige Mathematiker hervor, und für Sicherheitssoftware braucht es genau die.
Doch, genau das ist das entscheidende Argument.
Dann ist Dir leider nicht zu helfen. Im Ernst: Das ist nun wirklich pure Emotion und argumentativ nicht aufrechtzuhalten.

Für diese Argumentation müsstest Du beweisen, dass die Tatsache, dass jemand sich den Code aus beruflichem Zwang ansieht, die schiere Menge aufwiegt, wenn in einem Fall die ganze Welt und im anderen Fall nur ein paar Mitarbeiter einer Firma den Code untersuchen können.

Doch Du kannst das. Jemand kann Dir den Code vorlegen und Du könntest ihn lesen, wenn Du willst.
Du meinst in Wirklichkeit etwas ganz Anderes, nämlich dass Du den Code nicht verstehst, nicht beurteilen kannst oder vielleicht gar nicht lesen willst. Aber auch das wird durch den Durchschnitt herausgemittelt. Auf Dich als Einzelperson kommt es nicht an, sondern nur darauf, dass Du die Gelegenheit hättest, den Code zu prüfen.

Jetzt verwendest Du die asoziale Argumentation, es gäbe da oben irgendwelche Experten, die sich anmaßen, dem verblödeten Volk etwas vorzuschreiben. Solche Geschichten sind unterste Schublade.

Du stellst das jetzt so hin, als würde jeder den Fehler zu machen, zu denken, App X wäre sicher. Das hat aber niemand behauptet. Es ist nur so, dass die Wahrscheinlichkeit sicher zu sein, bei Programmen des Typs App X im Mittel höher ist, als bei Programmen des Typs App Y. Das heißt aber weder, dass App X sicher wäre, noch App Y unsicher.

Du sagst in dem Fall: Diese Aussage ist kompletter Blödsinn, weil der Umgang mit Bugs und Sicherheitsrisiken nichts mit der Frage zu tun hat, ob der Quelltext offen ist.

Genauso ist es.

Völlig richtig.

Deshalb nochmal: Es behauptet niemand, dass ein konkretes Programm deshalb sicher ist, weil es open-sourced ist. Nur die Wahrscheinlichkeit sicherer zu sein, ist für die Gesamtheit aller Open-Source-Programme höher.

Nun, ich bin bei uns im Team der "SSC" (Software-Security-Champion). Irgend so ein Fancy-Jobtitle, der keiner ist und auch nichts außer Arbeit bietet. Aber ich nehme das sehr ernst.
Dahinter steht viel Bürokratie in Form von Dokumentationspflichten, die aber im Zweifelsfall die Rechtfertigung gegenüber Stakeholdern sein kann. Und da sind einige sehr (zurecht) kritische Kunden, teilweise in der sogenannten "kritischen Infrastruktur", die selbst noch vor dem Einsatz Assessments durchführen - egal ob etwas Open- oder Closed-Source ist. Dazu kommen auch einige lästige aber sinnvolle Regulationen wie das Bereitstellen von SBOMs für Softwareprodukte.

Wir haben auch entsprechende Tools, die Analysen auf Code- und Binärebene durchführen. Dazu kommen auch einige selbst erstellte Workflows, wie statische Codeanalyse, (Unit-)Test-Coverage und weitere "Sanitizations" - die es allerdings nicht für alle Programmiersprachen gibt. Realität ist aber auch, dass ich darauf mehr Zeit verbringen sollte, um andere Team-Mitglieder bei ihren Projekten dabei zu unterstützen, solche Tools zu nutzen. Passiert nur wenig und ich bein kein Manager, der darauf einwirken kann (sie wissen aber auch, dass ich das nicht umsonst machen würde). Am Ende sammelt sich da "TechDept" an, wofür dann "TechWealth" Userstories erstellt werden, die aber nie hoch genug priorisiert werden. Schließlich kann man Kunden das nicht verkaufen, weil es kein Feature ist - naja, eigentlich schon, aber nicht als wertvoll angesehen wird, solange es nicht um die Ohren fliegt.
Also passiert das eher schleppend, weil Features wichtiger sind als Sicherheit - zumindest im Marketing. Da ist ja eine Sicherheitslücke kein Problem, solange sie niemand findet - was zunehmend schwerer wird.

Aber wie gesagt - natürlich gibt es "SupplyChain" Angriffe. Darin unterscheiden sich aber FOSS und kommerzielle Produkte nicht. Du bekommst für den Kaufpreis keine Sicherheiten - nur ein Nutzungsrecht.

Bezüglich "outdated software" - nun, ich nutze viel OpenSource und die installiere ich bevorzugt via Homebrew - da muss man halt regelmäßig mal "brew update" im Terminal ausführen, das löst dieses eine Problem.

Und ja - ich habe auch schon einige OpenSource-Projekte von Source gebaut, zum Beispiel VLCKit (VLC zum einbetten in eigene Apps). So konnte ich mir eine Debug-Version bauen, die mir dann in Instruments genau die Hinweise auf den Leak gegeben haben, die zu meinem Bugfix geführt haben. Klar "kann" das nicht jeder (nicht jeder Autfahrer kann ein Auto auch bauen oder reparieren), aber es gibt Menschen, die es können. Bei ClosedSource kann es keiner, der nicht in der Firma arbeitet (und auch dort können das die meisten nicht). Das heißt aber nicht, dass es dort Priorität bekommt und damit auch umgesetzt wird.

Daher sehe ich eben bei ClosedSource keine Vorteile gegenüber OpenSource. Damit muss OpenSource nicht besser sein, aber das liegt nicht am OpenSource-Gedanken, sondern an den Entwicklern.

Aus meiner Anwendersicht sehe ich den Vorteil von Open Source hauptsächlich darin, dass man auch als Nichtprogrammierer einen direkteren Draht zu den Programmierern hat und daher Fehler und Sicherheitslücken oft sehr viel schneller ausgemerzt werden, als bei Closed Source Software, wo Fehler oft von Version zu Version u.U. über Jahre mitgeschleppt werden ohne, dass sich jemand darum kümmert.

Falsche Frage. Dass die Erhaltung menschlichen Lebens immer relevant ist, ist doch die Voraussetzung dieses Risikokalküls, sonst würde sich das Problem der Rechtfertigung so ja gar nicht stellen. Und dann ist das eine rein relationale Frage. Wenn mehr Menschen gerettet werden als sterben, ist das im Sinne dieses Kalküls zu rechtfertigen. Wenn 6 Menschen (dann und nur dann) gerettet werden können, wenn 2 Menschen sterben, ist das im Sinne dieses Kalküls zu rechtfertigen. Wenn 6 Milliarden Menschen (dann und nur dann) gerettet werden können, wenn 2 Milliarden Menschen sterben, ist auch das im Sinne dieses Kalküls zu rechtfertigen.
Wie gesagt, um Relevanz geht es überhaupt nicht. Für die Menschheit ist das Überleben der Menschheit fraglos relevant, für das Universum fraglos irrelevant.
Das sind moralische Fragen, nicht relationale, und ein weites Feld, das wir hier nicht auch noch beackern sollten.
Schwierige Frage. Man könnte (holzschnittartig) so argumentieren (ist jetzt nicht mein eigener Standpunkt):

• Das Überleben der Menschheit (8 Milliarden) ist durch die Erderwärmung bedroht.
• Elektromobilität leistet eine wesentlichen Beitrag zur Verhinderung weiterer Erderwärmung.
• Damit sich Elektromobilität durchsetzt, braucht es Pioniere, die demonstrieren, dass sie machbar ist.
• Um das der Gesellschaft überzeugend vor Augen zu führen, muss die Elektromobilität auch wirtschaftlich erfolgreich sein.
• Technikgeschichtlich typische Probleme bei der Einführung neuer Technologien dürfen daher den wirtschaftlichen Erfolg des entsprechenden Unternehmens aufgrund seiner Vorbildfunktion nicht behindern.

⇒ Tesla kostet ein paar 100 Menschen das Leben, rettet aber 8 Milliarden, also ist das Handeln gerechtfertigt.

(Das entbindet Tesla aber natürlich nicht davon, die Zahl der Opfer zu minimieren.)
Das würde ich höchstwahrscheinlich, aber genau deswegen wäre ich dann für eine diesbezügliche Diskussion disqualifiziert, weil meine Emotionen meine Vernunft überlagern würden. Das wäre so, wie Menschen an einer Diskussion über die Todesstrafe zu beteiligen, deren Kinder einem grässlichen Sexualverbrechen zum Opfer gefallen sind – da bekämst Du vermutlich auch erhöhte Zustimmungswerte zu einer Wiedereinführung.
Hatte das Tesla für seinen Autopiloten nicht sogar mal angekündigt?

Es gibt gute Gründe, an der Sicherheit von Open Source zu zweifeln (undurchschaubare Abhängigkeiten, fehlendes Peer Review, zu wenig aktive Contributors), aber das ist kein Argument dafür, dass Closed Source sicherer ist.

Apple (nehme ich jetzt als Musterbeispiel für Closed Source) verteidigt seinen App Store mit dem Argument Sicherheit. Im Grunde ist das Gegenteil der Fall. Der Review-Prozess besteht überwiegend aus automatisierten Checks; manuelle Prüfungen finden statt, aber mit begrenzter Wirksamkeit. Malware hat den Review mehrfach passiert (gefälschte Krypto-Wallets und Adware), die monatelang unentdeckt blieben. Einzelentwickler dominieren das Angebot, ohne dass ihr Code systematisch auf Sicherheit geprüft wird.

iOS und macOS sind dennoch vergleichsweise sichere Betriebssysteme, aber nicht wegen des App Store, sondern trotz ihm. Der eigentliche Schutz ist die Betriebssystemarchitektur: Sandboxing, Berechtigungsmodell, System Integrity Protection. Schadsoftware kann in diesem Rahmen nur begrenzten Schaden anrichten, weil das System den Zugriff auf kritische Bereiche verwehrt, aber nicht weil Apple den App-Code vorab geprüft hat. In einem so konstruierten Betriebssystem ist es daher vertretbar, Open-Source-Software zu nutzen, ohne dass jede Codezeile zehnmal umgedreht wurde.

Open-Source hat aber eine Schattenseite. Systemrelevante Software wird von Einzelpersonen gepflegt, die dafür nicht bezahlt werden und einen erheblichen Teil ihrer Zeit einsetzen. Konzerne nutzen die Software und nutzen die Entwickler aus. Hier ein Artikel über einen Entwickler (requests, eine der meistgenutzten Python-Bibliotheken), den dieses System persönlich fast kaputt gemacht hat: Open Source Gave Me Everything Until I Had Nothing Left to Give

Interessanter Artikel dazu, wenn auch schon älter:
https://www.linux-community.de/nachrichten/osba-veroeffentlicht-studie-zur-sicherheit-von-open-source-und-proprietaerer-software/

Es gibt genügend bekannte Beispiele von Problemen die auch Closed Source betreffen in denen OpenSource zum Einsatz kommt. z.B.
https://www.heise.de/news/UEFI-BIOS-mit-bekannt-unsicherem-Code-gespickt-7351884.html

Und da sind wir nun wieder beim eigentlichen Problem.
Es gibt keine fehlerfreie Software und Fehler können auch Sicherheitslücken sein. Egal ob es eine OneManShow oder ein Großkonzern ist. Gegen Angriffe auf z.B. Git und infizieren mit Malware ist niemand wirkich sicher. Richtig schlimm wird es, wenn sich Software automatisch aktualisiert und man sein "sauberes" System durch eine komprimierte Datei infiziert.

Dann gab es ja auch noch den Entwickler der sich ein eigenes Krypto Wallet programmieren wollte und aufgrund fehlender Fachkenntnis doch mal die KI befragt hat die im gleich einen Trojaner mit untergeschoben hat. Sein Wallet das er programmiert hatte hat sich dann schnell entleert. Da sehe ich aktuell die größte Gefahr. Wenn Leute eine Software erstellen wollen, keine Ahnung von der Programmiersprache haben und sich blind auf die KI verlassen.

Ob und wie es generell noch mit OpenSource weitergeht bleibt zudem spannend, mit Blick auf die neue EU-Produkthaftungsrichtlinie. Mal sehen was da auf uns zukommt. Je nach Umsetzung werden dann viele kleine Entwickler ihre Repositories abschalten (müssen).

Hat vielleicht wenig mit dem Thema hier zu tun, ist aber ein bemerkenswerter Text. Danke für den Link!

Die c't hatte mal ausführlich über die Backdoor in der Open-Source-Bibliothek XZ berichtet, sehr interessant zu lesen, auch wie es dazu kam. Wenn es sich dann noch um eine Software-Komponente handelt, die quasi auf fast jedem Server läuft, sind die Folgen einer Katastrophe irgendwann unabsehbar.

Nach dem Lesen dieser Artikel, war für mich der Glaube irgendeiner vermeintlich höheren Sicherheit durch Open-Source eigentlich komplett gegessen....

Perfide Hintertür in der Softwarebibliothek xz:


4-teilige Analyse der Sicherheitslücke in der Softwarebibliothek xz:





Open-Source-Software als Risiko oder strategischer Vorteil?


Persönlich stört mich bei Open-Source-Software oftmals die super schlechten UIs, teilweise unterirdische überfrachtete Einstellmöglichkeiten, die eher etwas für Freaks sind, die sehr tief in der Thematik drin stecken.

Und es sind schon oft Projekte "gestorben" und verwunden, weil sich keiner mehr gefunden hat, der es fortführen wollte. Das habe ich oft erlebt, jedenfalls mehr als bei kommerzieller Software.

Das wird sicherlich ein anderer Thread von mir werden. Ich schlage mich aktuell — aus Gründen — mit einem RasPi herum. Es ist der blanke Horror … 😵‍💫

Damit dürfte xz noch immer sicherer sein, als viele closed source Produkte. Wenn Du in der Industrie die Möglichkeit hast Softwareprodukte im Sourcecode zu erhalten, z.B. bestimmte Entwickler Tools, dann kannst Du sehen wie schlecht die Software und deren Wartung ist. Ich habe da so meine Erfahrungen gemacht. Der Unterschied ist, dass man das als Anwender nicht sieht und nichts davon hört.
Es gibt so viele Projekte, dass das wenig aussagekräftig ist.

Auf dem RaspberryPi läuft als Vorgabe eine spezielles leichtgewichtige DE Umgebung früher LXDE. Das ist nicht unbedingt die beste Umgebung, aber sie läuft mit wenig RAM. Für Gnome oder Cinnamon sollte es schon ein Pi mit reichlich RAM sein.

Du hast mich hier zitiert, aber ich habe gar nichts zum Pi gesagt, das war System 6.0.1. Habe selber welche für Bastelzwecke im Einsatz und das einzig nervige für mich sind eher die Unterschiede zwischen BSD und GNU wenn es um Shell-Scripting geht.

Das ist doch exakt der Punkt: ist Open Source besser, weil es Open Source ist? Ist Apples Passwort-Manager unsicher, weil er Closed Source ist. Sind 50.000 „sichere“ Open-Source-Projekte ein Beweis dafür, dass der Apple Passwortmanager unsicher ist?

Nein. Was Du sagst ist: Open Source ist sicherer als Closed Source, weil es Open Source ist. Und da will ich ein besseres Argument. Am besten eines, in dem das Wort „dürfte“ nicht drin vorkommt.

Geht das?

Nein, das geht nicht, weil Aussagen zur Sicherheit immer nur Wahrscheinlichkeitsaussagen sein können. Wenn Dir das nicht reicht, musst Du dir eine andere Welt suchen.

Da bei sehr vielen Projekten nach dem Pareto-Prinzip vorgegangen wird um die Kosten und den verbundenen Aufwand im Griff zu behalten wird es nie eine 100%tig sichere oder fehlerfreie Software geben. Sobald auch nur eine einzige Abhängigkeit besteht verschiebt sich der Angriffsvektor. Dann muss man nicht nur die eigene Software prüfen sondern auch alle Abhängigkeiten. Zudem benötigt man auch entsprechendes Fachwissen um die möglichen Probleme zu erkennen.
Daher kann man keine Aussage treffen, welche Variante sicherer ist. Es gibt auf beiden Seiten schwarze Schafe die immer wieder dafür sorgen das es Sicherheitsprobleme gibt. Daher werden auch viele Betriebssysteme von Altlasten befreit um die Sicherheit zu erhöhen.. Sei es über signierte Programme oder das Abschalten von Kernel Extensions etc. Man kann eben nicht alles absichern, irgendwo wird es immer eine Lücke geben. Viel interessanter wäre doch das Thema, wie schnell reagieren und beheben Softwareentwickler gemeldete Sicherheitslücken. Da würde mich eine Statistik sehr interessieren, ist da OpenSource besser aufgestellt?

System 6.0.1
deine Fragestellung ist im Kern bereits relativ unpräzise.

"besser": aus welcher Sicht? Bzgl. welchem Kriteriums? Das kann sehr unterschiedliche Aspekte berühren und nicht jeder versteht automatisch das gleiche darunter.

"sicher / sicherer": auch hier: welche Art von Sicherheit? Da gibt es auch mehrere Möglichkeiten. Zudem gibt es einen erheblichen Unterschied, wenn man von "sicher" vs. "sicherer" spricht.

Das Thema ist komplex, hat sehr viele Facetten, kann unterschiedlich beleuchtet werden, kann anders in unterschiedlichen Kontexten gesehen werden. Die o.g. Studie liefert ja auch schon interessante Einblicke.
Wie immer: es kommt drauf an.

Wenn du weiterhin nur in unpräziser Form im polemischen Ton bleiben willst, dann kann man letztendlich nur an alle anderen hier sagen: Don't feed the troll.

Ja, das ist mir auch schon aufgefallen. Immer wenn es für den „Experten“ eng wird, zieht er die „Unpräzise-Fragestellung“-Karte. Das erlebe ich seit nun mehr als 35 Jahren in verschiedenen Bereichen der IT.

Dabei verstecke ich doch nun wahrlich nicht, dass ich zwar aus „der Szene“ komme, aber eben nicht auf der hier vorherrschenden Ebene.

Das Thema ist für einen Entwickler immer komplexer als für den Anwender. Letzterer interessiert sich nicht für die Details. Der Anwender interessiert sich für die Frage:

Kann die Anwendung dieser Software ein Sicherheitsproblem werden?

Und ja, das mag ignorant klingen. Und ja, solche Leute haben „keine Ahnung“. Geschenkt. Aber die Frage ist wichtig. Zu wichtig, um von einem Coder ein „deine Fragestellung ist im Kern bereits relativ unpräzise“ zu bekommen. Denn wäre mir die Kernkomponente des Problems bewusst, würde ich die Frage höchstwahrscheinlich nicht stellen.

Und an der Stelle frage ich mich dann, wie kann ein überdurchschnittlich intelligenter Mensch an etwas so simplen scheitern? Die Antwort ist so simpel wie unangenehm:

Wir. Sind. Unterschiedlich.

Vielleicht sollten mal einige Menschen mehr auf dem Planeten damit klarkommen, dass die Fähigkeiten nicht gleichmäßig verteilt sind, und das diese Fähigkeiten vereint, mehr erreichen können, als wenn sich Endanwender und Entwickler andauernd gegenseitig subtil erniedrigen.

Also, kannst du zu meiner Frage etwas Erleuchtendes beitragen?

PS:

Was soll das? Ich sage zu dir ja auch nicht „Inselbegabter Schwätzer“, oder? Also, lass das bitte. Danke.

Ich kürze das mal ein, damit hier kein dreiteiliger Scroll-Roman entsteht…Eine Frage kann nicht falsch sein, eine Antwort hingegen schon…

Es geht mir bei der ganzen Situation schon auch um die Relation ( = Anzahl ), aber unter dem Aspekt der Moral. Ich halte es für moralisch extrem verwerflich, wenn man auch nur ein Menschenleben bewußt auf's Spiel setzt, um sein eigenes pekuniäres Streben weiter zu steigern. Es ist ja nicht so, als würde es Tesla oder Musk selbst finanziell schlecht gehen.

Die Fehler sind bekannt ( die Tesla können nicht fehlerfrei autonom fahren ). Sie werden bewußt nicht abgestellt ( temporär durch Deaktivierung der Funktionen, bis eine Lösung gefunden ist ) und es wird weiterhin mit gefälschten Werbefilmen ( nachweisliche Aussage eines Mitarbeiters ( nun ehemalig, weil er dagegen aufbegehrt hat )) weiterhin propagiert. Das ist zum einen ein bewußtes Spielen mit Menschenleben, zum anderen rechtlich/wirtschaftlich gesehen Betrug. Und wie Du schriebst, jedes Menschenleben ist relevant. DAS – also die bewußte Ignoranz zu Gunsten des eigenen Profits – kritisiere ich !!

Und dabei war von mir nur aufgeworfen, dass die Argumentation bei schon einem Leben falsch, weil auch ein Leben relevant ist und ich zudem die Fragen nach der richtigen Anzahl, ab wann es relevant werden würde, sowie der, ob es sich im allgemeinen dabei nur um Menschenleben drehen würde, eingeworfen habe.

Andersherum gedacht: Wenn ich Deiner Argumentation folge – wenn ich drei opfere um 100 zu retten – wären damit auch Menschversuche akzeptabel. Drei tot, 100 geheilt, okay. Da fallen mir die »ewig gestrigen« ein, die diese Argumentation sehr wohl genau so nutzten…

ABER: Ich denke, dass der moralisch philosophische Exkurs vielleicht nicht so wirklich mehr in die OpenSource-Debatte passt und sich ebenfalls verselbstständigt hat ( auch wenn ich damit ja auch angefangen habe… – sorry ). Sollten wir dann vielleicht ebenfalls besser ausgliedern, wenn wir da weitermachen wollen ? Dann sollten die relevanten Posts aber mitkopiert werden.

Also zurück zum Thema.

Happy Weekend allen, C.

Dann probiere ich mich an einer Antwort. Geh die Frage empirisch an.

Die gesamte Infrastruktur des Internets läuft auf Open-Source-Software: SSH, der Linux-Kernel, die Linux-Tools. Das hat sich seit Jahrzehnten bewährt.
Wo es um kritische Infrastruktur geht, Flugzeugsteuerung, Kernkraftwerke, medizinische Geräte, wird die Software nach zertifizierten Prozessen mit Verifikation und unabhängigen Audits gebaut. Das ist zwar Closed Source, aber eine eigene Kategorie.
Normale Closed-Source-Software ist hingegen eine Blackbox. Man muss dem Hersteller vertrauen und das geht oft schief: LastPass, unzählige Fälle von jahrelang unentdeckten Lücken in proprietären Systemen oder im App Store. Der Hersteller entscheidet, ob und wann er eine Lücke einräumt und ausräumt.

Open Source ist damit kein Sicherheitsgarant, aber es ist die Grundlage, auf der unabhängige Prüfung überhaupt möglich ist. Und das ist meist besser als Closed Source.

Weder schrieb oder assoziiere ich, dass es eine einfache Antwort gibt. Im Gegenteil. Du sprichst von »im Mittel sinnvoll«, was ja eben eine Vereinfachung beinhaltet. Die treffe ich doch gar nicht, sondern kritisiere es, dass es eben nicht jedes Handeln abdeckt ( im Sinne von OpenSource wird kontrolliert und ist damit sicherer. Das kann so sein, muss es aber nicht. Umgekehrt gilt das gleiche für ClosedSource – kann, muss aber nicht ).

Eine Frage kann nicht falsch oder unsinnig sein…

Dann sag doch mal, wie Du meinst, dass die Frage gestellt werden muss.

Yep, sehe ich ebenso und bin da durchaus kritisch unterwegs. Dennoch gilt der Umkehrschluß, dass eine App ausserhalb des App-Stores sicher ist, eben auch nicht. Selbst ob sicherer/ unsicherer ist nicht klar – kann so oder so sein.

Ja.Nein.

Happy Weekend, C.

Nein.

Nein.

Von Handeln war nirgendwo die Rede. Ich habe die mathematische Herleitung skizziert, aus der sich die Behauptung "Open Source ist sicherer" ableitet. Welches Handeln sich daraus ergibt, kann Jeder für sich entscheiden.


Das hat niemand behauptet.

Du hast hier noch einmal ganz klar gezeigt, dass Du mit Wahrscheinlichkeitsaussagen nicht umgehen kannst.

Weder ziehe ich eine Karte, noch war ich mir dessen bewusst, dass es eine solche gibt.
Es ist mehr als offensichtlich, dass eine solche undifferenzierte one-liner-Frage nicht ausreichend ist.
Paradoxerweise ziehst du die "ich habe so und so viele Jahre Erfahrung in dem Bereich und damit habe ich automatisch eine unumstössliche Grundkompetenz"-Karte. Da du selber sogar aus der Branche kommst, ist das umso trauriger, wenn du es nicht verstehen willst (obwohl man aufgrund deines Verständnisses nach es können solltest).
Sorry, aber der Ton und deine weiteren Reaktionen bisher lassen deine Frage nur als rhetorische erscheinen damit du deinen sehr festgefahren Standpunkt in süffisanter Art einfach hier reindrücken kannst.
Diskussionen mit Querulanten sind selten erhellend.

Aber Software-Sicherheit ist doch keine Zufallsfunktion und Sicherheitslücken nicht zufällig verteilt - wenn wir hier schon präzise sein wollen.
Du sagst im Grunde nur, Open Source ist meistens sicherer.

Du willst eine Schwarzweiß Antwort auf eine Fragestellung, die eine solche Antwort nicht erlaubt. Das ist hier das Problem. Da Du kein Softwareentwickler bist, kannst Du nicht beurteilen weshalb das nicht funktioniert.

Wenn man ClosedSource Software hat, dann kann man (als Außenstehender) nur eine relativ begrenzte Anzahl von Tests durchführen, um die Qualität der Software zu prüfen. Bei OpenSource kann man auch den Sourcecode prüfen, und somit sehr viel umfangreichere Tests durchführen. Es ging die letzten Wochen durch die Fachpresse, dass Claude Code eine neue umfangreichere Version nur unter bestimmten Voraussetzungen zugänglich macht, weil man damit sehr umfangreiche Codeanalysen durchführen kann. Mittel- bis langfristig wird KI die Softwarequalität verbessern. Aber auch KI Analysen sind nur statistische Analysen.

Dir reichen solche statistischen Analysen nicht, und Du willst als Antwort einen Beweis der Korrektheit. Dazu müsste man aber die formale Korrektheit von Programmcode beweisen. Das macht man in der Regel aber nicht, weil es viel zu teuer ist. Und selbst dann können sich Fehler einschleichen, weil diese nicht im Programmcode liegen können sondern in der fehlerhaften Anforderung siehe Ariane V.

Ich glaube „Open“ vs „Closed“ Software ist hier schlicht die falsche Dichotomie.

Auch Closed Source Software beruht heutzutage zu großen Teilen auf OpenSource. Die sicherheitsrelevanten Korrekturen können also genauso ankommen wie bei einem OpenSource Projekt. Es gibt ja mittlerweile da auch gute Automatisierung und Warnsysteme. Diese machen keinen Unterschied zwischen Closed Source Anbietern und Open Source Projekten.

Vielmehr sind bezüglich der Sicherheit die konsequent durchgeführten Prozesse wichtig. Die können sowohl bei Closed Source als auch bei Open Source umfassend und gut, aber eben auch erbärmlich und dilettantisch sein.

Ein Vorteil vieler OpenSource Projekte ist, das man deren Prozesse vielleicht besser einsehen kann - das trifft aber bei weitem nicht auf alle zu und manche OpenSource Projekte unterscheiden sich überhaupt nicht von normalen Unternehmen (sie SIND meist sogar normale Unternehmen).

Wenn Wir davon ausgehen, dass die Sicherheitslücken durch menschliche Fehler entstehen, weil jemand unachtsam war, dann sind diese Sicherheitslücken statistisch verteilt. Die Fehlerquote mag durch bestimmte Rahmenbedingungen beeinflusst werden. Z.B. wer unter starkem Zeitdruck steht wird deutlich mehr Fehler produzieren, wer mehr Erfahrung hat, wird bestimmte Patterns vermeiden, weil diese mehr Fehler liefern, …

Völlig richtig. Mehr kann man seriös nicht behaupten.