Sign-Script und separater Benutzer

[apfohl]

Um das Manifest zu signen würde ich einen gesonderten Benutzer auf dem Build-Server anlegen. So etwas wie sign@build-server.n39.eu. Diese besitzt keine Shell sondern führt ein Script beim Login aus, welches den Benutzer nach seinem Namen fragt. Je nachdem, was der Benutzer eingibt, wird der entsprechende Private-Key ausgewählt und damit das Manifest signiert.

Dazu muss jeder Benutzer seinen Private-Key auf einem Server mit SSH-Zugang ablegen. Die Server werden im Script hinterlegt und den Namen zugeordnet.

Der Vorteil ist, dass das signing an einem Ort stattfindet und niemand das Manifest kopieren muss. Darüber hinaus werden die Private-Keys lediglich in den Speicher geladen, jedoch nicht als Datei oder String in die Konsole.

[LeSpocky]

Dazu muss das Skript dann genau wissen, wo die Images liegen. Wollen wir dazu einen Nutzer build anlegen mit SSH-Key-Login? Damit jemand™ dann Image bauen kann, bevor es signiert wird?

[LeSpocky]

Muss das zwingend vor v0.28 fertig werden? Wir könnten jene auch erstmal von Hand einmal signieren. Ich finde das wäre okay, wenn die Leute wissen, wie das geht, falls wir mal aus irgendwelchen Gründen nicht auf den Build-Server zugreifen können. Das signieren des Manifests ist nicht so aufwändig. Für eine Stable alle paar Monate ist das vom Aufwand her nicht zu viel.

[bastinat0r]

Ich bin eigentlich eher dafür ein Script zu bauen, das jeder bei sich ausführen kann und das die Binaries runterlädt, signiert, und das signierte File wieder hochlädt. Das ist deutlich sauberer als andersrum und funktioniert auch noch mit public-key-auth.

[tcatm]

Also die Idee hinter den Signaturen war eigentlich, dass diejenigen tatsächlich die Firmware mal auf Testgeräten installieren und ausprobieren ob sie überhaupt läuft (hauptsächlich ob nach dem Upgrade auch ein meshfähiges Gerät herauskommt) und das der autoupdater erst anspringt, wenn genügend Leute das getan haben.

Je nach site.conf kann man nämlich kaputte Firmwares bauen und die möchte man wahrscheinlich nicht automatisiert im ganzen Mesh verteilen.

Der Arbeitsaufwand liegt also nicht beim Signieren, sondern viel mehr dabei mal ein paar Router in die Hand zu nehmen und dort a) Updates von der alten Firmware und vielleicht sogar der Version davor auszuprobieren und b) Neuinstallationen ohne Updates auszuprobieren.

[LeSpocky]

Klingt sinnvoll für mich. Das hieße allerdings, dass wir uns das hier komplett klemmen können und doch manuell signieren.

[jplitza]

Das ist auch der Gedanke hinter private keys. Wenn ihr sie alle auf einen Server legt kann jemand, der diesen Server kapert, legitime Images erstellen, die automatisch überall geflasht werden. Wenn jeder der Entwickler seinen Private Key bei sich aufm Rechner hat, wird das wesentlich schwieriger.

[apfohl]

Die Private-Keys werden ja auch nicht auf dem Build-Server gespeichert. Sie werden per ssh in den Singning-Script-Aufruf rein gepipet.

Mein Vorschlag wäre, das Script trotzdem so umzusetzen. Nur das man erst signen darf, wenn man auch die neue Firmware getestet hat. Das sind ja zwei verschiedene Schritte.

[bastinat0r]

Ich bin immer noch der Meinung, man sollte keine Privatekeys auf dem Server lassen, egal ob die "nur im Speicher" sind, wenn ich Zugang zu dem Server habe, dann komme ich trotzdem an deinen Schlüssel. Und es ist eh weniger aufwand das skript lokal auszuführen als erst per ssh auf den server zu connecten (und den ggf auch noch dafür anzuschalten) als sich die binaries aus $quelle runterzuladen und zu signieren.

Um die Firmwares zu testen würde ich am liebsten meienen eigenen Router so einstellen, das er sich automatisch die updates zieht von irgend einem testing-branch und wenn der nicht kaputtgeht sollte das auoupdate funktionieren und komplett neu flashen kann man ja auf meinem Spielknoten im space, wenn man eh grade die firmware gebaut hat.

[penguineer]

+1

Ich würde meinen Private Key nirgendwo hin hochladen, um dort $etwas damit signieren zu lassen. Firmware herunterladen, bauen und $irgendwas (Firmware oder einen Eintrag in einem Testlog) abzeichnen, um zu bestätigen, dass das bei mir funktioniert hat. Das $etwas lade ich dann wieder hoch. Mein Key bleibt, wo er ist.

[LeSpocky]

Die Geschichte hier ist doch für stable gedacht, also für Releases. Die sollten von Hand getestet und signiert werden. Für experimental wird das doch so eingestellt, dass nur ein Key benötigt wird, so dass man das automatisieren kann.

[LeSpocky]

Ich hab mir das jetzt nochmal durchgelesen und es gefällt mir immernoch nicht. Selbst wenn mein private Key auf meinem Rechner/Server bleibt, der Build-Server loggt sich da ein, d.h. jeder, der auf dem Build-Server ist bzw. die entsprechenden Rechte erlangt, kann meinen private key bekommen? Ich glaube dann signe ich lieber manuell.

[apfohl]

Du gibst dein Passwort zum Server ein.

[penguineer]

Ich schließe mich da @LeSpocky und @bastinat0r nochmal ausdrücklich an: Die einzige Möglichkeit, die ich einer Software zum Signieren gebe, ist ein Aufruf des GnuPG auf meinem Rechner. Der private Schlüssel wird nirgendwo hin hochgeladen. Schlimm genug, dass es ihn lokal gibt. ;)

[LeSpocky]

Bin dann dafür, das Ticket zu schließen.

Für die stable waren wir ja jetzt so vorgegangen, dass stable.manifest auf den Webserver geladen wird. Die Leute laden sich das runter, signieren es, laden es wieder hoch. Wenn einem das zu umständlich ist, kann man sich da lokal 'nen Dreizeiler schreiben, so wie @bastinat0r das gemacht hat. Oder?

[penguineer]

Im Zweifel kann man ja noch eine Schritt-für-Schritt-Anleitung ablegen. Das Signing ist zwar trivial, aber wenn man sich nicht jedes Mal die gleichen Befehle wieder überlegen muss, wird es noch leichter und weniger fehleranfällig.

[bastinat0r]

Siehe https://gist.github.com/bastinat0r/92ec25686d70dcce13af