News Debians „Reproduzierbares Paketarchiv“ fast fertig

[fethomm]

Ein Vorteil freier Software ist, dass jeder deren Quelltext einsehen kann. Aber entstammen die von Linux-Distributionen verteilten Binärpakete dem veröffentlichten Quelltext? Dieser Nachweis war bislang schwierig. Ein Debian-Projekt möchte solche Nachweise automatisieren – und hat das bereits bei 80% der Pakete geschafft.

Zur News: Debians „Reproduzierbares Paketarchiv“ fast fertig

 

[Eagle-PsyX-]

Allerdings werden die restlichen 20 Prozent der Pakete schwieriger reproduzierbar zu bauen sein als die bisherigen 80 Prozent, die über 17.000 Pakete darstellen.

Weiß jemand auch warum das so ist?

 

[etking]

Ich sehe in der Beschreibung irgendwie den Nachweis nicht.

Ein rein vertrauensbasiertes System ist doch genauso verwundbar wie das kaputte Zertifikatsystem im Browser. Es ist den ganzen Aufwand nicht wert und es fehlen Regelungen zum Zurückziehen des Vertrauens bei Missbrauch oder Hack der vertrauten Person. Am Ende haben wir Security by Obscurity ohne wirkliche Sicherheit weil jeder blind vertraut ohne das System zu verstehen und zu hinterfragen.

 

[ice-breaker]

Den Weg von Homebrew zu gehen wäre meiner Meinung nach viel sinnvoller:
Das Repository enthält für jedes Paket nur noch eine maschinenlesbare Anleitung wie das Paket gebaut wird (Laden von Quelle X, Check der Datei, Patch drüberbügeln etc.), damit ist sichergestellt dass man keine modifizierten Binaries bekommt.
Und weil manche Dinge selbst zu kompilieren Ewigkeiten brauchen können, gibt es zusätzlich noch wie bisher fertige Binärpakete, für diejenigen die eben nicht paranoid sind.

 

[roidal]

Den Weg von Homebrew zu gehen wäre meiner Meinung nach viel sinnvoller:
Das Repository enthält für jedes Paket nur noch eine maschinenlesbare Anleitung wie das Paket gebaut wird (Laden von Quelle X, Check der Datei, Patch drüberbügeln etc.), damit ist sichergestellt dass man keine modifizierten Binaries bekommt.
Und weil manche Dinge selbst zu kompilieren Ewigkeiten brauchen können, gibt es zusätzlich noch wie bisher fertige Binärpakete, für diejenigen die eben nicht paranoid sind.

Gentoo macht das zb. so. Und auch andere Distributionen stellen sogenannte source-Pakete zur verfügung, in denen der Sourcecode, und eine build-Anleitung, vorhanden ist.

Bei "repoduceable builds" geht es darum Binärpakete auch verifizieren zu können. Bisher gibt es sonst keine Möglichkeit zu überprüfen ob der Maintainer die Binaries aus den angegebenen sourcen generiert hat, oder doch aus manipulierten (absichtlich oder auch unabsichtlich).

 

[Moranaga]

Allerdings werden die restlichen 20 Prozent der Pakete schwieriger reproduzierbar zu bauen sein als die bisherigen 80 Prozent, die über 17.000 Pakete darstellen.

Weiß jemand auch warum das so ist?

Aufwand. Dazu sind viele individuelle Anpassungen der Toolchain nötig. Das steht im verlinkten Blogpost unter "Understanding problems":

"There are still toolchain fixes to be made (more than 180 packages for the PHP registry) which can make many packages reproducible at once, but others like C pre-processor macros will require many individual changes."

 

[coolmodi]

für diejenigen die eben nicht paranoid sind.

Prinzipiell jedem gegenüber misstrauisch zu sein hat nichts mit Paranoia zu tun, und ich hab mich auch schon immer gefragt was Quellcodeangaben bringen, wenn ich doch garnicht weiß ob das auch wirklich der Code vom Programm ist.
Hätte ich wichtig wichtige Daten aufm PC wäre ich wohl auch etwas paranoid, aber so reicht mir naives Vertrauen auch

sourcen

Mit Saucen hat das nichts zu tun.
Quellen oder sources, unnötig mischen muss man die Wörter nun auch nicht

 

[Miuwa]

Tatsache ist, dass kein einzelner Mensch (auch nicht Linus Torvalds) in der Lage ist den kompletten relevaanten Quellcode eines modernen PC-Betriebssystems auf Hintertüren oder Schadcode zu überprüfen. Das Gleiche gilt für die meisten größeren Anwendungen und natürlich auch für Kompiler.
Insofern basiert die Sicherheit des eigenen Systems immer auf Vertrauen gegenüber anderen Menschen und Systemen. Das Einzige was man machen kann ist die Anzahl der SPoFs- in dieser Kette zu minimieren. Entweder indem man die Anzahl der Schritte reduziert oder für jeden Schritt so viel Redundanz wie möglich schafft.
Debians „Reproduzierbares Paketarchiv“ setzt genau hier an. An einem Punkt bei dem es - soweit ich das verstanden habe - zuvor praktisch keine Redundanz gab. Die Eliminierung dieses SPoFs macht den ganzen Prozess deutlich robuster gegen Angriffe, auch wenn es - wie jedes andere System auch - keine hundert prozentige Sicherheit gewährleisten kann - nicht einmal für den Schritt vom Quellcode zum Binary auf dem eignen Computer.

 

[Sukrim]

Dazu gab es übrigens auch einen interessanten Vortrag am 31C3 letzten Monat:

http://media.ccc.de/browse/congress..._mike_perry_-_seth_schoen_-_hans_steiner.html

 

[MusicJunkie666]

Wirklich nachweisbar finde ich das nicht. Der von ice-breaker vorgeschlagene Weg entspricht am ehesten meiner Vorstellung von reproduzierbar und nachvollziehbar.

Auf einer Atom-Krücke wie in meiner vorigen Linux-Firewall möchte ich das aber auch nicht nutzen...

 

[roidal]

Wirklich nachweisbar finde ich das nicht.

Kannst du das genauer erklären? Wenn ich das Programm selbst compiliere und exakt das selbe Binary raus bekomm, in wie weit ist dann der Nachweis nicht gegeben?

 

[mensch183]

Den Weg von Homebrew zu gehen wäre meiner Meinung nach viel sinnvoller:
Das Repository enthält für jedes Paket nur noch eine maschinenlesbare Anleitung wie das Paket gebaut wird (Laden von Quelle X, Check der Datei, Patch drüberbügeln etc.), damit ist sichergestellt dass man keine modifizierten Binaries bekommt.

Damit musst du genau denen gegenüber auf unmodifizierte Quellen vertrauen, denen du sonst trauen musst, aus eben diesen unmodifizierten Quellen nachvollziehbar Binaries erstellt zu haben. Was genau ist an deinem Vorschlag "sinnvoller"? Das nötige Vertrauen ist identisch. Der Arbeitsaufwand auf Clientseite ist höher.

Sinnvoller ist das nur, wenn du für Hardwarehersteller o.ä. arbeitest, die an mehr Arbeit auf den Clients Geld verdienen.

Reproduzierbare Builds dienen nicht nur der initialen Softwareverteilung. Du kannst auch nachher Files via Länge+Hash ansehen, ob sie verändert worden. Heute kommen 1000 plausible Erklärungen in Frage, warum dein sshd-binary ein anderes ist als bei 95% der anderen Nutzer deiner Distribution. Mit reproduzierbaren Builds wäre so eine Entdeckung hingegen plötzlich ein Hinweis auf eine ggf. bösartige Manipulation.