Re: Reaffirm public voting

[Kurt Roeckx]

On Sat, Mar 05, 2022 at 06:30:35PM +0100, Thomas Goirand wrote:
> When considering a voting system, there are a few important things to
> consider [1]:
> 
> 1- vote-privacy: the fact that a particular voter voted in a particular way
> is not revealed to anyone.
> 2- Receipt-freeness: a voter does not gain any information (a receipt) which
> can be used to prove to a coercer that she voted in a certain way.
> 3- Coercion-resistance: a voter cannot cooperate with a coercer to prove to
> him that she voted in a certain way.
> 4- Individual verifiability: a voter can check that her own ballot is
> included in the election's bulletin board.
> 5- Universal verifiability: anyone can check that the election outcome
> corresponds to the ballots published on the bulletin board.
> 6- Eligibility verifiability: anyone can check that each vote in the
> election outcome was cast by a registered voter and there is at most one
> vote per voter.

This paper about belenios covers some of that:
https://hal.inria.fr/hal-02066930/document


Kurt

Re: Reaffirm public voting

[Timo Röhling]

* Russ Allbery  [2022-03-05 12:39]:

I'm not sure that I see this for DPL elections because we publish both the
list of votes and the list of voters.  If those two lists aren't the same
length, that's fairly trivially detectable.

You're right, I missed that when I looked at the election
results. In that case, the forger needs to map some voters who voted
identically to the same HMAC_SHA256_HEX value, which means you need
to find collisions on the HMAC keys such that

  H(uid1, K1) == H(uid2, K2)

I don't know how resistant HMAC-SHA256 is to this type of "chosen
key" attack.

Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Russ Allbery]

Timo Röhling  writes:
> * Thomas Goirand :

>> 2- Receipt-freeness: a voter does not gain any information (a receipt)
>> which can be used to prove to a coercer that she voted in a certain way.

>> 6- Eligibility verifiability: anyone can check that each vote in the
>> election outcome was cast by a registered voter and there is at most one
>> vote per voter.

> Property 2 is violated if the vote is confirmed in a signed email like
> the public votes (I can't say because I never participated in a DPL
> election yet).

It is.  Our current voting system makes no attempt at property 2.

> Property 6 is violated, because you can trivially add arbitrary
> ballots with random HMAC_SHA256_HEX values (unless the voter turnout
> is 100%, which seems rather unlikely).

I'm not sure that I see this for DPL elections because we publish both the
list of votes and the list of voters.  If those two lists aren't the same
length, that's fairly trivially detectable.

-- 
Russ Allbery (r...@debian.org)  

Re: Reaffirm public voting

[Timo Röhling]

* Thomas Goirand :

1- vote-privacy: the fact that a particular voter voted in a particular
way is not revealed to anyone.
2- Receipt-freeness: a voter does not gain any information (a receipt)
which can be used to prove to a coercer that she voted in a certain way.
3- Coercion-resistance: a voter cannot cooperate with a coercer to prove
to him that she voted in a certain way.
4- Individual verifiability: a voter can check that her own ballot is
included in the election's bulletin board.
5- Universal verifiability: anyone can check that the election outcome
corresponds to the ballots published on the bulletin board.
6- Eligibility verifiability: anyone can check that each vote in the
election outcome was cast by a registered voter and there is at most one
vote per voter.


* Russ Allbery :

I'm personally more interested in using something like Belenios than just
replicating the DPL election scheme mostly because I'm unsure that the DPL
election scheme has had sufficient security analysis and I'd prefer to see
us move onto the firmer footing of a voting system that's had a published
rigorous analysis of its properties and I'm not aware of one for our
current DPL election system.  (I would love to be corrected if one does
exist.)

That analysis is quickly done:

Property 1 holds contigent on the security of HMAC-SHA256
and discounting side channel attacks on the voting server itself.
[Technically, it's violated because the secretary can see all votes,
but I don't think that is a problem in our use-case.]

Property 2 is violated if the vote is confirmed in a
signed email like the public votes (I can't say because I never
participated in a DPL election yet).

Property 3 is violated because the HMAC key can be passed on.

Property 4 holds, as does property 5, because all ballots are
published with the corresponding HMAC_SHA256_HEX values.

Property 6 is violated, because you can trivially add arbitrary
ballots with random HMAC_SHA256_HEX values (unless the voter turnout
is 100%, which seems rather unlikely).

I'm also in favor of using a Belenios derivative, especially since
Stephane already agreed to help us adopt the system for Debian. We
can probably even reduce the complexity a bit because we can live
with a weakened form of property 1 (that is, the secretary may learn
the voting behavior of individual DDs).


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Thomas Goirand]

On 3/5/22 21:07, Holger Levsen wrote:

And I'd call this 'rushed' still. If someone promises foo without explaining
how foo should be achieved and then a vote is held to mandate foo, I'd call
this 'rushed'. Even if there has been talk about foo for a year, which btw,
by Debian standards, is not a long time.


