# gpg signierte ebuilds? Howto?

## slick

Manchmal male ich mir aus was wohl passieren würde, wenn es ein böser Angreifer schafft mittels ein wenig Social Engineering oder Gesetzeskeule seinen Server in den Rsync Mirror Pool zu hängen. Er modifiziert das Ebuild für den gcc, packt einen Patch dazu und erzeugt das Digest des ebuilds neu. $USER würde vermutlich nicht Verdacht schöpfen und kompiliert alle seine Pakete mit fertiger Backdoor. (Das Szenario läßt sich auch prima auf private Rsync Mirrors übertragen, die z.B. "freundlicherweise" bereitgestellt werden da z.B. innerhalb eines ISP Netzes Traffic kostenlos ist.)

Das führt zu der Frage, wie könnte man das verhindern? 

War bzw. ist es nicht angedacht (GLEP:57) alle ebuilds mit gpg zu signieren, dass man als Endnutzer deren Authentizität prüfen kann? Ich finde aber nicht wirklich viel dazu. Das einzige was ich finde ist Pulling Validated Portage Tree Snapshots D.h. das überprüfen einzelner ebuilds ist aktuell (noch) nicht möglich?

----------

## schmidicom

Würde das den Aufwand für die Gentoo-Devs nicht enorm vergrößern? Denn mit dem signieren alleine ist es ja nicht getan, es müsste vor dem signieren auch jemand sowas wie ein Audit durchführen. Auch dürfte die sichere Aufbewahrung (also NSA sicher) des GPG-Schlüssels bei Beteiligung mehrerer Personen sich als schwierig herausstellen.

Irgendwie habe ich das Gefühl die Gentoo-Devs haben im Moment grössere Sorgen, wie zum Beispiel Leute zu finden die sich mit Samba 4 auskennen.

----------

## mrueg

Es gibt noch das Gentoo-keys Projekt [1], das sich u.a. darum kümmert einen Keyring aller Entwicklerkeys zusammenzustellen, so dass man als Endnutzer die Signaturen der Ebuilds bzw. deren Hashes leichter verifizieren kann.

Im Moment signieren einige Entwickler bereits ihre ebuilds, aber es fehlen noch Schlüsselpolicies und Überprüfungsmöglichkeiten.

Gruß

Manuel

[1] https://wiki.gentoo.org/wiki/Project:Gentoo-keys

----------

## toralf

Signierete ebuilds wären echt cool, damit man irgendwann eine vollständig vertrauenswürdige Kette con den Sourcen bis zum Kompilat hat.

Ich würde mir momentan eher Gedanken über die gewollten ebuild-Inhalte machen, z.B. wieso im Paket openssh noch immer das USE flag "hpn" per default gesetzt ist :

http://thread.gmane.org/gmane.linux.gentoo.devel/90808

----------

## kurisu

Einstweilen genügt doch webrsync-gpg, um solchen Sze­na­ri­en vorzubeugen. Klar, man muss jedes Mal einen kompletten Portage-Snapshot downloaden. Heutzutage sollte das aber kein echtes Problem mehr darstellen, oder?

----------

## ChrisJumper

Ich hätte auch gerne signierte E-Builds. Aber nach dem Heartbleed Desaster halte ich es für möglich das sich an so vielen stellen eine Fehlerquelle einschleichen kann. Das jemand bewusst Code integriert das es schwer ist Computern zu vertrauen.

Daher sollte man immer das Verhalten der eigenen Systeme überwachen und schon mal genauer drauf schauen was da passiert. Noch besser verschiedene Systeme verwenden die sich gegenseitig überwachen und unterschiedliche Updatezyklen haben.

Ich beruhige mich immer damit das ich einen evil Code ja haben müsste wenn ich alles selber Compiliere. Kenne mich jetzt aber nicht so gut mit dem System aus das ich da eine realistische Einschätzung machen könnte. Schon ein normales Update bringt ja immer genug Features mit.

So wie ich das verstanden habe werden ja die Quellen Signiert und auf Integrität geprüft und dann die Patches auch noch mal. Misstraut man den Quellen würde das bei dessen Integritätsprüfung auffallen. Misstraut man den Patches, könnte man diese da sie doch vom Umfang her kleinere Änderungen sind eigentlich auf Scha... oh stimmt. Der Umbau einer vorhandenen Funktion kann ja auch mit Sprunganweisungen so verschachtelt werden das man es weder dem Patch noch der Quelle ansieht und das ganze lediglich im gepatchen Zustand findet.

Seufz. Ernsthaft, ich glaube das ist nicht möglich. Ich verstehe auch Kritiker die ausweisen und behaupten Open Source lässt sich leichter modifizieren. Aber ich denke es ist auch die Stärke, wir haben in der Regel einen Verlauf, eine Entstehungsgeschichte der Quellcodes und Patches zumindest bei Software die wir regelmässig und langfristig einsetzen. Damit lassen sich vergleiche Anstellen oder zu einem Punkt zurückkehren den man vertraut.

Signaturen bringen doch auch keinen Sicherheitsgewinn. Natürlich hat es dann der Dev unterschrieben, aber dessen Rechner könnte Kompromittiert sein. Ihm ist ein Fehler unterlaufen.. oder oder oder. Natürlich ist eine Signatur für die Authentizität besser als keine. Aber wenn man diese nicht prüft..

Ich weiß nicht, viel sicherer würde ich mich damit auch nicht fühlen. Wohl fühle ich mich aber auf jeden Fall mit dem Compilieren aus dem Quellcode.

----------

