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 |