I agree. With the current proposal, I would vote "further discussion".

Thomas

Re: Reaffirm public voting

[Holger Levsen]

On Sat, Mar 05, 2022 at 11:42:03AM -0800, Russ Allbery wrote:
> [...] Just
> > voting on "I want my vote to be secret" without having any information
> > about the other properties is IMO completely silly and looses the point.

exactly.

> Sam's GR intentionally leaves the details open to the Project Secretary to
> determine.  I understand why people might object to that and would prefer
> to require a GR for any change to the process.

Yes.

>  I just wouldn't
> characterize that as "rushed" (it's a deliberate choice, and hasn't been
> made in a hurry so far as I can tell), so wasn't sure if that was the
> objection here or if there was something else I was missing.

And I'd call this 'rushed' still. If someone promises foo without explaining
how foo should be achieved and then a vote is held to mandate foo, I'd call
this 'rushed'. Even if there has been talk about foo for a year, which btw,
by Debian standards, is not a long time.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

If a monkey hoarded more bananas than it could eat, while most of the other
monkeys starved, scientists would study that monkey to figure out what the
heck was wrong with it. When humans do it, we put them on the cover of Forbes.


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Russ Allbery]

Thomas Goirand  writes:

> When considering a voting system, there are a few important things to
> consider [1]:

> 1- vote-privacy: the fact that a particular voter voted in a particular
> way is not revealed to anyone.
> 2- Receipt-freeness: a voter does not gain any information (a receipt)
> which can be used to prove to a coercer that she voted in a certain way.
> 3- Coercion-resistance: a voter cannot cooperate with a coercer to prove
> to him that she voted in a certain way.
> 4- Individual verifiability: a voter can check that her own ballot is
> included in the election's bulletin board.
> 5- Universal verifiability: anyone can check that the election outcome
> corresponds to the ballots published on the bulletin board.
> 6- Eligibility verifiability: anyone can check that each vote in the
> election outcome was cast by a registered voter and there is at most one 
> vote per voter.

> If I understand well the problem, we can't have all of the above. That's
> technically not possible, with the current state of knowledge on earth. 
> I haven't read enough on the topic, but I believe that's the case. If
> anyone has read more and would like to explain, please do...

> The current proposal, if I understand well, is that we would like to
> enforce 1- and 3-. I'm somewhat ok with it, but I very much value 4-, 5-
> and 6- above 1-, 2- and 3-.

I believe the current system gives us 4, 5, and 6 only, and the proposed
initial implementation of using the same mechanism as DPL votes for all
GRs would give us 1 (partially), 4, 5, and 6.  In other words, I think
it's additive with respect to your list because you do not lose 5 or 6
(all the rankings and all of the voters are published and you can do the
math yourself; you just don't have the association between rankings and
people).  It's possible that we could gain more properties from Belenios
or some other voting system that makes better use of cryptographic
primitives.  The security tradeoff (which is not captured by your list) is
to rely more heavily on trust in the Project Secretary because 4 remains
possible but becomes more complex (you have to check your hash rather than
just scrolling through the list and finding your name and your vote).

Both of our current voting mechanisms are somewhat vulnerable to injection
of votes by the Project Secretary or someone with administrative access to
the voting system supposedly from people listed as Debian Developers but
who are inactive and did not actually vote.  The DPL election mechanism is
probably somewhat more so because people are less inclined to review the
list of voters when their votes aren't listed as well, but the difference
feels minor to me.  This is a challenging thing to defend against in
general.

In DPL elections, we get 1 only partially since the Project Secretary
still can, in theory, determine which voters voted a specific way (as can
anyone else with privileged access to the machine that receives and
verifies the votes).  This proposal would also only give us 1 partially.

I'm personally more interested in using something like Belenios than just
replicating the DPL election scheme mostly because I'm unsure that the DPL
election scheme has had sufficient security analysis and I'd prefer to see
us move onto the firmer footing of a voting system that's had a published
rigorous analysis of its properties and I'm not aware of one for our
current DPL election system.  (I would love to be corrected if one does
exist.)  But I think there's a bit of a chicken and egg problem with
experimenting with any other voting mechanism, and I'm not sure how we get
started.  Sam's GR is one way to get started that seems reasonable to me,
but I can see why people may disagree.

> I am unsure about what Holger has in mind, but for me, yes, I do want to
> know about the full details of implementation to make sure we have 4-, 
> 5- and 6-, which we currently have with a fully public voting system. Just
> voting on "I want my vote to be secret" without having any information
> about the other properties is IMO completely silly and looses the point.

Sam's GR intentionally leaves the details open to the Project Secretary to
determine.  I understand why people might object to that and would prefer
to require a GR for any change to the process.  I just wouldn't
characterize that as "rushed" (it's a deliberate choice, and hasn't been
made in a hurry so far as I can tell), so wasn't sure if that was the
objection here or if there was something else I was missing.

-- 
Russ Allbery (r...@debian.org)  

Re: Reaffirm public voting

[Thomas Goirand]

