Hat Open Source ohne Reproduzierbarkeit einen Mehrwert im Bezug auf Vertrauenswürdigkeit?

In meinem Augen ist eine bestimmte Binary, also die ausführbare Software, nur Open Source wenn man den Source Code dafür kompilieren kann und anschließend eine Binary erhält, welchen dem selben Hash hat, wie die offizielle Binary die als Open Source bezeichnet wird.
Nur so kann man effektiv überprüfen ob der Source Code wirklich das ist was auch wirklich ausgeführt wird.

Viele „Open Source“ Apps haben aber nur einem Großteil ihres Source Codes veröffentlicht, diesen in der offiziellen Binary aber mit Proprietären Source Code gemischt so das man durch kompilieren und hashen nichts mehr überprüfen kann.

Bevor das einer schreibt:
Man kann Binarys auch reverse engineeren, aber das ist deutlich aufwendiger als das eben schon erwähnte kompilieren und hashen.

3 „Gefällt mir“

Wenn man nicht nachweisen kann das der Source Code auch wirklich die Basis der Binary ist.
Kann man anhand des Source Codes nicht die Funktionsweise der Binary garantieren

1 „Gefällt mir“

Reproducible Builds sind schon wichtig. Gerade in Hochsicherheitsbereichen.

Das mir dem Binärcode funktioniert nur bei gleichem Compiler und gleicher Systembasis

Bei allem was als Open Source bezeichnet wird

Du hast absolut recht – ohne Reproduzierbarkeit ist der Mehrwert bezüglich Vertrauenswürdigkeit stark eingeschränkt. Open Source lebt davon, dass jeder nachvollziehen kann, was ausgeführt wird. Ist das nicht möglich, bleibt nur ein theoretischer Gewinn, aber kein praktischer. Gerade bei Sicherheitsanwendungen ist reproduzierbares Bauen essenziell, sonst bleibt immer Restzweifel, ob die veröffentlichte Binary wirklich aus dem Quellcode stammt. Ein „Open Source“-Label allein reicht da nicht.

1 „Gefällt mir“

Ich befürchte, dass “open source“ vermehrt als Marketinginstrument verwendet wird. Es ist nur open source, wenn jeder den Quellcode vollständig einsehen kann. Alles andere sind falsche Hoffnugen.

Ich wüsste nicht, außer ggf. falls die weights von LLMs betrifft (wobei das ein ganz anderes Thema meiner Meinung nach ist), wann etwas als open source bezeichnet wird, obwohl es der Quellcode nicht vollständig einsehbar ist.

Wenn etwas fälschlicherweise als open source bezeichnet wird, ist die Community normalerweise sehr aktiv und kritisiert das dann auch gleich, weshalb es immer weniger vorkommt.

Der properitäre Source Code lässt sich aus technischen Gründen - je nachdem, in welchem Kontext man arbeitet, nicht vermeiden.

Normalerweise verhindert properitärer source code jedoch nicht zwingend reproducible builds.

Muss auf jeden Fall reproduzierbar sein. Da gibt es ja recht viele Anstrengungen zum Beispiel in der Debian Community um die Reproduzierbarkeit zu erhöhen.

Software die proprietäre Komponenten hat wie zum Beispiel die Firmware beim Kernel sind leider eine Tatsache und untergraben den ganzen Aufwand. Leider gibt es sehr wenig Hardware die komplett ohne diese binary blops auskommt.

Was natürlich noch geiler ist und ein weiteres Rabithole, auch schon wegen den Hintergründen, ist “Bootstrapability” was unter anderem auf Anstrengungen aus der Bitcoin Community basiert. Bitcoin Core ist nicht nur Reproduzierbar, sondern das build environment in dem das gemacht wird ist “bootstrapable”

Es gibt wenige Funktionen für die es keine Open Source Option gibt.

Nicht zwingend aber proprietär heißt in der Regel nicht nur Proprietäre Lizenz sondern auch das der Code gar nicht erst veröffentlicht wird.

Richtig, aber es gibt sie, und auf die hab ich mich bezogen.

Ich weiß, aber beides verhindert keine Reproducible Builds.

Wenn man den Code nicht hat, dann kann man das build nicht reproduzieren

Sicher, nur der spezifische Teil lässt sich halt nicht auditieren. Das Einbinden einer nicht-opensource library “zerstört" reproducible builds nicht automatisch.

Reproducibility != Auditierbarkeit

Bestes Beispiel: Signal, welches die google play services nutzt, die closed-source sind. google play services werden praktisch von jeder app genutzt, auch von FOSS apps.

Wer das nicht möchte, muss auf zB Molly nutzen.

Das hängt davon ab wie die library eingebunden ist.
Wenn die library statisch zur Runtime geladen wird, also eine eigene binary ist, dann kann man die Open Source Teile immernoch getrennt kompilieren und ihre Reproduzierbarkeit testen.
Wenn proprietärer code statisch gelinkt wird ist die ganze binary nicht mehr reproduzierbar. Und soweit ich weiß werden mobile apps meistens statisch gelinkt.

Eigentlich ist beides auch ein Bruch der GPL und im Falle von Playservives auch komplett unnötig. Man kann mit denen nämlich auch über normale Inter Process Communication sprechen ohne die reproduzierbarkeit zu beeinflussen und oben evt die GPL zu verletzen