Re: [gentoo-project] [pre-GLEP] Secrecy-respecting voting mechanism for Gentoo projects

[Michał Górny]

On Mon, 2021-08-30 at 05:23 +0000, Robin H. Johnson wrote:
> On Sat, Aug 28, 2021 at 12:30:15PM +0200, Michał Górny wrote:
> > Please review the following pre-GLEP.
> Please don't take the rest of my mail as a dismissal, but rather as
> considering how to protect Gentoo's voting system from any attack that I
> feel I might even remotely have the system privilege level to conduct.
>
> I absolutely do want improvements to Gentoo's voting process, like I
> said last year in mentioning mail-in ballot systems.
>
> >
> > ---
> > GLEP: 9999
> > Title: Secrecy-respecting voting mechanism for Gentoo projects
> > Author: Michał Górny <mgorny@g.o>
> > Type: Standards Track
> > Status: Draft
> > Version: 1
> > Created: 2021-08-27
> > Last-Modified: 2021-08-27
> > Post-History: 2021-08-27
> > Content-Type: text/x-rst
> Can you please reference all of your earlier proposals about changing
> the voting system, because this isn't the first time you've suggested
> it, and there have been prior suggestions by others as well.

Was there actually more than one?  I didn't link it (or search for it)
because it's literally the same proposal, just in GLEP form.

Unless you mean the "community vote verification" which I considered to
be out of the scope.  However, it's going to work the same with this
voting model.

>
> ...
> > The election process
> > --------------------
> >
> > Each election/referendum consists of the following steps:
> >
> > 1. A developer creates a new election/referendum.  During this step,
> >    the developer specifies whether the boundary dates for each election
> >    phase, the voter list and the (potential) candidates.
> >
> > 2. If the nomination phase is applicable, the system accepts nominations
> >    from the voters.  Each nominated candidate is mailed about
> >    the nomination, and given the explicit choice of accepting
> >    or declining it.  If the nomination is accepted, the candidate may
> >    also upload a manifesto.
> >
> > 3. When the voting phase beings, the system creates random identifiers
> >    for all voters.  Each identifier is encrypted using voter's PGP key
> >    and sent via email to the voter.  The voter-identifier mapping is
> >    discarded immediately to reduce the risk of it leaking.
> What if each voter generates their OWN identifier (using tooling), and
> includes it in an encrypted ballot, such that it later winds up in the
> master ballot, where they can verify it...

I'm sorry but you need to spell this out slower because everything's
just encrypted and I can't decrypt it ;-).

>
> >    If the nomination phase was enabled, the system also creates
> >    the final candidate list from nominees who accepted their nomination.
> >
> > 4. Voters submit their votes using their random identifiers.
> Can you expand on this step more?
>
> If I send a mail to the gentoo.org email system, it must by definition
> contain somewhere:
> - my email address as the sender
> - my identifier
>
> If there's no encryption on the return mail, both details are
> potentially available to anybody in infra, which is one of the parties
> we want to block.
>

Nobody's talking about "return mail".  In fact, the rationale section
suggests votes are submitted via HTTPS.  This way in the worst case
Infra can grab IP of the voter but again, they would also have to tamper
with the receiving script to get the vote along with it.

I suppose we could have people submit votes encrypted to the election
officials.  Then I think this will eliminate the problem because Infra
will have access to the IP addresses of voters but not votes,
and election officials will only receive the final ballot.

-- 
Best regards,
Michał Górny