Genuinitäts-Bestätigung mittels Hashwert

[peterkleibert]

Ums vorweg zu nehmen: Ich finde diesen Sicherheits-Check toll. Ein verfügbarer und geprüfter Quellcode ist die einzige Möglichkeit sich vor Geheimdiensten und anderen Verbrechern zu schützen.

Aber wäre für die spätere verifizierung, ob eine kompilierte Anwendung tatsächlich dem geprüften Quellcode entspricht, nicht ein Hashwert-Vergleich angebracht?

[Spaghetticode]

peterkleibert schrieb:
--------------------------------------------------------------------------------
> Aber wäre für die spätere verifizierung, ob eine kompilierte Anwendung
> tatsächlich dem geprüften Quellcode entspricht, nicht ein
> Hashwert-Vergleich angebracht?
Das geht nicht, weil Quellcode und Kompilat prinzipbedingt unterschiedliche Hashwerte haben.

[peterkleibert]

Sry, ich habe mich undeutlich ausgedrückt. Natürlich ist mir bewusst, dass Quellcode und Kompilat einen unterschiedlichen Hashwert haben. Vielmehr meine ich, dass der geprüfte Quellcode innerhalb des Audits kompiliert wird, und dieser Hash dann als "Referenz" veröffentlicht wird, sodass jeder User selbst gewährleisten kann, dass ihm keine Ente untergeschoben wurde.

[mfeldt]

peterkleibert schrieb:
--------------------------------------------------------------------------------
> Sry, ich habe mich undeutlich ausgedrückt. Natürlich ist mir bewusst, dass
> Quellcode und Kompilat einen unterschiedlichen Hashwert haben. Vielmehr
> meine ich, dass der geprüfte Quellcode innerhalb des Audits kompiliert
> wird, und dieser Hash dann als "Referenz" veröffentlicht wird, sodass jeder
> User selbst gewährleisten kann, dass ihm keine Ente untergeschoben wurde.

Geht das? Erzeugt nicht das Kompiulat auch Compiler/Maschinen/BS-abhängige Hashwerte?

[Spaghetticode]

Wenn du dem beim Audit aufgestellten System vertraust, dann würde das funktionieren.

Alternativ kann man, wenn man ganz sicher gehen will, den geprüften Quelltext auf seinem eigenen System kompilieren. Wenn der gleiche Compiler mit den gleichen Parametern verwendet wird, dürfte wohl sogar der gleiche Hashwert herauskommen.

[peterkleibert]

Besten dank für deine Einschätzung :-)

[Spaghetticode]

mfeldt schrieb:
--------------------------------------------------------------------------------
> Geht das? Erzeugt nicht das Kompiulat auch Compiler/Maschinen/BS-abhängige
> Hashwerte?
Der Hashwert ist aber nur vom Dateiinhalt abhängig. Eine exakte Kopie (zum Beispiel einer Bilddatei) hat den gleichen Hashwert, egal ob auf Windows oder Linux. Eine Windows-Binary hat aber einen anderen Hashwert als eine Linux-Binary aus dem gleichen Quellcode. (Die selbe Windows-Binary hat aber auf Windows und Linux den gleichen Hashwert.)

[ansi4713]

Prinzipiell geht das schon, aber...

Das setzt voraus, das es (für jedes System) eine compilierte Version gibt, die mit absoluter Sicherheit aus den öffentlichen Quellen erzeugt wurde. Dies konnte aber bislang noch nicht zweifelsfrei überprüft werden, wenn ich das richtig verstanden habe.

Siehe dazu auch: http://heise.de/-1982154

Bit denne...
ansi4713



1 mal bearbeitet, zuletzt am 21.10.13 11:35 durch ansi4713.

[SJ]

mfeldt schrieb:
--------------------------------------------------------------------------------
> Geht das? Erzeugt nicht das Kompiulat auch Compiler/Maschinen/BS-abhängige
> Hashwerte?

Ja, da gibts grosse Probleme. Jos van den Oeuver hat das vor einiger Zeit mal aufgeworfen:

https://blogs.kde.org/2013/06/19/really-source-code-software

[quote]Conclusion
A cherished characteristic of computers is their deterministic behaviour: software gives the same result for the same input. This makes it possible, in theory, to build binary packages from source packages that are bit for bit identical to the published binary packages. In practice however, building a binary package results in a different file each time. This is mostly due to timestamps stored in the builds. In packages built on OpenSUSE and Fedora differences are seen that are harder to explain. They may be due to any number of differences in the build environment. If these can be eliminated, the builds will be more predictable. Binary package would need to contain a description of the environment in which they were built.
[/quote]

--
Wer all meine Fehler findet und die richtig zusammensetzt, erhält die geheime Formel wie man Eisen in Gold umwandeln kann.

[SJ]

Leider ist dem nicht ganz so:

https://blogs.kde.org/2013/06/19/really-source-code-software

--
Wer all meine Fehler findet und die richtig zusammensetzt, erhält die geheime Formel wie man Eisen in Gold umwandeln kann.

[Spaghetticode]

SJ schrieb:
--------------------------------------------------------------------------------
> This is mostly due to timestamps stored in the builds.
Also wird das nichts mit dem gleichen Hashwert von Binaries aus dem gleichen Quellcode. (Man könnte aber trotzdem die selbstkompilierte Version verwenden, wenn der Compiler vertrauenswürdig ist. Man weiß ja, dass das die Software aus dem Quelltext stammt.)

[SJ]

Na ja, wenn TC unter GPL gestellt würde, könnten Distros das selbst kompilieren und die Binaries verteilen.... das würde es schon bequemer machen. Oder Organisationen wie EFF, FSF könnten die kompilierten Binaries auch verteilen.

--
Wer all meine Fehler findet und die richtig zusammensetzt, erhält die geheime Formel wie man Eisen in Gold umwandeln kann.