1 |
Hi, |
2 |
|
3 |
Please review the following pre-GLEP. |
4 |
|
5 |
--- |
6 |
GLEP: 9999 |
7 |
Title: Secrecy-respecting voting mechanism for Gentoo projects |
8 |
Author: Michał Górny <mgorny@g.o> |
9 |
Type: Standards Track |
10 |
Status: Draft |
11 |
Version: 1 |
12 |
Created: 2021-08-27 |
13 |
Last-Modified: 2021-08-27 |
14 |
Post-History: 2021-08-27 |
15 |
Content-Type: text/x-rst |
16 |
--- |
17 |
|
18 |
Abstract |
19 |
======== |
20 |
|
21 |
A new voting system is devised with the aim of providing a single voting |
22 |
system for all Gentoo elections and votes. Automation is used to |
23 |
eliminate the human bottleneck in processing the elections. Votes are |
24 |
submitted via random identifers, and the identifiers are sent to voters |
25 |
via encrypted e-mail to protect the vote secrecy. E-mail is used to |
26 |
enable non-developer voters to participate. |
27 |
|
28 |
|
29 |
Motivation |
30 |
========== |
31 |
|
32 |
The votify/countify tooling used to run Gentoo elections dates back |
33 |
to 2005. While it still serves it purpose, it has grown antiquated |
34 |
and is facing a few problems that are discouraging the developers from |
35 |
using it. These are: |
36 |
|
37 |
The problems with the current tooling include: |
38 |
|
39 |
1. The elections require a lot of manual setup and attention. This is |
40 |
causing noticeable delays and can raise doubts about the validity |
41 |
of elections. For example, voters can still submit or modify votes |
42 |
after the deadline until the infra official collects them. |
43 |
|
44 |
2. The vote secrecy is not respected properly. While the voting is |
45 |
ongoing, the votes are stored in voters' home directories. Any |
46 |
person with superuser access to dev.gentoo.org is capable of reading |
47 |
the votes. Furthermore, there has been a case of votes being |
48 |
accidentally disclosed to the mailing list by election officials. |
49 |
|
50 |
3. Including non-developers as voters is cumbersome and potentially |
51 |
violates the vote secrecy. In the past, it has been either done by |
52 |
creating temporary accounts on dev.gentoo.org, or requiring the votes |
53 |
to be sent openly via mail and therefore known to the election |
54 |
officials. |
55 |
|
56 |
At this point, votify is practically used only for the Council |
57 |
and Trustee elections. The late attempts of using it for the Base |
58 |
System and Security project elections have resulted in a lot of |
59 |
frustration from the developers participating. The vast majority of |
60 |
project elections are currently run using third-party services or plain |
61 |
mail votes. |
62 |
|
63 |
The goal of this GLEP is to propose a new voting system that meets |
64 |
the expectations of developers better, and can be easily used to run |
65 |
elections and referenda by Gentoo developers and projects. |
66 |
|
67 |
|
68 |
Specification |
69 |
============= |
70 |
|
71 |
Requirements for the election system |
72 |
------------------------------------ |
73 |
|
74 |
The new election system should meet the following requirements: |
75 |
|
76 |
1. Gentoo developers should be able to start a new election/referendum |
77 |
without requesting manual attention of any other individuals. |
78 |
|
79 |
2. The election system should cover the nomination phase if it is |
80 |
applicable, providing the necessary automation to assemble the final |
81 |
candidate list. |
82 |
|
83 |
3. All deadlines should be enforced automatically, and results should |
84 |
be published automatically as well. In particular, it must not be |
85 |
possible to modify votes after the final deadline. |
86 |
|
87 |
4. The secrecy of the votes must be protected to the best of ability. |
88 |
This includes both associating a particular vote with a voter, |
89 |
as well as determining whether a voter in question has cast a vote. |
90 |
|
91 |
5. The system should make it easy for non-developers to cast a vote |
92 |
on the same terms as developers. |
93 |
|
94 |
|
95 |
The election process |
96 |
-------------------- |
97 |
|
98 |
Each election/referendum consists of the following steps: |
99 |
|
100 |
1. A developer creates a new election/referendum. During this step, |
101 |
the developer specifies whether the boundary dates for each election |
102 |
phase, the voter list and the (potential) candidates. |
103 |
|
104 |
2. If the nomination phase is applicable, the system accepts nominations |
105 |
from the voters. Each nominated candidate is mailed about |
106 |
the nomination, and given the explicit choice of accepting |
107 |
or declining it. If the nomination is accepted, the candidate may |
108 |
also upload a manifesto. |
109 |
|
110 |
3. When the voting phase beings, the system creates random identifiers |
111 |
for all voters. Each identifier is encrypted using voter's PGP key |
112 |
and sent via email to the voter. The voter-identifier mapping is |
113 |
discarded immediately to reduce the risk of it leaking. |
114 |
|
115 |
If the nomination phase was enabled, the system also creates |
116 |
the final candidate list from nominees who accepted their nomination. |
117 |
|
118 |
4. Voters submit their votes using their random identifiers. |
119 |
|
120 |
5. When the voting phase ends, the system publishes the results |
121 |
and the master ballot. |
122 |
|
123 |
|
124 |
Rationale |
125 |
========= |
126 |
|
127 |
In the proposed system, the whole election process is automated from |
128 |
the point of creating the election, through nominations and voting |
129 |
phases, to publishing the results. Any developer can easily start |
130 |
an election without hitting a manpower bottleneck. This should make it |
131 |
possible to use the new election system both for major elections such |
132 |
as the Council elections, and small in-project elections and votes. |
133 |
|
134 |
The elections/votes can be either based on predefined candidate/option |
135 |
list, or run a semi-automated nomination phase, to account for various |
136 |
kinds of elections. |
137 |
|
138 |
The system is largely based on mail, making it possible to easily |
139 |
include voters who are not developers. The most important mails are |
140 |
PGP-encrypted to provide the necessary authentication for voters |
141 |
and protect their secrecy. |
142 |
|
143 |
This GLEP does not enforce a specific UI to the voting system. |
144 |
An example solution would be to provide a simple web-based UI to handle |
145 |
nominations and cast votes, using URLs with random identifiers sent via |
146 |
mail. Such a system would make it easy for non-developers |
147 |
to participate. Creating and managing elections could be done locally |
148 |
using scripts on dev.gentoo.org. |
149 |
|
150 |
As long as the underlying tooling is not tampered with, the system |
151 |
protects the vote secrecy through use of random identifiers. |
152 |
The association between a random identifiers and a voter name is |
153 |
preserved only for the short time needed to encrypt the identifier |
154 |
and send it via mail. Afterwards, the association is discarded. |
155 |
|
156 |
After the election concludes, the master ballot is published |
157 |
and the voters can both verify the election results, and confirm that |
158 |
their vote has been included in it. |
159 |
|
160 |
The system does not provide the ability to establish whether |
161 |
a particular voter has cast a vote or not by design. This makes it |
162 |
unsuitable for Trustee elections. |
163 |
|
164 |
|
165 |
Backwards Compatibility |
166 |
======================= |
167 |
|
168 |
The new system can replace the use of votify script, with the exception |
169 |
of Trustee elections that require the ability to determine who have |
170 |
voted. However, there is no reason not to deploy it alongside the old |
171 |
one. |
172 |
|
173 |
|
174 |
Reference Implementation |
175 |
======================== |
176 |
|
177 |
Not complete. |
178 |
|
179 |
|
180 |
Copyright |
181 |
========= |
182 |
This work is licensed under the Creative Commons Attribution-ShareAlike |
183 |
3.0 |
184 |
Unported License. To view a copy of this license, visit |
185 |
https://creativecommons.org/licenses/by-sa/3.0/. |
186 |
|
187 |
|
188 |
-- |
189 |
Best regards, |
190 |
Michał Górny |