[gentoo-project] [RFC] vote.gentoo.org - a new voting frontend for Gentoo Elections

[gentoo-project] [RFC] vote.gentoo.org - a new voting frontend for Gentoo Elections

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3823 bytes --]

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
=====
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
========
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 = 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
=================
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. 
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. 
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
=============
What are your thoughts?

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

[gentoo-project] Re: [RFC] vote.gentoo.org - a new voting frontend for Gentoo Elections

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 2467 bytes --]

On 2019.07.27 07:21, Michał Górny wrote:
> 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
> =====
> 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.
> 

5. Election Officials shall have a means to determine the voter turmout
from time to time while the election is in progress.

Today, its carried out by the -infra contact and publicised in reminders
to vote, IRC channel topics etc

[snip]

> 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.

How do we deal with expired public keys?

Devs get a warning at commit time before their key expires. Non devs
will not be permitted (by gpg) to sign a ballot with an expired key.
Here, the election officials script will be attempting to make use of 
expired keys.

I can see another requirement ...
6. At the record date for any election, voters public keys shall be 
checked for validity until at least the end of the voting period.

That will give election officials time to remind the electorate to fix
their keys.

[snip]  

> Your comments
> =============
> What are your thoughts?
> 
> -- 
> Best regards,
> Michał Górny
> 
> 

No showstopper comments from me.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

[-- Attachment #2: Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-project] Re: [RFC] vote.gentoo.org - a new voting frontend for Gentoo Elections

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3020 bytes --]

On Sat, 2019-07-27 at 11:40 +0100, Roy Bamford wrote:
> On 2019.07.27 07:21, Michał Górny wrote:
> > 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
> > =====
> > 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.
> > 
> 
> 5. Election Officials shall have a means to determine the voter turmout
> from time to time while the election is in progress.
> 
> Today, its carried out by the -infra contact and publicised in reminders
> to vote, IRC channel topics etc

Oh, I though those mails are directed to all listed officials
for an election and assumed this is nothing new to solve.  Sure, this is
entirely feasible.

> 
> [snip]
> 
> > 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.
> 
> How do we deal with expired public keys?

When token mails are generated GPG automatically verifies whether keys
are usable.  As a result, if someone has an expired key, the script
explicitly notes it and returns an error.

> 
> Devs get a warning at commit time before their key expires. Non devs
> will not be permitted (by gpg) to sign a ballot with an expired key.
> Here, the election officials script will be attempting to make use of 
> expired keys.
> 
> I can see another requirement ...
> 6. At the record date for any election, voters public keys shall be 
> checked for validity until at least the end of the voting period.
> 
> That will give election officials time to remind the electorate to fix
> their keys.

You can't sign votes using your key, as this kills the privacy
requirement.  Instead, we rely on secret token mails being encrypted
using voter's key.  Key only needs to be valid at encryption time,
as you can decrypt messages from the past ;-).

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-project] Re: [RFC] vote.gentoo.org - a new voting frontend for Gentoo Elections

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]

On Sat, Jul 27, 2019 at 11:40:12AM +0100, Roy Bamford wrote:
> On 2019.07.27 07:21, Michał Górny wrote:
> > 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
> > =====
> > 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.
> > 
> 
> 5. Election Officials shall have a means to determine the voter turmout
> from time to time while the election is in progress.

6. The voting system must produce a list of voters who cast a valid
ballot. This is required to see which voters did not cast a ballot in
the Foundation elections, and could thus be struck off the member list
for failure to participate.

This might be implemented via two separate identifiers from the secret
per your ideas.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

Re: [gentoo-project] Re: [RFC] vote.gentoo.org - a new voting frontend for Gentoo Elections

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3311 bytes --]

On Fri, 2019-08-09 at 05:49 +0000, Robin H. Johnson wrote:
> On Sat, Jul 27, 2019 at 11:40:12AM +0100, Roy Bamford wrote:
> > On 2019.07.27 07:21, Michał Górny wrote:
> > > 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
> > > =====
> > > 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.
> > > 
> > 
> > 5. Election Officials shall have a means to determine the voter turmout
> > from time to time while the election is in progress.
> 
> 6. The voting system must produce a list of voters who cast a valid
> ballot. This is required to see which voters did not cast a ballot in
> the Foundation elections, and could thus be struck off the member list
> for failure to participate.
> 
> This might be implemented via two separate identifiers from the secret
> per your ideas.

Do I understand correctly that you want:

1. one derived identifier to be used to cast the vote and stored without
association to developer,

2. another derived identifier to be used to confirm the vote, and stored
with association to developer?

I suppose this could work.  However, it would weaken the privacy
protection much.  Any active watcher (say, Infra or election official)
would be able to notice simultaneous appearance of the vote
and the voter entry.  Sure, they could also break the system by hacking
the scripts over or adding voters manually rather via the script
but the whole point is to limit privacy exposure to the minimum.

Furthermore, I believe the fact whether one has voted or not is also
a matter of privacy.  Expecting people to explicitly indicate this is
violating it, so it doesn't seem the correct solution to the problem
at hand.

Maybe Trustees should consider finding a better way of determining when
to retire inactive members?  The simplest solution that comes to my head
is finally requiring all Foundation members to be active developers, or
at least setting same rules for both groups (i.e. retiring Foundation
members when they stop making new contributions to Gentoo).  Given that
there are only a few Foundation members who are not devs, either way
shouldn't be a real issue.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]