From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C7882158013 for ; Sat, 28 Aug 2021 10:30:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1D730E089A; Sat, 28 Aug 2021 10:30:21 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D19CCE0895 for ; Sat, 28 Aug 2021 10:30:20 +0000 (UTC) Message-ID: Subject: [gentoo-project] [pre-GLEP] Secrecy-respecting voting mechanism for Gentoo projects From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-project@lists.gentoo.org Date: Sat, 28 Aug 2021 12:30:15 +0200 Organization: Gentoo Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: 0cb06a8f-7523-4ce4-bac2-0be9af0fbfda X-Archives-Hash: 87a953463a192c1d7fc9d43140a4ec52 Hi, Please review the following pre-GLEP. --- GLEP: 9999 Title: Secrecy-respecting voting mechanism for Gentoo projects Author: Michał Górny Type: Standards Track Status: Draft Version: 1 Created: 2021-08-27 Last-Modified: 2021-08-27 Post-History: 2021-08-27 Content-Type: text/x-rst --- Abstract ======== A new voting system is devised with the aim of providing a single voting system for all Gentoo elections and votes. Automation is used to eliminate the human bottleneck in processing the elections. Votes are submitted via random identifers, and the identifiers are sent to voters via encrypted e-mail to protect the vote secrecy. E-mail is used to enable non-developer voters to participate. Motivation ========== The votify/countify tooling used to run Gentoo elections dates back to 2005. While it still serves it purpose, it has grown antiquated and is facing a few problems that are discouraging the developers from using it. These are: The problems with the current tooling include: 1. The elections require a lot of manual setup and attention. This is causing noticeable delays and can raise doubts about the validity of elections. For example, voters can still submit or modify votes after the deadline until the infra official collects them. 2. The vote secrecy is not respected properly. While the voting is ongoing, the votes are stored in voters' home directories. Any person with superuser access to dev.gentoo.org is capable of reading the votes. Furthermore, there has been a case of votes being accidentally disclosed to the mailing list by election officials. 3. Including non-developers as voters is cumbersome and potentially violates the vote secrecy. In the past, it has been either done by creating temporary accounts on dev.gentoo.org, or requiring the votes to be sent openly via mail and therefore known to the election officials. At this point, votify is practically used only for the Council and Trustee elections. The late attempts of using it for the Base System and Security project elections have resulted in a lot of frustration from the developers participating. The vast majority of project elections are currently run using third-party services or plain mail votes. The goal of this GLEP is to propose a new voting system that meets the expectations of developers better, and can be easily used to run elections and referenda by Gentoo developers and projects. Specification ============= Requirements for the election system ------------------------------------ The new election system should meet the following requirements: 1. Gentoo developers should be able to start a new election/referendum without requesting manual attention of any other individuals. 2. The election system should cover the nomination phase if it is applicable, providing the necessary automation to assemble the final candidate list. 3. All deadlines should be enforced automatically, and results should be published automatically as well. In particular, it must not be possible to modify votes after the final deadline. 4. The secrecy of the votes must be protected to the best of ability. This includes both associating a particular vote with a voter, as well as determining whether a voter in question has cast a vote. 5. The system should make it easy for non-developers to cast a vote on the same terms as developers. The election process -------------------- Each election/referendum consists of the following steps: 1. A developer creates a new election/referendum. During this step, the developer specifies whether the boundary dates for each election phase, the voter list and the (potential) candidates. 2. If the nomination phase is applicable, the system accepts nominations from the voters. Each nominated candidate is mailed about the nomination, and given the explicit choice of accepting or declining it. If the nomination is accepted, the candidate may also upload a manifesto. 3. When the voting phase beings, the system creates random identifiers for all voters. Each identifier is encrypted using voter's PGP key and sent via email to the voter. The voter-identifier mapping is discarded immediately to reduce the risk of it leaking. If the nomination phase was enabled, the system also creates the final candidate list from nominees who accepted their nomination. 4. Voters submit their votes using their random identifiers. 5. When the voting phase ends, the system publishes the results and the master ballot. Rationale ========= In the proposed system, the whole election process is automated from the point of creating the election, through nominations and voting phases, to publishing the results. Any developer can easily start an election without hitting a manpower bottleneck. This should make it possible to use the new election system both for major elections such as the Council elections, and small in-project elections and votes. The elections/votes can be either based on predefined candidate/option list, or run a semi-automated nomination phase, to account for various kinds of elections. The system is largely based on mail, making it possible to easily include voters who are not developers. The most important mails are PGP-encrypted to provide the necessary authentication for voters and protect their secrecy. This GLEP does not enforce a specific UI to the voting system. An example solution would be to provide a simple web-based UI to handle nominations and cast votes, using URLs with random identifiers sent via mail. Such a system would make it easy for non-developers to participate. Creating and managing elections could be done locally using scripts on dev.gentoo.org. As long as the underlying tooling is not tampered with, the system protects the vote secrecy through use of random identifiers. The association between a random identifiers and a voter name is preserved only for the short time needed to encrypt the identifier and send it via mail. Afterwards, the association is discarded. After the election concludes, the master ballot is published and the voters can both verify the election results, and confirm that their vote has been included in it. The system does not provide the ability to establish whether a particular voter has cast a vote or not by design. This makes it unsuitable for Trustee elections. Backwards Compatibility ======================= The new system can replace the use of votify script, with the exception of Trustee elections that require the ability to determine who have voted. However, there is no reason not to deploy it alongside the old one. Reference Implementation ======================== Not complete. Copyright ========= This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. To view a copy of this license, visit https://creativecommons.org/licenses/by-sa/3.0/. -- Best regards, Michał Górny