On 3/5/22 17:52, Russ Allbery wrote:

Holger Levsen  writes:


And then, early 2022 is not the time for rushed changes like this, which
is also why I explicitly want to see "keep the status quo" on the ballot,
and not only as "NOTA", but as a real option.


We've been talking about secret votes for about nine months now, so I'm
not sure "rushed" is the word that you're looking for.  Concretely, it's
leaving me unclear what would make the change feel not rushed to you.

I understand if you are opposed to secret voting in general, but this
feels like a different objection than general opposition to the idea.

Could you be a bit clearer about what would make a proposal not rushed
(whether or not you would then support it)?  Are you specifically asking
that we agree on the full details of implementation before passing a GR
allowing for it?  Or something else?


Hi Russ,

Thanks for raising the topic. It's a way more difficult one than many 
may think, so let's dive into it.


When considering a voting system, there are a few important things to 
consider [1]:


1- vote-privacy: the fact that a particular voter voted in a particular 
way is not revealed to anyone.
2- Receipt-freeness: a voter does not gain any information (a receipt) 
which can be used to prove to a coercer that she voted in a certain way.
3- Coercion-resistance: a voter cannot cooperate with a coercer to prove 
to him that she voted in a certain way.
4- Individual verifiability: a voter can check that her own ballot is 
included in the election's bulletin board.
5- Universal verifiability: anyone can check that the election outcome 
corresponds to the ballots published on the bulletin board.
6- Eligibility verifiability: anyone can check that each vote in the 
election outcome was cast by a registered voter and there is at most one 
vote per voter.


If I understand well the problem, we can't have all of the above. That's 
technically not possible, with the current state of knowledge on earth. 
I haven't read enough on the topic, but I believe that's the case. If 
anyone has read more and would like to explain, please do...


The current proposal, if I understand well, is that we would like to 
enforce 1- and 3-. I'm somewhat ok with it, but I very much value 4-, 5- 
and 6- above 1-, 2- and 3-.


I am unsure about what Holger has in mind, but for me, yes, I do want to 
know about the full details of implementation to make sure we have 4-, 
5- and 6-, which we currently have with a fully public voting system. 
Just voting on "I want my vote to be secret" without having any 
information about the other properties is IMO completely silly and 
looses the point.


Cheers,

Thomas Goirand (zigo)

[1] Taken from http://www.lsv.fr/Projects/anr-avote/RAPPORTS/deliv1-2.pdf

Re: Reaffirm public voting

[Russ Allbery]

Holger Levsen  writes:

> And then, early 2022 is not the time for rushed changes like this, which
> is also why I explicitly want to see "keep the status quo" on the ballot,
> and not only as "NOTA", but as a real option. 

We've been talking about secret votes for about nine months now, so I'm
not sure "rushed" is the word that you're looking for.  Concretely, it's
leaving me unclear what would make the change feel not rushed to you.

I understand if you are opposed to secret voting in general, but this
feels like a different objection than general opposition to the idea.

Could you be a bit clearer about what would make a proposal not rushed
(whether or not you would then support it)?  Are you specifically asking
that we agree on the full details of implementation before passing a GR
allowing for it?  Or something else?

-- 
Russ Allbery (r...@debian.org)  

Re: Reaffirm public voting

[Gunnar Wolf]

Stefano Rivera dijo [Fri, Mar 04, 2022 at 10:27:45PM +]:
> Hi Holger (2022.03.04_10:42:51_+)
> > And then, early 2022 is not the time for rushed changes like this, which
> > is also why I explicitly want to see "keep the status quo" on the ballot,
> > and not only as "NOTA", but as a real option. 
> 
> If we were to have such an option on the ballot, my understanding of
> constitution 4.2.4 is that we'd have both "keep the status quo" and
> "NOTA" as ballot options.

It will make sense if they are ranked almost-equally then :-) Although
it is not impossible they will not, which might read as "we are happy
/ unhappy about this particular GR's background" or something like
that.

Re: Reaffirm public voting

[Sven Bartscher]

I sponsor the option below.

Am 04.03.22 um 11:42 schrieb Holger Levsen:

Reaffirm public voting
==

Since we can either have secret and intransparent voting, or we can have
open and transparent voting, the project resolves to leave our voting
system as it is.

Rationale:

The GR proposal for secret voting is silent on implenentation details,
probably because secret and transparent voting is, well, impossible to
achieve fully, so this GR is bound to a similar fate as the 'publish
debian-private' vote, which was voted for and then was never implemented.

A voting system which is transparent only to some, is undemocratic and
will lead to few people in the know, which is diagonal to Debians goals
of openness and transparency.

And then, early 2022 is not the time for rushed changes like this, which
is also why I explicitly want to see "keep the status quo" on the ballot,
and not only as "NOTA", but as a real option.

I'm seeking sponsors for this amendment to the current GR.




OpenPGP_signature
Description: OpenPGP digital signature

Re: Reaffirm public voting

[Stefano Rivera]

