CommunityDay2019
Draft!
Details
Wann?
In 2019? https://dudle.inf.tu-dresden.de/FFKBUCommunityDay2019/
Wo?
C4?
Programm
Status 100x Wlan
Landesföderprogramme
KBU Backbone Arbeit
Adminbootcamp
Wireguard in der Hood Bonn v2
FFRL Werbeblock
??????????
Mesh ./. Ad-Hoc (802.11s ./. IBSS)
- Was sind die genauen Gründe, für den Wechsel auf 802.11s in Bonn v2?
- Welche Hinweis geben wir Freifunkern, deren Hardware kein 802.11s kann? (z.B. RaPis)
- Warum zieht Bonn auf 802.11s um - Köln und Umland jedoch nicht?
yanosz denkt, es wäre gut, wenn wir:
- den gleichen Modus überall verwenden (also 802.11s default überall)
- den Modus konfigurierbar halten (soweit möglich)
- auf der Karte anzeigen, welcher Modus verwendet wird, damit pico-Peering möglich ist.
Dokumentation Auto-Updater
Situation
- Seit Firmware 1.4 (2016??) ist der Auto-Updater per default aktiv (Opt-Out). Einige Freifunkker haben damit Zugriff auf private Router und Netze, um Software zu installieren.
- Bis 01/2018 wurden die Benutzerinnen und Benutzer im unklaren gelassen - die Dokumentation sagte aus, dass es keine Update-Funktion gibt und keine Updates verteilt werden können.
- Seit 01/2018 gibt es einen Hinweis in der Wiki, dass die Firmware über einen Auto-Updater verfügt. Benutzerinnen und Benutzer werden informiert und darauf hingewiesen, dass der Auto-Updater bei Interesse deaktiveren werden kann. Falls überlesen, werden Benutzer/innen nicht erneut aktiv mit der Entscheidung (automatische Updates ja / nein) konfrontiert. Stand jetzt ist kein Fall eines automatischen Updates bekannt.
Probleme / Issues
1. Hintertür-Problem
Freifunker haben aktuell noch ohne Zustimmung und ggf. Kenntnis des Aufsteller/innen Zugriff auf private Netze & Daten. Bis 01/2018 wurden Aufsteller(innen) über die Zugriffsmöglichkeit irregeleitet.
yanosz findet es indiskutabel, dass sich Freifunker auf diese Weise verdeckt Zugriff auf private Daten und Netze verschaffen können: Falls jmd. denkt, dass es cool ist, unter falschen Angaben Zugang zu privaten Netze & Daten zu erlangen gibt es Diskussionsbedarf.
Es steht für yanosz außer Frage, dass die Benutzer dem Autoupdater aktiv zustimmen müssen: Es muss klar erkennbar sein:
- Was ist die Konsequenz: Wer hat Zugang zu den privaten Netzen der Nutzer?
- Wer hat wann welches Update ausgegrollt (audit history)?
- Welche Infos gibt es bei einem Update (changelog)?
- Welche Policy gibt es für automatische Updates (Key-Management, 4-Augen-Prinzip, etc.)
Diskussionspunkte:
- Wie soll die/der Benutzer/in Updates zustimmen (Radio-Button / Feld im Config-Mode? / Hinweis)?
- ToDos für die Key-Inhaber
- Re-keying, löschen aktueller Keys: Ernsthafte Zusicherung, dass geschaffene Zugänge gelöscht wurden, sofern Aufsteller/innen nicht explizit zugestimmt haben.
- Nachvollziehbare Dokumentation der Ownership (PGP / Web-Of-Trust?)
- Soll die Zustimmung der Nutzer dokumentiert werden? Falls ja, wie?
- Wie werden ausgerollte Updates dokumentiert?
- Wiki-Seite mit changelog
- E-Mail über spezielle Liste?
- Kontrolle / Auditing in der Community?
2. Es-gibt-keine-Updates-Problem - es gibt keine Auto-Updater ja/nein Entscheidung.
Die Dokumenation suggierte aktuell, dass es einen Auto-Updater bzw. automatische Updates gibt. Benutzer/innen gehen z.T. gutgläubig davon aus. Die / der Benutzer/in kann sich für oder gegen automatische Updates zeigen.
Diskussionspunkte:
- Welche Dokumentation macht Stand jetzt Sinn? Wie soll die aktuelle Firmware beschrieben werden? Evtl. klarer herausstellen: Es geht nicht um automatische Updates, sondern um Zugriffsrechte auf private Netze.
- Auto-Updater ist keine ja / nein - dafür / dagegen Frage. Es wird immer Leute geben, die "Ihre"-Firmware bauen. Das ist der Sinn des Projekts! Wie kann dies aus der Dokumentation hervorgehen?
Ideen / Arbeitspunkte / Anregungen
- Wir branchen jetzt eine neue Firmware für neue Devices. Was tun?
- Auto-Update klar als Projekt einzelner Freifunker herausstellen: Es gibt auch Leute, die auch eine Firmware bauen, wo ihre Keys hinterlegt, damit sie ggf. Updates einspielen können. Wer macht genau was?
- Netzstabilität ohne Auto-Updater (Notfall-Plan für fastd-Port Rotation)?
- Das Scharf-Schalten (d.h. verlinken als Download in der Installationsanleitung) sollte der letzte Schritt sein - d.h. die Doku-Todos müssen erledigt sein, bevor entsprechende Software zum Download angeboten wird.
- Vorschlag zur Auto-Updater Umsetzung
- 2 Branches: Mit / ohne Auto-Updater (2018.x) asap für alle Hoods
- Zunächst nur Firmware ohne Auto-Updater in der Anleitung verlinken
- Wenn die Doku fertig ist und es regelmäßige Updates gibt: Hinweise in Installationsanleitung aufnehmen.