Firmware/Releaseprozess: Unterschied zwischen den Versionen

Version vom 15. Dezember 2018, 14:44 Uhr

Auf dieser Wikiseite werden die notwendigen Schritte zum Release einer neuen Firmware dokumentiert.

Release taggen

Jedes Release wird mit einem PGP-signierten Tag (-s) versehen. Dabei enthält die Tag-Message jeweils eine kurze Zusammenfassung der Änderungen. Beachte bei der Erstellung des Tags bitte unsere Dokumentation zur Versionierung. Wichtig Hier erst weiter machen wenn ein release tag gemäß der Versionierung Seite vorhanden ist.

Vorlage für die Tag-Message:

Release firmware version <VERSION>.

Changes:
 * Short list of bullet points with changes made in this version

Befehle zum taggen:

git tag -s VERSION #tag anlegen
git show VERSION #tag anzeigen
git push origin --tags #tag hochladen

Git message editor ändern:

git config --global core.editor "vim"

Firmware kompilieren

Siehe Firmware/Kompilieren.

Wichtig Firmwares + Manifest auf den Server hochladen und auch die modules für die opkg packages!

Firmware signieren

Es gab am 29.01.2017 den Vorschlag von Eike, den Wert good_signatures nicht wie bisher auf >50% aller Signaturen zu setzen, sondern hier einen konstanten Wert (5) zu setzen. Dieser Vorschlag wurde in der Diskussion um den sign-request für das Release 20171126 von Tarek wieder aufgegriffen, allerdings mit good_signatures=4 (siehe Dev-ML vom 09.12.2017). Es wurde mit der Mehrheit für diese Änderung gestimmt. Somit Ist nun ein konstanter Signatur wert von 4 gesetzt.

Hinweis zur Erstsignatur

Die erste Signatur in einer Manifest Datei stammt immer von der Person, die die Firmware kompiliert hat und wird von dieser noch vor dem Upload der Firmware hinzugefügt. Nachfolgende Signateure sind angehalten diese Signatur zu validieren.

Siehe dazu auch die Diskussion auf der Dev-Liste "0.5.6.2 die zweite" vom 17.06.2015.

Signatur durchführen

Vor einem Release wird die Firmware signiert, damit das Autoupdate prüfen kann, ob es sich um eine valide Firmware der Freifunkentwickler handelt. Es werden gültige Signaturen von mindestens X Entwicklern benötigt. Im folgenden wird der Signaturprozess beschrieben. Es wird ein Linux-System mit installierten ecdsautils benötigt.

Zuerst wird ein Arbeitsverzeichnis firmware erstellt und darin ein Vereichnis release_keys angelegt

mkdir firmware
cd firmware
mkdir release_keys

Im Verzeichnis release_keys legen wir unser Zertifikat und unseren Privaten Signatur-Key ab (ecdsa-privatekey und ecdsa-publickey). Anschließend legen wir die das Manifest stable.manifest in unseren Arbeitsordner firmware.

Dann laden wir das Manifest herunter, welches wir signieren möchten:

scp firmware.ffnw.de:/var/www/dev/firmware/<l2tp/fastd>/<VERSION>/sysupgrade/stable.manifest stable.manifest

Dann holen wir uns die zum Signieren notwendigen Scripte aus dem Gluon-Repo und signieren das manifest:

git clone https://github.com/freifunk-gluon/gluon.git
./gluon/contrib/sign.sh ./release_keys/ecdsa-privatekey ./stable.manifest

Nach erfolgreicher Signatur, müssen wir das Manifest wieder hochladen:

scp stable.manifest firmware.ffnw.de:~
ssh firmware.ffnw.de
sudo -s
mv stable.manifest /var/www/dev/firmware/<l2tp/fastd>/<VERSION>/sysupgrade/stable.manifest

Einen Versuch, das oben stehende so weit wie möglich zu automatisieren und somit den Signaturprozess und unkompliziert wie möglich zu machen stellt dieses shell-script dar

Sign-Request auf Dev-Mailingliste veröffentlichen

Auf der Dev-Mailingliste sollte eine Aufforderung an die Entwickler zur Signierung der Firmware veröffentlicht werden. Dieser sollte enthalten:

