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 322D3138334 for ; Sat, 27 Jul 2019 06:22:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F2927E0833; Sat, 27 Jul 2019 06:22:01 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 B2C67E0831 for ; Sat, 27 Jul 2019 06:22:01 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 8FC10348CC1; Sat, 27 Jul 2019 06:21:58 +0000 (UTC) Message-ID: Subject: [gentoo-project] [RFC] vote.gentoo.org - a new voting frontend for Gentoo Elections From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-project Cc: Gentoo Elections , infrastructure , council , trustees Date: Sat, 27 Jul 2019 08:21:54 +0200 Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-Z1VqtI+VjSeHEbsJGtt6" User-Agent: Evolution 3.30.5 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 X-Archives-Salt: a679111e-1409-429e-94eb-96755bc53436 X-Archives-Hash: 6977bf6f9b72a17847fdc93afd4d9a9f --=-Z1VqtI+VjSeHEbsJGtt6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, (CC-ing all parties interested in technicals, plus main consumers) I'd like to work on providing new web-based frontend for voting in Gentoo elections. It would replace votify in the pipeline but generate countify-compatible data, so the votes would still be counted using old tooling. Goals =3D=3D=3D=3D=3D The goals for the new system would be to: 1. Improve privacy of votes by removing connection between voters and their confirmation IDs ASAP (not storing them unencrypted on permanent storage at all). 2. Unifying voting mechanism for developers and non-developers. The latter currently vote by mail and get their votes manually hacked into the system. 3. Removing dependency on dev.gentoo.org shell access for voting. This is implied by 2. but should also support any future efforts of reducing reliance on the single system in Infra. 4. Make it possible to use the system for unofficial elections (e.g. team lead votes). Currently setting a vote up requires root privileges on dev.g.o which is not really feasible. Voter UX =3D=3D=3D=3D=3D=3D=3D=3D The idea is based on using two tokens: 1. *Secret token* which is known only to the voter, and is used to authenticate in order to cast/modify the vote. 2. *Voter ID* (formerly: confirmation ID) which is used to pseudonymously identify the vote. While IDs themselves are public, their association with a particular voter is known only to the voter. Ideally, voter_id =3D KDF(secret_token), so the voter needs only to use one of them while voting and the other will be implicit. Before the election starts, election officials prepare a list of voters containing their e-mail addresses and OpenPGP key fingerprints. They run a script which creates tokens for all voters, encrypts them, then mails them to voters. The flat list of voter IDs (without association to voters) is then stored on the server. During the voting period, voters visit a trivial web-form. They enter their secret token in order to authenticate, and are presented with a simple box to edit their vote. Once the vote is submitted, is it saved using voter ID. The site also lets voter download a copy of the vote for post-election verification. I will also provide a trivial CLI app to preserve the old 'use my favorite editor' voting experience. Once the voting period is over, election official runs another script that collects results and generates countify-compatible data. Then votes can be counted on any system, using the old tooling and results announced as usual. Technical details =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I've been wondering what would be the best implementation. I had two ideas in mind: either absolutely minimal scripting with SSH-based access for election officials, or full-fledged webapp. It's important to avoid low bus factor and follow KISS principle. Our experience shows that maintenance of most of the custom webapps for Infra has become a nightmare, so I think the former is a better option. This means that webapp would be limited to the actual voting. It will be written either in simple Python (without frameworks) or even bash.=20 Votes will be stored in plain text files. Election officials will access the server via SSH. They will be provided with a few scripts to do common things such as setting up the election, generating tokens, mailing voters, collecting results.=20 For anything less common, they will have to edit files directly. We will also provide SSH access to other devs who wish to set up unofficial elections. Access to individual election will be controlled by ownership/permissions, so regular devs won't be able to fiddle with Council or Trustee elections. Your comments =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D What are your thoughts? --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-Z1VqtI+VjSeHEbsJGtt6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAl077YJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM3 NkE4NDUwOTQwOThEMjhDQzhCMjZDNTYzOUFEQUUyMzI5RTI0MEUACgkQY5ra4jKe JA49dwf/enkxyrfrL6x4IFyotwI1sf+xKeri8QH5xoe5oTauKMg4NgFXHdD0yHsR R6FFIuUij5NoMVDhwoPw8lErI/Ylfc9nIflWNo2Or8VZJOTWC0saDIzDlrBbhv+g r3C3uIu3UFLW0Lag0Mvhs142pSGoZsUgDO1LWSJIHW2xtyCWM8uiEeMjFhz9d0gd 9KUvMoAAVYTjslFUYC0pcuk7RClWWqVs6611vtCRQ6pdZXiMnnwYvL/zQ0Frqj0D fPCWeHblax28xC2np0XIPoROLaUrAUclxvc2o6sDInvvsp0zmcTSuX1vgNv6duyr LQJctiI3rAMV3QBJtfKpzlm1mX2Rig== =q7Wd -----END PGP SIGNATURE----- --=-Z1VqtI+VjSeHEbsJGtt6--