plattform-eva / revision-politische-rechte-2021

Diskussion zu einer gemeinsamen Antwort zur eidgenössischen Vernehmlassung 2021/61: Änderung der Verordnung über die politischen Rechte (VPR) und der Verordnung der BK über die elektronische Stimmabgabe (VEleS)
Creative Commons Zero v1.0 Universal
13 stars 1 forks source link

VEleS Art. 11 Offenlegung des Quellcodes und der Dokumentation zum System und dessen Betrieb #26

Open christiankiller opened 3 years ago

christiankiller commented 3 years ago

Wortlaut der Vorlage

Art. 11 Offenlegung des Quellcodes und der Dokumentation zum System und dessen Betrieb

1 Der Kanton sorgt dafür, dass folgende Unterlagen offengelegt werden: a. der Quellcode der Software des Systems einschliesslich der Dateien mit re-levanten Parametern; b. die Dokumentation der Software; c. Anleitungen und ergänzende Dokumentationen, die fachkundige Personen benötigen, um das System in der eigenen Infrastruktur kompilieren, in Betrieb nehmen und analysieren zu können; d. die Dokumentation der Prozesse für den Betrieb, die Wartung und die Sicherung des Systems; e. Informationen und Beschreibungen zu bekannten Mängeln.

2 Nicht offengelegt werden müssen: a. der Quellcode von Drittkomponenten wie Betriebssystemen, Datenbanken, Web- und Applikationsservern, Rechteverwaltungssystemen, Firewalls oder Routern, sofern diese weit verbreitet sind und laufend aktualisiert werden; b. der Quellcode von Behördenportalen, die mit dem System verbunden sind; c. Dokumente, für die eine begründete Ausnahme von einer Publikation insbesondere gestützt auf das Öffentlichkeits- oder das Datenschutzrecht vorliegt

Referenzen

Art. 11 Offenlegung des Quellcodes und der Dokumentation zum System und dessen Betrieb Die bisherigen Anforderungen an die Offenlegung des Quellcodes und der Dokumentation zum System und dessen Betrieb werden präzisiert. Absatz 1 enthält neu eine Liste der Unterlagen, die offengelegt werden müssen. Erläuterungen einiger Begrifflichkeiten: Abs. 1 Bst. a: Die «relevanten Parameter» umfassen alle Informationen und Daten, die notwendig sind, um das System bei sich in Betrieb zu nehmen. Abs. 1 Bst. b: Die Dokumentation der Software umfasst insbesondere das kryptografische Protokoll, die Spezifikation und das Design, Anleitungen, Testkonzepte, Berichte zu Mängeln und Korrekturen sowie Ergebnisse des Reviewprozesses. Abs. 1 Bst. c: Umfasst Dokumente, welche die Inbetriebnahme des Systems zu dessen Untersuchung unterstützen (z.B. Anleitungen, FAQ, etc.). Abs. 1 Bst. d: Umfasst die Unterlagen, die die Erfüllung der Anforderungen der VEleS dokumentieren. Dazu gehören auch Unterlagen, die wesentliche risikominimierende Massnahmen dokumentieren, auf die in der Risikobeurteilung verwiesen wird. Im Grundsatz gilt: Je stärker die Dokumentation den Betrieb, die Wartung oder die Sicherung einer sogenannten vertrauenswürdigen Komponente oder die Handhabung eines Datenträgers mit kritischen Daten betrifft, desto wichtiger ist die Offenlegung. Darüber hinaus gelten die Ausnahmebestimmungen der Öffentlichkeitsgesetzgebung. Abs. 1 Bst. e: Wenn dem Systembetreiber ein Mangel im offengelegten Quellcode oder in der Dokumen-tation bekannt ist, soll er darüber informieren. Er beschreibt den Mangel und allfällige geplante Massnahmen zur Behebung des Mangels. Dies dient der Nachvollziehbarkeit, der Transparenz und der Zusam-menarbeit mit der Öffentlichkeit. Abs. 2 Bst. c: Die begründeten Ausnahmen orientieren sich grundsätzlich an der Öffentlichkeits- und Datenschutzgesetzgebung. Zusätzlich kann bei Dokumenten mit tiefer oder keiner Relevanz für die Sicherheit des Systems und des Betriebs in begründeten Fällen von einer Publikation abgesehen werden.

Dazu gehören etwa Beschriebe von betrieblichen Prozessen ohne direkten Bezug zum System oder reine Präzisierungen, die für die Sicherheit nicht oder wenig entscheidend sind oder bei denen davon ausgegangen werden darf, dass sie korrekt umgesetzt werden. Dabei ist jeweils zwischen dem öffentlichen Interesse an der Publikation und dem Interesse an der Vertraulichkeit abzuwägen. Zu den Interessen an Vertraulichkeit können etwa interne Richtlinien, Schutz von Geschäftsinterna oder Schutz von Daten Dritter gelten.

christiankiller commented 3 years ago

sofern diese weit verbreitet sind und laufend aktualisiert werden; (#26)

oder bei denen davon ausgegangen werden darf, dass sie korrekt umgesetzt werden

Anhang überprüfen, inwiefern dies reguliert wird.

melchl commented 3 years ago

1 Der Kanton sorgt dafür, dass folgende Unterlagen offengelegt werden: ... d. die Dokumentation der Prozesse für den Betrieb, die Wartung und die Sicherung des Systems; e. Informationen und Beschreibungen zu bekannten Mängeln.

Sehe ich positiv. Bin gespannt, wie weit die Kantone konkret gehen werden.

dune73 commented 3 years ago

Die Experten haben sich deutlich für eine Open Source Lizenz ausgesprochen. Dies wird nun nicht eingefordert und der begleitende Bericht liefert dazu keine Begründung. Drastischer Ausgedrückt: Die BK will nicht das regulieren, was die eigenen Experten empfehlen und sie will auch nicht sagen warum. Gefällt mir nicht.

Ansonsten fehlen mir die Pen-Test Berichte des Systembetreibers. Und die Commit Messages.

Die Commit Messages sind einerseits wichtig für das Verständnis von Änderungen im Source Code (Changelog ist in aller Regel knapp gehalten, Commit Messages bringen idealerweise mehr Details und Begründungen) und auch für ein Beurteilung des Entwicklungsprozesses (Welche Accounts haben wann, in welchem Rhythmus, welche Code-Teile verändert. Gibt es Korrekturen, Nachbesserungen, welche Accounts arbeiten in weilen Bereichen des Codes, wieviele Accounts sind beteiligt, etc. etc. Mit diesen Informationen lässt sich sehr viel erschliessen, ohne diese Informationen ist es ein haufen Source Code.

Ansonsten ist Umfang der Publikationen und Scope der Systeme aus meiner Sicht sehr gut umrissen.