Hi Holger (2022.03.04_10:42:51_+)
> And then, early 2022 is not the time for rushed changes like this, which
> is also why I explicitly want to see "keep the status quo" on the ballot,
> and not only as "NOTA", but as a real option. 

If we were to have such an option on the ballot, my understanding of
constitution 4.2.4 is that we'd have both "keep the status quo" and
"NOTA" as ballot options.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: Reaffirm public voting

[Bill Allombert]

On Fri, Mar 04, 2022 at 04:24:46PM +0100, Stéphane Glondu wrote:
> Hello,
> 
> Le 04/03/2022 à 11:42, Holger Levsen a écrit :
> > The GR proposal for secret voting is silent on implenentation details,
> > probably because secret and transparent voting is, well, impossible to
> > achieve fully, [...]
> 
> It is possible to achieve some reasonable level of secrecy and
> transparency (and verifiability)... it is an active research topic per
> se. Belenios came out of this research, devotee-ng could also benefit
> from this research.
> 
> Disclaimer: I am upstream of Belenios in my dayjob.

I have voted several time using Belenios. This is probably the most
advanced free software voting solution. This has been useful to lots
of organisation during the lockdown.

However I feel this GR is putting the cart before the horses.
Before voting for or against a new voting system, we need to experiment
with them and see how they can be made to fit Debian. The secrecy used
for DPL elections is too weak if the purpose is to protect against
contentious GR.

That is why my own ballot proposal just say to keep the vote as is for
the time being and to discourage non-technical contentious GR.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Reaffirm public voting

[Bill Allombert]

On Fri, Mar 04, 2022 at 04:24:46PM +0100, Stéphane Glondu wrote:
> > A voting system which is transparent only to some, is undemocratic and
> > will lead to few people in the know, which is diagonal to Debians goals
> > of openness and transparency.
> 
> I'm not sure what you mean here. From some point of view, TLS is also
> transparent "only to some", since very few people understand the
> mathematics behind the crypto involved there. Yet, we don't promote
> unsecured communications where a TLS-secured variant exists.

TLS is not a voting system, so it does not need to have the same
property to be useful.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Reaffirm public voting

[Gunnar Wolf]

Jean-Philippe MENGUAL dijo [Fri, Mar 04, 2022 at 01:08:33PM +0100]:
> Hi,
> 
> I think we can establish a limitation between "secret" and "wiser
> secret". I can understand that making vote transparent and secret is
> likely not possible. And I am not sure that it is the purpose. The
> purpose is not to see displayed on a public website one name related
> to a GR and a vote.

An idea just floated to me :-) The reason our GRs are called General
Resolutions and not, ahem, "votes" (except when we talk about them
informally or want to write in fewer characters) is IMO because Debian
works as a collective, where we held assemblies, and collectively
discuss, propose and choose among options.

Assemblies are often open (in real-world gatherings). People
argue. When it comes to voting, you know what to expect about most of
the people (those you know best, and those that did the arguing).

Votes come from electoral systems, from larger constituencies. The
stakes are different, yes, but the _participation style_ is also
different. And I think we should remain closer to an assembly than to
an electoral system.

Yes, Debian has grown a lot since our Constitution was
drafted. However, I joined in 2003, approximately where the amount of
DDs stabilized; we have been ~800-1100 people since then. The model
has worked decently for the past twenty years; we had two cases where
private voting could have allowed people to express their opinions
without fear of hate-mail, retaliation or somesuch (the FSF and the
systemd votes, both with a strong political rather than technical
component, even though systemd _is_ technical).

> In other words, while I dont think someone will do a detailed
> investigation to know who voted what (most people just will not want
> to spend energy for this), anyone, including with malicious purpose,
> can visit a web page to see what I voted and do harasment
> then.
>
> While I accept not to be in a full secret, as I am not afraid with
> persons who can do harasment to spend so energy to find this info in
> a deep server or via a hash or whatever, I am worry bif any mad guy
> can see what I voted about a GR as I know the person will not
> hesitate to attack me. Again, we have an example of this, of high
> flame, during RMS GR, and while the most radical persons probably
> did not want to do deep investigations about voters, I think they
> were ready to visit a page and go after voters. I dont know if it
> happent effectively, but given how the vote happent with trials to
> disturb after the campaign time, it is possible.

Voting is a single-time action. If somebody is willing to harass
people with strong viewpoints... It's much easier IMO to go through
the mailing list archives and find who is more active, and not only
find their vote, but their full argumentation. Votes for the most part
_cannot_ really be private for the people most involved in a decision
if we are consistent with our argumentation.

Of course, you argue just the other way, that people will attack us
based on the vote tally. But we are talking -and you expressly
recognize it- about what _could_ happen, not about what _has_
happened.

> The last thing which may justify a such ballot is the idea that "if you dont
> want to see your name related to a vote, just dont vote, you dont have to do
> it, you are free". this may be acceptable for political GRs, but more a
> problem for ambiguous situations.
> 
> Hence the importance to make secret possible at least, if not general and
> mandatory.

I agree votes should be "secretizable". But I really hope they don't
become mandatorily secret.


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Gunnar Wolf]

I know Holger's and Bill's proposed options are prone to change and
merge, but I'll say it now and probably reaffirm it later:

I second this option.

While I prefer Harlan's, it has failed to gain sponsors, and I don't
want to risk the complete loss of public votes in Debian. I think the
status quo (all votes are public except for DPL votes) is much better
than the other proposals.

Holger Levsen dijo [Fri, Mar 04, 2022 at 10:42:51AM +]:
> Reaffirm public voting
> ==
> 
> Since we can either have secret and intransparent voting, or we can have
> open and transparent voting, the project resolves to leave our voting
> system as it is.
> 
> Rationale:
> 
> The GR proposal for secret voting is silent on implenentation details,
> probably because secret and transparent voting is, well, impossible to
> achieve fully, so this GR is bound to a similar fate as the 'publish 
> debian-private' vote, which was voted for and then was never implemented.
> 
> A voting system which is transparent only to some, is undemocratic and
> will lead to few people in the know, which is diagonal to Debians goals
> of openness and transparency.
> 
> And then, early 2022 is not the time for rushed changes like this, which
> is also why I explicitly want to see "keep the status quo" on the ballot,
> and not only as "NOTA", but as a real option. 
> 
> I'm seeking sponsors for this amendment to the current GR.



-- 



signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Stéphane Glondu]

Hello,

Le 04/03/2022 à 11:42, Holger Levsen a écrit :
> The GR proposal for secret voting is silent on implenentation details,
> probably because secret and transparent voting is, well, impossible to
> achieve fully, [...]

It is possible to achieve some reasonable level of secrecy and
transparency (and verifiability)... it is an active research topic per
se. Belenios came out of this research, devotee-ng could also benefit
from this research.

Disclaimer: I am upstream of Belenios in my dayjob.

> A voting system which is transparent only to some, is undemocratic and
> will lead to few people in the know, which is diagonal to Debians goals
> of openness and transparency.

I'm not sure what you mean here. From some point of view, TLS is also
transparent "only to some", since very few people understand the
mathematics behind the crypto involved there. Yet, we don't promote
unsecured communications where a TLS-secured variant exists.


Cheers,

-- 
Stéphane

Re: Reaffirm public voting

[Christian Kastner]

On 2022-03-04 13:15, Holger Levsen wrote:
> On Fri, Mar 04, 2022 at 12:14:56PM +0100, Pierre-Elliott Bécue wrote:
>> Is init systems GR a political GR?
> 
> yet there are people maintaining systemd and sysv in public.

How is that relevant?

I'm neither a systemd nor sysv maintainer, but considering the grief
that some other non-maintainers got just for expressing that they favor
systemd, I'd rather not vote at all if it's not secret.

You of all people should know this. You've spoken out against exactly
this kind of grief. You asked for a shield back then, and that's what
the people in favor of voting secrecy are asking for now.

Best,
Christian

Re: Reaffirm public voting

[Santiago Ruano Rincón]

El 04/03/22 a las 12:03, Mattia Rizzolo escribió:
> On Fri, Mar 04, 2022 at 10:42:51AM +, Holger Levsen wrote:
> > Reaffirm public voting
> > ==
> > 
> > Since we can either have secret and intransparent voting, or we can have
> > open and transparent voting, the project resolves to leave our voting
> > system as it is.
> > 
> > Rationale:
> > 
> > The GR proposal for secret voting is silent on implenentation details,
> > probably because secret and transparent voting is, well, impossible to
> > achieve fully, so this GR is bound to a similar fate as the 'publish 
> > debian-private' vote, which was voted for and then was never implemented.
> > 
> > A voting system which is transparent only to some, is undemocratic and
> > will lead to few people in the know, which is diagonal to Debians goals
> > of openness and transparency.
> > 
> > And then, early 2022 is not the time for rushed changes like this, which
> > is also why I explicitly want to see "keep the status quo" on the ballot,
> > and not only as "NOTA", but as a real option. 
> > 
> > I'm seeking sponsors for this amendment to the current GR.
> 
> 
> Assuming you meant this as "this ballot" instead of "this amendment"
> (following the new GR flow), I sponsor this.
> 
> 

I sponsor this ballot.

> If I were to add my thoughts: political GRs don't belong in Debian,
> please take them elsewhere.  For non-political votes there is no use
> for private voting.

I think technical is political. Giving freedom to software users is
political.
And I'd rather say we should avoid GRs involving individuals.

Cheeers,

 -- S


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Mathias Behrle]

* Philip Hands: " Re: Reaffirm public voting" (Fri, 04 Mar 2022 13:23:32 +0100):

