Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: gentoo-project@l.g.o
Cc: Gentoo Elections <elections@g.o>, infrastructure <infrastructure@g.o>, council <council@g.o>, trustees <trustees@g.o>
Subject: Re: [gentoo-project] Re: [RFC] vote.gentoo.org - a new voting frontend for Gentoo Elections
Date: Sat, 27 Jul 2019 11:18:58
Message-Id: b0672a6f0ae409c1b82caed11dd2d77f30a7c369.camel@gentoo.org
In Reply to: [gentoo-project] Re: [RFC] vote.gentoo.org - a new voting frontend for Gentoo Elections by Roy Bamford
1 On Sat, 2019-07-27 at 11:40 +0100, Roy Bamford wrote:
2 > On 2019.07.27 07:21, Michał Górny wrote:
3 > > Hi,
4 > >
5 > > (CC-ing all parties interested in technicals, plus main consumers)
6 > >
7 > > I'd like to work on providing new web-based frontend for voting
8 > > in Gentoo elections. It would replace votify in the pipeline but
9 > > generate countify-compatible data, so the votes would still be counted
10 > > using old tooling.
11 > >
12 > >
13 > > Goals
14 > > =====
15 > > The goals for the new system would be to:
16 > >
17 > > 1. Improve privacy of votes by removing connection between voters
18 > > and their confirmation IDs ASAP (not storing them unencrypted
19 > > on permanent storage at all).
20 > >
21 > > 2. Unifying voting mechanism for developers and non-developers.
22 > > The latter currently vote by mail and get their votes manually hacked
23 > > into the system.
24 > >
25 > > 3. Removing dependency on dev.gentoo.org shell access for voting.
26 > > This
27 > > is implied by 2. but should also support any future efforts of
28 > > reducing
29 > > reliance on the single system in Infra.
30 > >
31 > > 4. Make it possible to use the system for unofficial elections (e.g.
32 > > team lead votes). Currently setting a vote up requires root
33 > > privileges
34 > > on dev.g.o which is not really feasible.
35 > >
36 >
37 > 5. Election Officials shall have a means to determine the voter turmout
38 > from time to time while the election is in progress.
39 >
40 > Today, its carried out by the -infra contact and publicised in reminders
41 > to vote, IRC channel topics etc
42
43 Oh, I though those mails are directed to all listed officials
44 for an election and assumed this is nothing new to solve. Sure, this is
45 entirely feasible.
46
47 >
48 > [snip]
49 >
50 > > Before the election starts, election officials prepare a list of voters
51 > > containing their e-mail addresses and OpenPGP key fingerprints. They
52 > > run a script which creates tokens for all voters, encrypts them, then
53 > > mails them to voters.
54 >
55 > How do we deal with expired public keys?
56
57 When token mails are generated GPG automatically verifies whether keys
58 are usable. As a result, if someone has an expired key, the script
59 explicitly notes it and returns an error.
60
61 >
62 > Devs get a warning at commit time before their key expires. Non devs
63 > will not be permitted (by gpg) to sign a ballot with an expired key.
64 > Here, the election officials script will be attempting to make use of
65 > expired keys.
66 >
67 > I can see another requirement ...
68 > 6. At the record date for any election, voters public keys shall be
69 > checked for validity until at least the end of the voting period.
70 >
71 > That will give election officials time to remind the electorate to fix
72 > their keys.
73
74 You can't sign votes using your key, as this kills the privacy
75 requirement. Instead, we rely on secret token mails being encrypted
76 using voter's key. Key only needs to be valid at encryption time,
77 as you can decrypt messages from the past ;-).
78
79 --
80 Best regards,
81 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature