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 C37D6158013 for ; Sat, 28 Aug 2021 20:05:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 913ACE0885; Sat, 28 Aug 2021 20:05:50 +0000 (UTC) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 4531FE0863 for ; Sat, 28 Aug 2021 20:05:50 +0000 (UTC) Received: by mail-ed1-x52d.google.com with SMTP id dm15so15152079edb.10 for ; Sat, 28 Aug 2021 13:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gentoo-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=raK64Ibm9V55GjNRVjj9w/w205K0FZKqyeo/icz3dj4=; b=y7/waLRVPX/cP/DKXNqF7tdyJsahga1m4oKtU6HG9CyPspIU47K6BxKwh9ogM+7Z6T JIukPB4BWj/rK/l/nV88GupqmYpPQBmCG3p0EO+CoT1fWZT7wvpqOr9XbuJrF06c1LYD SUg0fWEp2dwK3+Uk1hE6/gPp6DxmxOjXibd5GgBQcMLuXFaLvViGlSKjZXOnucrJCrx6 UN/4AxD97nQDDI6EDjSc4G9b1g/poQ8joY6nr2W9eqvb34H8xSMIlu9HHbsK2bD2ungJ jsFd7eV/PMn3+l/B4V5pnGM8nHDCkm1thX+TaJefZ8b6F+VAdJxuBzU9+Cir5dpZHCkq 5vBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=raK64Ibm9V55GjNRVjj9w/w205K0FZKqyeo/icz3dj4=; b=jxICMxNbdgxpshjjaIveywHICX0ZzOlHcuSTe9Mk0wekNQsBFyG+i33d6Nd2rJ18mv FvKdLAvTXDYX7HUc9M/2DAqjxS6KS9LTboTMhO8vErM/aHBSanJU5hs+lW8juevWNqh2 I+YX5Wt+23hMPIaSHsvfWIaEjeYhPeOs1/sxANvrdIia9GBwvRoN+GhExvlmK83Eqaw9 CNgTY9JTWNL8BYLTNh+yDxG7IiDuVD9tZGgyhH0BwSGQqUJsJhSKoo5LK+T6viwl892N 30my0BOTx5rb3SyceySV5gL6W6bYzJkwzhR81MS1gnoBS6SFjTUwEW4EyCyCmEvdym32 DSjQ== X-Gm-Message-State: AOAM531pAYxEbuJFNc3abZUPMbRDF+YMSmpiORpDavVFQqv7B1FgDU8y 8QEkDxZENUacQwzCTM+4hDrx4Ea1jBs6RWxj5sgQHrw8XdLo4w== X-Google-Smtp-Source: ABdhPJwWF8OMf6ndgBN0hojpX7Dvr3h23hL5+zcU+d/MvqRmE25qMxmJDo8zcq8MaLPeRG1uo9xCUDWVrrd6orn2Ki8= X-Received: by 2002:a50:fa93:: with SMTP id w19mr6847479edr.86.1630181148398; Sat, 28 Aug 2021 13:05:48 -0700 (PDT) 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 References: In-Reply-To: From: Alec Warner Date: Sat, 28 Aug 2021 13:05:37 -0700 Message-ID: Subject: Re: [gentoo-project] [pre-GLEP] Secrecy-respecting voting mechanism for Gentoo projects To: gentoo-project Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 93e42c38-d182-4da1-805b-7c7c10d6cbd5 X-Archives-Hash: fbf74ca315d374d00f84075a7e7c42ed On Sat, Aug 28, 2021 at 3:30 AM Micha=C5=82 G=C3=B3rny = wrote: > > Hi, > > Please review the following pre-GLEP. > > --- > GLEP: 9999 > Title: Secrecy-respecting voting mechanism for Gentoo projects > Author: Micha=C5=82 G=C3=B3rny > 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 > =3D=3D=3D=3D=3D=3D=3D=3D > > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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. Why do you want secret elections? > > 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. I'm not sure disclosing "frustration" is sufficient. If there was frustration (and FWIW I believe there was) it would be great to get some detail on the list. > > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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. This seems like a fairly generic problem; are we not sure that a solution already exists? > > > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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. I'm currently a trustee; and I do not necessarily desire a secret election for board members; so I'm fine with not using this proposal for that. > > > Reference Implementation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Not complete. > > > Copyright > =3D=3D=3D=3D=3D=3D=3D=3D=3D > 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=C5=82 G=C3=B3rny > > >