> Holger Levsen  writes:
> 
> > On Fri, Mar 04, 2022 at 12:03:22PM +0100, Mattia Rizzolo wrote:  
> >> On Fri, Mar 04, 2022 at 10:42:51AM +, Holger Levsen wrote:  
> >> > Reaffirm public voting
> >> > ==
> >> > 
> >> > Since we can either have secret and intransparent voting, or we can have
> >> > open and transparent voting, the project resolves to leave our voting
> >> > system as it is.
> >> > 
> >> > Rationale:
> >> > 
> >> > The GR proposal for secret voting is silent on implenentation details,
> >> > probably because secret and transparent voting is, well, impossible to
> >> > achieve fully, so this GR is bound to a similar fate as the 'publish 
> >> > debian-private' vote, which was voted for and then was never implemented.
> >> > 
> >> > A voting system which is transparent only to some, is undemocratic and
> >> > will lead to few people in the know, which is diagonal to Debians goals
> >> > of openness and transparency.
> >> > 
> >> > And then, early 2022 is not the time for rushed changes like this, which
> >> > is also why I explicitly want to see "keep the status quo" on the ballot,
> >> > and not only as "NOTA", but as a real option. 
> >> > 
> >> > I'm seeking sponsors for this amendment to the current GR.  
> >> Assuming you meant this as "this ballot" instead of "this amendment"
> >> (following the new GR flow), I sponsor this.  
> >
> > yes, that's what I ment, thanks. Do I need to resent my mail now with this
> > change? :)  
> 
> I sponsor this.
> 
> While I may not end up voting for it as my first option, I think it
> deserves to be an explicit option, because I can imagine that no
> super-majority emerges in this vote, and if that happens then we will be
> able to draw rather different conclusions about the project consensus
> depending upon whether this option comes above or below NotA (and by how
> much).
> 
> Cheers, Phil.

I sponsor this as well.


-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6


pgpIZjIS7Pa98.pgp
Description: Digitale Signatur von OpenPGP

Re: Reaffirm public voting

[Philip Hands]

Holger Levsen  writes:

> On Fri, Mar 04, 2022 at 12:03:22PM +0100, Mattia Rizzolo wrote:
>> On Fri, Mar 04, 2022 at 10:42:51AM +, Holger Levsen wrote:
>> > Reaffirm public voting
>> > ==
>> > 
>> > Since we can either have secret and intransparent voting, or we can have
>> > open and transparent voting, the project resolves to leave our voting
>> > system as it is.
>> > 
>> > Rationale:
>> > 
>> > The GR proposal for secret voting is silent on implenentation details,
>> > probably because secret and transparent voting is, well, impossible to
>> > achieve fully, so this GR is bound to a similar fate as the 'publish 
>> > debian-private' vote, which was voted for and then was never implemented.
>> > 
>> > A voting system which is transparent only to some, is undemocratic and
>> > will lead to few people in the know, which is diagonal to Debians goals
>> > of openness and transparency.
>> > 
>> > And then, early 2022 is not the time for rushed changes like this, which
>> > is also why I explicitly want to see "keep the status quo" on the ballot,
>> > and not only as "NOTA", but as a real option. 
>> > 
>> > I'm seeking sponsors for this amendment to the current GR.
>> Assuming you meant this as "this ballot" instead of "this amendment"
>> (following the new GR flow), I sponsor this.
>
> yes, that's what I ment, thanks. Do I need to resent my mail now with this
> change? :)

I sponsor this.

While I may not end up voting for it as my first option, I think it
deserves to be an explicit option, because I can imagine that no
super-majority emerges in this vote, and if that happens then we will be
able to draw rather different conclusions about the project consensus
depending upon whether this option comes above or below NotA (and by how
much).

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Mattia Rizzolo]

On Fri, Mar 04, 2022 at 06:41:54AM -0500, Tiago Bortoletto Vaz wrote:
> On Fri, Mar 04, 2022 at 12:14:56PM +0100, Pierre-Elliott Bécue wrote:
> > I'm pretty sure some gave double thoughts before voting because of the
> > shitstorm/flame that had happened before the vote.
> 
> This has been argued already it seems.

Yes, it's already been discussed, I doubt it needs to be discussed even
more here, and I surely don't want to.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Holger Levsen]

On Fri, Mar 04, 2022 at 12:14:56PM +0100, Pierre-Elliott Bécue wrote:
> Is init systems GR a political GR?

yet there are people maintaining systemd and sysv in public.
so what's next, secret maintainers?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

This is a pandemic, not a war. People keep dying even if you surrender.


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Jean-Philippe MENGUAL]

Hi,

I think we can establish a limitation between "secret" and "wiser 
secret". I can understand that making vote transparent and secret is 
likely not possible. And I am not sure that it is the purpose. The 
purpose is not to see displayed on a public website one name related to 
a GR and a vote. In other words, while I dont think someone will do a 
detailed investigation to know who voted what (most people just will not 
want to spend energy for this), anyone, including with malicious 
purpose, can visit a web page to see what I voted and do harasment then. 
While I accept not to be in a full secret, as I am not afraid with 
persons who can do harasment to spend so energy to find this info in a 
deep server or via a hash or whatever, I am worry bif any mad guy can 
see what I voted about a GR as I know the person will not hesitate to 
attack me. Again, we have an example of this, of high flame, during RMS 
GR, and while the most radical persons probably did not want to do deep 
investigations about voters, I think they were ready to visit a page and 
go after voters. I dont know if it happent effectively, but given how 
the vote happent with trials to disturb after the campaign time, it is 
possible.


