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: Fri, 09 Aug 2019 06:02:38
Message-Id: 27f3f126c9e90860a901e091b6052e0c8a38a6e5.camel@gentoo.org
In Reply to: Re: [gentoo-project] Re: [RFC] vote.gentoo.org - a new voting frontend for Gentoo Elections by "Robin H. Johnson"
1 On Fri, 2019-08-09 at 05:49 +0000, Robin H. Johnson wrote:
2 > On Sat, Jul 27, 2019 at 11:40:12AM +0100, Roy Bamford wrote:
3 > > On 2019.07.27 07:21, Michał Górny wrote:
4 > > > Hi,
5 > > >
6 > > > (CC-ing all parties interested in technicals, plus main consumers)
7 > > >
8 > > > I'd like to work on providing new web-based frontend for voting
9 > > > in Gentoo elections. It would replace votify in the pipeline but
10 > > > generate countify-compatible data, so the votes would still be counted
11 > > > using old tooling.
12 > > >
13 > > >
14 > > > Goals
15 > > > =====
16 > > > The goals for the new system would be to:
17 > > >
18 > > > 1. Improve privacy of votes by removing connection between voters
19 > > > and their confirmation IDs ASAP (not storing them unencrypted
20 > > > on permanent storage at all).
21 > > >
22 > > > 2. Unifying voting mechanism for developers and non-developers.
23 > > > The latter currently vote by mail and get their votes manually hacked
24 > > > into the system.
25 > > >
26 > > > 3. Removing dependency on dev.gentoo.org shell access for voting.
27 > > > This
28 > > > is implied by 2. but should also support any future efforts of
29 > > > reducing
30 > > > reliance on the single system in Infra.
31 > > >
32 > > > 4. Make it possible to use the system for unofficial elections (e.g.
33 > > > team lead votes). Currently setting a vote up requires root
34 > > > privileges
35 > > > on dev.g.o which is not really feasible.
36 > > >
37 > >
38 > > 5. Election Officials shall have a means to determine the voter turmout
39 > > from time to time while the election is in progress.
40 >
41 > 6. The voting system must produce a list of voters who cast a valid
42 > ballot. This is required to see which voters did not cast a ballot in
43 > the Foundation elections, and could thus be struck off the member list
44 > for failure to participate.
45 >
46 > This might be implemented via two separate identifiers from the secret
47 > per your ideas.
48
49 Do I understand correctly that you want:
50
51 1. one derived identifier to be used to cast the vote and stored without
52 association to developer,
53
54 2. another derived identifier to be used to confirm the vote, and stored
55 with association to developer?
56
57 I suppose this could work. However, it would weaken the privacy
58 protection much. Any active watcher (say, Infra or election official)
59 would be able to notice simultaneous appearance of the vote
60 and the voter entry. Sure, they could also break the system by hacking
61 the scripts over or adding voters manually rather via the script
62 but the whole point is to limit privacy exposure to the minimum.
63
64 Furthermore, I believe the fact whether one has voted or not is also
65 a matter of privacy. Expecting people to explicitly indicate this is
66 violating it, so it doesn't seem the correct solution to the problem
67 at hand.
68
69 Maybe Trustees should consider finding a better way of determining when
70 to retire inactive members? The simplest solution that comes to my head
71 is finally requiring all Foundation members to be active developers, or
72 at least setting same rules for both groups (i.e. retiring Foundation
73 members when they stop making new contributions to Gentoo). Given that
74 there are only a few Foundation members who are not devs, either way
75 shouldn't be a real issue.
76
77 --
78 Best regards,
79 Michał Górny

Attachments

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