Re: Reaffirm public voting
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: Amendment: Keep e-mail while allowing other options in addition [Re: GR: Hide Identities of Developers Casting a Particular Vote]
Le 26/02/2022 à 23:22, Don Armstrong a écrit : >> I plan to look at least at belenios is voting by email is no longer >> required. My plan is to run at least a small test to see if people >> like it or not. I could maybe also run a larger poll. But we'll see >> about how we pick a different system, or not, later. > > Looks interesting. I know (having hacked up devotee to make > pocket-devotee) that the plumbing around these systems is complicated; Should Belenios (of which I am upstream) be chosen, I think some adaptations (and plumbing) will be needed. In Debian, every voter has a GPG key... This could be leveraged to simplify things while retaining other security properties. In Belenios, the primary voting interface is web-based, but its design allows for other interfaces. For example, there exists a command-line tool to create ballots, that can be submitted by whatever means to an election board. There is also the notion of "trustee", a person who is in charge of keeping a share of the secret key used to decrypt ballots. The Secretary comes to mind, but ideally there should be several independent trustees (maybe the Technical Committee?). But maybe we should wait for the principle of secret ballots to be adopted before discussing implementation details... Cheers, -- Stéphane
Re: Call for vote - Diversity statement for the Debian Project
Le 16/05/2012 00:28, Kurt Roeckx a écrit : I'll start the vote during the weekend. But I need to think about the name of the option, I wasn't very happy with it when I wrote that. Has the issue mentioned in [1] been taken into account? [1] https://lists.debian.org/debian-devel/2012/04/msg00528.html Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb534c9.6090...@debian.org
Re: Q for all candidates: license and copyright requirements
Dmitrijs Ledkovs wrote: I you would like to guarantee to the users that unpacked debian source is DFSG we should hook into unpack (similar to DpkgSrc3.0 / quilt) and remove DFSG blobs at maintainers discretion for example by parsing debian/copyright. [...] This change will result in maintainers spending less time by recuding effort required for packaging software with non-DFSG-pristine-tarball. Debian developer time is precious and very limited and IMHO should be used as efficiently as possible. IMHO, writing a hook at unpack time to remove non-DFSG stuff and repackaging require the same effort. I would even say the former is more error-prone (in the sense that it can leave non-DFSG bits behind in some unexpected situation) and therefore requires more time. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4baa0b82.5050...@glondu.net