The last thing which may justify a such ballot is the idea that "if you 
dont want to see your name related to a vote, just dont vote, you dont 
have to do it, you are free". this may be acceptable for political GRs, 
but more a problem for ambiguous situations.


Hence the importance to make secret possible at least, if not general 
and mandatory.


Jean-Philippe MENGUAL
Debian Developer non uploading
Community team member
Accessibility team member
debian-l10n-french team member
President of Debian France non-profit organization

Le 04/03/2022 à 12:41, Tiago Bortoletto Vaz a écrit :

On Fri, Mar 04, 2022 at 12:14:56PM +0100, Pierre-Elliott Bécue wrote:


Mattia Rizzolo  wrote on 04/03/2022 at 12:03:22+0100:


[[PGP Signed Part:Signature made by expired key 0816B9E18C762BAD Mattia Rizzolo 
  ]]
On Fri, Mar 04, 2022 at 10:42:51AM +, Holger Levsen wrote:

Reaffirm public voting
==

Since we can either have secret and intransparent voting, or we can have
open and transparent voting, the project resolves to leave our voting
system as it is.

Rationale:

The GR proposal for secret voting is silent on implenentation details,
probably because secret and transparent voting is, well, impossible to
achieve fully, so this GR is bound to a similar fate as the 'publish
debian-private' vote, which was voted for and then was never implemented.

A voting system which is transparent only to some, is undemocratic and
will lead to few people in the know, which is diagonal to Debians goals
of openness and transparency.

And then, early 2022 is not the time for rushed changes like this, which
is also why I explicitly want to see "keep the status quo" on the ballot,
and not only as "NOTA", but as a real option.

I'm seeking sponsors for this amendment to the current GR.



Assuming you meant this as "this ballot" instead of "this amendment"
(following the new GR flow), I sponsor this.



If I were to add my thoughts: political GRs don't belong in Debian,
please take them elsewhere.  For non-political votes there is no use
for private voting.


Is init systems GR a political GR?

I'm pretty sure some gave double thoughts before voting because of the
shitstorm/flame that had happened before the vote.


Not only that, but also conflicts of interest involving an employer may
have influence over a non-political vote (or the willingness to vote).
This has been argued already it seems.

Bests,

--
Tiago

Re: Reaffirm public voting

[Tiago Bortoletto Vaz]

On Fri, Mar 04, 2022 at 12:14:56PM +0100, Pierre-Elliott Bécue wrote:
> 
> Mattia Rizzolo  wrote on 04/03/2022 at 12:03:22+0100:
> 
> > [[PGP Signed Part:Signature made by expired key 0816B9E18C762BAD Mattia 
> > Rizzolo   ]]
> > On Fri, Mar 04, 2022 at 10:42:51AM +, Holger Levsen wrote:
> >> Reaffirm public voting
> >> ==
> >> 
> >> Since we can either have secret and intransparent voting, or we can have
> >> open and transparent voting, the project resolves to leave our voting
> >> system as it is.
> >> 
> >> Rationale:
> >> 
> >> The GR proposal for secret voting is silent on implenentation details,
> >> probably because secret and transparent voting is, well, impossible to
> >> achieve fully, so this GR is bound to a similar fate as the 'publish 
> >> debian-private' vote, which was voted for and then was never implemented.
> >> 
> >> A voting system which is transparent only to some, is undemocratic and
> >> will lead to few people in the know, which is diagonal to Debians goals
> >> of openness and transparency.
> >> 
> >> And then, early 2022 is not the time for rushed changes like this, which
> >> is also why I explicitly want to see "keep the status quo" on the ballot,
> >> and not only as "NOTA", but as a real option. 
> >> 
> >> I'm seeking sponsors for this amendment to the current GR.
> >
> >
> > Assuming you meant this as "this ballot" instead of "this amendment"
> > (following the new GR flow), I sponsor this.
> >
> >
> >
> > If I were to add my thoughts: political GRs don't belong in Debian,
> > please take them elsewhere.  For non-political votes there is no use
> > for private voting.
> 
> Is init systems GR a political GR?
> 
> I'm pretty sure some gave double thoughts before voting because of the
> shitstorm/flame that had happened before the vote.

Not only that, but also conflicts of interest involving an employer may
have influence over a non-political vote (or the willingness to vote).
This has been argued already it seems.

Bests,

--
Tiago

Re: Reaffirm public voting

[Pierre-Elliott Bécue]

Mattia Rizzolo  wrote on 04/03/2022 at 12:03:22+0100:

