Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: gentoo-project@l.g.o
Subject: [gentoo-project] [pre-GLEP] Secrecy-respecting voting mechanism for Gentoo projects
Date: Sat, 28 Aug 2021 10:30:22
Message-Id: fb69ffd202cc8a24b2ea33b44fdd7b869b7f44ce.camel@gentoo.org
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

Replies