[Freifunk-Bonn] Bitte kein Auto-Update // War: Re: Nächstes Treffen: 04.01.2018 im Netzladen in Bonn, Breite Straße 74, 20:00 Uhr

Mi Jan 3 16:17:07 CET 2018

Hi yanosz,

es gibt viele gute Gründe für, eine Autoupdate Option.
Ende 2016 haben wir das im Netzladen bei einem regulären Treffen diskutiert
und uns im Konsens für die Hood Bonn dafür entschieden es in Zukunft
anzubieten.
Der Link mit der Agenda vor dem Treffen, sowie zum daraus entstandenen
Protokoll dieses Treffens ging 13 mal über den Mailverteiler[1].

Ich denke derjenige, er sich entscheidet einen Node einzurichten und
aufzustellen,
kann auch am besten selbst entscheiden welches Updateverfahren in dem
Netzwerk, über das Uplink/Downlink bezogen wird, sinnvoll ist.

Wie man Autoupdate ein oder ausschalten kann steht natürlich auch im
Wiki[2].
Ferner ist der von dir geprostete Link ins Wiki[3] bis auf die Behauptung
im ersten Satz,
dass es einen solchen Mechanismus nicht gäbe, nach wie vor korrekt - Der
empfohlene Weg ist und bleibt der Selbe wie vorher.
Es gibt auch keinen Anspruch auf Autoupdates - aber es gibt die Möglichkeit.

Die Möglichkeit Sicherheitslücken schneller schließen zu können, falls es
nötig ist.
Beispiel:
Du hast am 16.04.2017 eine Schwachstelle gepostet[4].
Einen Tag später ist die Firmware gepatch und liegt zum download bereit.
Auswertung heute, acht Monate später am Beispiel Hood Bonn(gluon Nodes,
Quelle Map):
163 Nodes gepacht (42%)
229 Nodes nicht gepacht (58%)

Ferner bietet Autoupdate bietet die Möglichkeit geplant einen
Technologiewechsel durchzuführen zu können z.B. von:
Adhoc/IBSS -> 802.11s
Batman 14 -> Batman 15 | Babel
WLAN Channel 1 -> X
.. alle Änderungen die mit der Kompatibilität zur Vorgängerversion brechen,
können heute nur parallel aufgebaut werden,
mit der Folge dass ein Legacy-Netz zurückbleibt.

Den Ansatz, dass möglichst viele sich ihre Firmware selber bauen sollen
unterstützte ich zu hundert Prozent,
von daher wird es hoffentlich eh nicht nur die eine "zentrale" Firmware
geben, sondern bunte kompatibel gebaute in jeder Hood.
Es gibt schon seit Jahren Leute innerhalb kbu, die sich ihre eigenen builds
mit ihrem eigenen Autoupdater bauen
und auf ihren Knoten Anpassungen ausprobieren.

Ob ich nun die Firmware selbst flashe, die jemand anders gebaut hat und die
auf einem zentralen Server liegt,
oder ob ich mich entscheide das von einem Autoupdate erledigen zu lassen,
setzt aus meiner Sicht das selbe Vertrauen zu dem Bauer der Firmware und
die selbe Zentralität voraus.
Man könnte sogar argumentieren, dass durch die Notwenigkeit das Autoupdates
von mehr als einer Person freigegeben werden müssen,
die aktuelle Situation verbessert wird.

Schaut man sich die anderen Communites die Gluon nutzen an z.B. alle über
30 site.confs die im Gluon Manual [5] verlinkt sind,
stellt man fest, dass jede der über 30 Communities den Autoupdater
konfiguriert hat.
(mit der Ausnahme das die Configuration von Freifunk Lausitz nicht
funktionieren wird.)
Den Gedanken, dass der Autoupdater nicht Freifunky sei scheint also nicht
Konsens zu sein.

frohes Neues,
Simon

