Protokoll der Sitzung der PG Basisentscheid "Thema BEO CH"¶

• Ort: Mumble NRW
• Datum: 17.12.2015
• Zeit: 20:00 CET
• Ende: hh:mm CEST
• Leitung: Moira Brülisauer
• Protokoll: Gemeinsam, Verantwortlich MBR

Anwesende¶

• Moira Brülisauer (PPV PPS)
• Tobias Stenzel (Entwickler Portal, Anpassung Discourse)
• Entropy (Entwickler ID Server)
• Stefan Thöni (Technik PPS, Juristisches PPS)
• Robert Arnold (Entwickler VVVote)

Informationen und Tasks¶

Vertragsverhandlung PPS-LV-by¶

Die Vertreter der PPS haben sich gestern mit dem Chef der Bayern IT über den Art und Umfang des Services der geboten wird. https://ppv.piratenpad.de/BEOCH2

Tasks¶

Moira¶

• Links sammeln und dokumentieren, done Siehe
• Protokoll publiziert: done
• Mockup für Design von VVVote: 1. Teil done

Stand der einzelnen Systeme?¶

Discourse¶

mitgeteilt von: escaP

• noch nicht herausgefunden, warum Discourse zu viele Requests an den ID-Server schickt. An meinem Code kann es nicht liegen.

Portal¶

mitgeteilt von: escaP

• ist jetzt mit AGPL3 auf github veröffentlicht https://github.com/dpausp/arguments
• transifex-Projekt ist wieder offen: https://www.transifex.com/ekklesia-1/arguments
• jetzt mit Nix package manager installierbar

ID Server (CH)¶

mitgeteilt von escaP und entropy

• transifex-Projekt angelegt: https://www.transifex.com/ekklesia-1/identity
• jetzt mit Nix package manager installierbar
• Installation auf pps1 in Vorbereitung, habe aktuell noch Probleme mit Ansible
• in Arbeit: Portierung auf Django 1.8 und andere Abhängigkeiten aktualisieren

VVVote (CH)¶

• notwendige Klickzahl für OAuth2-Autorisierung deutlich verringert
• 3. Eingabe des Nutzernamens beseitigt und Sicherheit verbessert
• Desgin-Verbesserung angefangen
• angefangen, eine Transportverschlüsselung für die Stimmabgabe zu implementieren

Traktanden¶

Tasks struktieren?¶

eingereicht von: MBR

Wollen wir unsere Tasks einfach mit Protokollen managen oder doch lieber mit Redminetickets arbeiten?

• Entropy: Protokoll reicht mir - weniger overhead
• Robert: mir egal
• Tobias: Protokoll reicht aktuell, evtl. später im Produktivbetrieb.

Ist somit entschieden, wir bleiben beim Tasks via Protokoll.

Nächste Schritte¶

Discourse¶

• Tobias: requests-Problem nochmal analysieren, aber niedrige Priorität
• Escap: Link zur Passwortänderung in Discourse (-> ID-Server) im Profil

Portal¶

• Escap: Weiterentwicklung ab Anfang Januar

ID Server (CH)¶

• Tobias: Installation bis Ende des Jahres
• Stefa: ich werde das ID Server Backend so anpassen, dass es für die benötigenten Daten wie UUID, E-Mail, Gliederungen, Stimmberechtigung und Akkreditierung-/Verifizierungsstatus
• Entropy: quote problem analysieren
• Robert: Für die Autorisierung des vvvote-Server beim ID-Server wird immer Login gebraucht, beim zweiten vvvote-Server muss das Login wiederholt werden.
• Moira, Entropy: Wir werden das nächstes mal noch weiter diskutieren.
• Stefan: Werde das Protokoll aufzeichnen.

VVVote (CH)¶

Es läuft aktuell eine Diskussion ob eine Sperrzeit zwischen Erstellung des Wahlmaterials und der Stimmabgabe sinnvoll ist. Moira findet die Sperrzeit mühsam und für User eine Zumutung. Deswegen entstand der Vorschlag einen dritten Server zu nehmen, wo die Stimmen zwischen gelagert werden.

Anderer Vorschlag: Die Stimmen werden zwischen 1h und 36h verzögert vom JavaScript-Client gesendet. Wenn das Browserfenster vorher geschlossen wird, wird eine Warnung ausgegeben, dass die Stimme dann nicht gesendet wird. <--- dieser Vorschlag soll umgesetzt werden. Ggf. werden Anonymisierungsserver nachgerüstet, wenn im Betrieb dann zu viele Stimmen nicht rechtzeitig auf dem Server eingehen.

Es braucht noch eine Meldung: "Der Wahlschein wird benötigt, um die Stimme abzugeben und kann nicht ersetzt werden. Daher wird empfohlen, den Wahlschein bis zum Ende der Abstimmung zu sichern."

Problem: die Stimmabgabe wird bisher nicht verschlüssel/signiert vom Server bestätigt. Ein Angreifer könnte missliebige (oder alle) Stimmen einfach mit OK bestätigen, aber die Stimme wegwerfen. Erst nach der Abstimmung könnte das auffallen und Teilnehmer könnten nicht belegen, dass sie abgestimmt haben. Mit einer signierten Quittung des Servers könnte der Abstimmer beweisen, dass er abgestimmt hat.

Vorschlag: Die Signatur der Bestätigng wird als offener Punkt aufgenommen und transparent kommuniziert (was auch allgemein für das Projekt gelten soll). Das Feature wird nach Einführung nachgerüstet (oder schon vorher, wenn denn Zeit ist).

Schluss und nächste Sitzung¶

Sitzung wird durch den Sitzungsleiter geschlossen um 22:23.

Die nächste Sitzung findet am 06.01.2016 um 20:00 CEST statt im NRW Mumble statt. Protokolllink:

Footer¶

Was soll das ganze?¶

Bitte im Redmine der PPS nachlesen, was die PPS hier umsetzt: https://projects.piratenpartei.ch/projects/beo?jump=welcome

Und wer macht das? http://wiki.piratenpartei.de/Basisentscheid/Projektgruppe

Vorherige Protokolle¶

Die Protokolle der Entwicklungsarbeit am Urabstimmungssystem für die Piratenpartei Schweiz finden sich im Wiki