CommunityDay2019: Unterschied zwischen den Versionen

Aus Freifunk Köln, Bonn und Umgebung
Zur Navigation springen Zur Suche springen
Zeile 51: Zeile 51:


Es steht für yanosz außer Frage, dass die Benutzer dem Autoupdater aktiv zustimmen müssen: Es muss klar erkennbar sein:
Es steht für yanosz außer Frage, dass die Benutzer dem Autoupdater aktiv zustimmen müssen: Es muss klar erkennbar sein:
* Wer hat Zugang zu den privaten Netzen der Nutzer?
* Was ist die Konsequenz: Wer hat Zugang zu den privaten Netzen der Nutzer?
* Wer hat wann welches Update ausgegrollt (audit history)?
* Wer hat wann welches Update ausgegrollt (audit history)?
* Welche Infos gibt es bei einem Update (changelog)?
* Welche Infos gibt es bei einem Update (changelog)?

Version vom 13. Januar 2019, 00:02 Uhr

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

  1. Wir branchen jetzt eine neue Firmware für neue Devices. Was tun?
  2. 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?
  3. Netzstabilität ohne Auto-Updater (Notfall-Plan für fastd-Port Rotation)?
  4. 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.
  5. Vorschlag zur Auto-Updater Umsetzung
    1. 2 Branches: Mit / ohne Auto-Updater (2018.x) asap für alle Hoods
    2. Zunächst nur Firmware ohne Auto-Updater in der Anleitung verlinken
    3. Wenn die Doku fertig ist und es regelmäßige Updates gibt: Hinweise in Installationsanleitung aufnehmen.