> [[PGP Signed Part:Signature made by expired key 0816B9E18C762BAD Mattia 
> Rizzolo   ]]
> On Fri, Mar 04, 2022 at 10:42:51AM +, Holger Levsen wrote:
>> Reaffirm public voting
>> ==
>> 
>> Since we can either have secret and intransparent voting, or we can have
>> open and transparent voting, the project resolves to leave our voting
>> system as it is.
>> 
>> Rationale:
>> 
>> The GR proposal for secret voting is silent on implenentation details,
>> probably because secret and transparent voting is, well, impossible to
>> achieve fully, so this GR is bound to a similar fate as the 'publish 
>> debian-private' vote, which was voted for and then was never implemented.
>> 
>> A voting system which is transparent only to some, is undemocratic and
>> will lead to few people in the know, which is diagonal to Debians goals
>> of openness and transparency.
>> 
>> And then, early 2022 is not the time for rushed changes like this, which
>> is also why I explicitly want to see "keep the status quo" on the ballot,
>> and not only as "NOTA", but as a real option. 
>> 
>> I'm seeking sponsors for this amendment to the current GR.
>
>
> Assuming you meant this as "this ballot" instead of "this amendment"
> (following the new GR flow), I sponsor this.
>
>
>
> If I were to add my thoughts: political GRs don't belong in Debian,
> please take them elsewhere.  For non-political votes there is no use
> for private voting.

Is init systems GR a political GR?

I'm pretty sure some gave double thoughts before voting because of the
shitstorm/flame that had happened before the vote.
-- 
PEB


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Holger Levsen]

On Fri, Mar 04, 2022 at 12:03:22PM +0100, Mattia Rizzolo wrote:
> On Fri, Mar 04, 2022 at 10:42:51AM +, Holger Levsen wrote:
> > Reaffirm public voting
> > ==
> > 
> > Since we can either have secret and intransparent voting, or we can have
> > open and transparent voting, the project resolves to leave our voting
> > system as it is.
> > 
> > Rationale:
> > 
> > The GR proposal for secret voting is silent on implenentation details,
> > probably because secret and transparent voting is, well, impossible to
> > achieve fully, so this GR is bound to a similar fate as the 'publish 
> > debian-private' vote, which was voted for and then was never implemented.
> > 
> > A voting system which is transparent only to some, is undemocratic and
> > will lead to few people in the know, which is diagonal to Debians goals
> > of openness and transparency.
> > 
> > And then, early 2022 is not the time for rushed changes like this, which
> > is also why I explicitly want to see "keep the status quo" on the ballot,
> > and not only as "NOTA", but as a real option. 
> > 
> > I'm seeking sponsors for this amendment to the current GR.
> Assuming you meant this as "this ballot" instead of "this amendment"
> (following the new GR flow), I sponsor this.

yes, that's what I ment, thanks. Do I need to resent my mail now with this
change? :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

We live in a world where teenagers get more and more desperate trying to
convince adults to behave like grown ups.


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Mattia Rizzolo]

On Fri, Mar 04, 2022 at 10:42:51AM +, Holger Levsen wrote:
> Reaffirm public voting
> ==
> 
> Since we can either have secret and intransparent voting, or we can have
> open and transparent voting, the project resolves to leave our voting
> system as it is.
> 
> Rationale:
> 
> The GR proposal for secret voting is silent on implenentation details,
> probably because secret and transparent voting is, well, impossible to
> achieve fully, so this GR is bound to a similar fate as the 'publish 
> debian-private' vote, which was voted for and then was never implemented.
> 
> A voting system which is transparent only to some, is undemocratic and
> will lead to few people in the know, which is diagonal to Debians goals
> of openness and transparency.
> 
> And then, early 2022 is not the time for rushed changes like this, which
> is also why I explicitly want to see "keep the status quo" on the ballot,
> and not only as "NOTA", but as a real option. 
> 
> I'm seeking sponsors for this amendment to the current GR.


Assuming you meant this as "this ballot" instead of "this amendment"
(following the new GR flow), I sponsor this.



If I were to add my thoughts: political GRs don't belong in Debian,
please take them elsewhere.  For non-political votes there is no use
for private voting.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Reaffirm public voting

[Holger Levsen]

Reaffirm public voting
==

Since we can either have secret and intransparent voting, or we can have
open and transparent voting, the project resolves to leave our voting
system as it is.

Rationale:

The GR proposal for secret voting is silent on implenentation details,
probably because secret and transparent voting is, well, impossible to
achieve fully, so this GR is bound to a similar fate as the 'publish 
debian-private' vote, which was voted for and then was never implemented.

A voting system which is transparent only to some, is undemocratic and
will lead to few people in the know, which is diagonal to Debians goals
of openness and transparency.

And then, early 2022 is not the time for rushed changes like this, which
is also why I explicitly want to see "keep the status quo" on the ballot,
and not only as "NOTA", but as a real option. 

I'm seeking sponsors for this amendment to the current GR.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The vision of self driving cars is nothing compared to the vision of no cars
at all.


signature.asc
Description: PGP signature