[1] https://pad.freifunk.net/p/KBU_Agenda-2016-10-06
[2] https://kbu.freifunk.net/wiki/index.php?title=Node_
konfigurieren#Automatische_Firmware_Updates
[3] https://kbu.freifunk.net/wiki/index.php?title=FAQ#Muss_ich_m
einen_Router_manuell_Updaten_oder_kann_ich_das_automatisch_e
rledigen_lassen.3F
[4]
https://lists.kbu.freifunk.net/pipermail/freifunk-bonn/2017-April/007123.html
[5] https://gluon.readthedocs.io/en/v2017.1.x/user/site.html#site-conf

Am 02.01.2018 22:57 schrieb "yanosz" <freifunk at yanosz.net>:

Hallo,

Am 2018-01-02 um 21:28 schrieb edgar.soldin at web.de:
> On 1/2/2018 21:06, Nunatak wrote:
>> - aktuelle FirmwareHardware-Empfehlungen für Freifunk-Router --> Wiki
>> überarbeiten
>
> hey Alle,
>
> wie gesagt wär ich momentan willens die firmware zu pflegen. was mir
fehlt ist zugang zu
> - images/autoupdate.ffkbu.de

Puh - autoupdate ist eine ziemlich heiße Kiste.

Aktuell gibt es nur in Bonn [1] die pubkeys von K3V1N, Simon und g3ntleman.

Ich bin gegen die Verwendung der Autoupdate-Funktionalität
- Die fehlende Update-Verantwortung bei den Benutzer fördert einen
Service-Gedanken und läuft dem Freifunk-Prinzip zu wieder. Es schadet
damit der Community.
- Durch ein Update haben die Administratoren die Macht, Updates mit
Hintertüren aufzuspielen und in fremde, private Netze einzudringen-.
- Die Idee hinter Freifunk ist, dass Leute Ihr Netz bauen - das geht
nur, wenn sie es selbst warten und Updates einspielen.
- Jede / jeder die Updates Massenhaft ausrollen möchte, kann entweder
paralleles ssh [6] nutzen oder eigene Binaries packen (Imagebuilder).
Dafür gibt's extra Doku [5].

Zudem läuft's dem Grundsatz "Misstraue Autoritäten, fördere
Dezentralisierung" zuwider. [3,4]

Ich bin offen gesagt auch ziemlich überrascht dass die keys dort[1]
hinterlegt sind, aber die wiki das Gegenteil dokumentiert [2].
Leute, dass geht so nicht: Wenn Ihr durch Update-Keys Zugriff auf
fremde, private Netze erlangen könnt, so gehört das zumindest
dokumentiert. *Respektiert* die informationelle Selbstbestimmung (aka
Privatheit) der Leute.

Ich stelle voraussichtlich morgen mal einen Pullrequest zur Entfernung
der Keys. Man wird sehen.

Gruß, yanosz

[1] https://github.com/ff-kbu/site-ffkbu/blob/master/site.conf#L199
[2]
https://kbu.freifunk.net/wiki/index.php?title=FAQ#Muss_ich_m
einen_Router_manuell_Updaten_oder_kann_ich_das_automatisch_e
rledigen_lassen.3F
[3] https://de.wikipedia.org/wiki/Hackerethik
[4] https://www.ccc.de/de/hackerethik
[5] https://kbu.freifunk.net/2015/04/Building-OpenWRT/
[6]
https://www.linux.com/news/parallel-ssh-execution-and-single
-shell-control-them-all
--
For those of you without hope, we have rooms with color TV,
cable and air conditioning
--
_______________________________________________
Freifunk-Bonn mailing list
Freifunk-Bonn at lists.kbu.freifunk.net
https://lists.kbu.freifunk.net/cgi-bin/mailman/listinfo/freifunk-bonn
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.kbu.freifunk.net/pipermail/freifunk-bonn/attachments/20180103/c6c20765/attachment.htm>