* Version der Firmware
* Versionsnummer der Gluon-Basis
* Commit ID der Gluon-Basis
* Einen Link auf den Download der Firmware
* Kurzbeschreibung der Änderungen
* Eine explizite Bitte die Änderungen zu prüfen und die Signatur durchzuführen 
* Einen Link auf die Dokumentation zur Durchführung der Signatur

Kopiervorlage:

Hi,

Ich habe heute eine neue Firmware gebaut. Basisdaten:
 * Firmware-Version:
 * Gluon-Version:
 * Commit ID:
 * Download:

Folgende Gluon spezifischen Änderungen gab es unter anderen:

* HIER PUNKTE [0]
* HIER PUNKTE

Die upstream Änderungen findet ihr hier:

https://github.com/freifunk-gluon/gluon/compare/<alte commit ID>...<neu commit ID>

Folgende Comunnity spezifischen Änderungen gab es im package repo:

 * HIER PUNKTE
 * HIER PUNKTE [1]

Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden:

https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/<alte Version>...<neue Version>

Folgende Comunnity spezifischen Änderungen gab es im siteconf repo:

 * HIER PUNKTE
 * HIER PUNKTE

Die Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden:

https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/<alte Version>...<neue Version>

Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu
signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter:
http://wiki.nordwest.freifunk.net/Firmware/Releaseprozess#Firmware_signieren

Viele Grüße

[0]
[1]

Release-Announcement auf Blog veröffentlichen

Auf dem Blog sollte ein Release-Announcement veröffentlicht werden. Dieses sollte folgende Informationen enthalten:

Einleitender Text ("Hiermit veröffentlich wir..." o.Ä.)
Version der Firmware
Versionsnummer der Gluon-Basis
Downloadlink
Kurzbeschreibung der Änderungen
Einen Link auf die Dokumentation zu unserer Firmware
- https://wiki.nordwest.freifunk.net/Router/Firmware
Einen Link auf die Dokumentation zur Gluon-Firmware
- https://gluon.readthedocs.org/en/stable/
Einen Link auf die Seite der Unterstützten Geräte in der Gluon Dokumentation
- http://gluon.readthedocs.io/en/stable/#supported-devices-architectures

Symlink umbiegen

Sind genügen Signaturen vorhanden, muss der Symlink, der auf die aktuelle Firmware aus dem Stable-Channel zeigt auf die neue Version umgebogen werden:

cd /var/www/dev/firmware/
unlink stable
ln -s VERSION stable

Das symlinken des manifest ist nicht mehr nötig, da der Firmware-bot dies tut.

Allgemeines zu Signaturen

Signaturkeys erstellen

Dieser Prozess ist nur einmal beim Beitritt in das Dev-Team notwendig. Es wird Schreibzugriff auf das Siteconf Git Repository benötigt.

Privaten Key erstellen:

% ecdsakeygen -s > ecdsa-privatekey
% cat ecdsa-privatekey
68b12c0eaf88bf17fbcdf560780136b9cc4be352fb8aa7148215fbd65887db7b

Öffentlichen Key erstellen:

% ecdsakeygen -p < ecdsa-privatekey
1f63ef7450760af9062ff697995eb536eef25a555822087fa4cfd9a82d9faa79

Beide Keys speichern wir uns sicher ab, da diese Keys in Zukunft bei jedem Signaturprozess benötigt werden. Den öffentlichen Key tragen wir in der site.conf in den Abschnitt Autoupdater->Pubkeys ein.

Signatur manuell prüfen

Ob eine bestimmte Signatur in der Manifest Datei gültig ist, kann wie folgt geprüft werden:

* Signaturen aus manifest Datei entfernen (Die Signaturen am Ende der Datei inklusive der "---" müssen entfernt werden)
* ecdsaverify -s ZuPrüfendeSignatur -p PassenderPublicKey stable.manifest
* echo $?

Ist das Ergebnis 0 ist die Signatur korrekt, ist das Ergebnis 1 ist die Signatur falsch. Siehe https://github.com/tcatm/ecdsautils