Bug#990228: [Pkg-openssl-devel] Bug#990228: Bug#990228: Bug#990228: Bug#990228: openssl: breaks ssl-cert installation: 8022CB35777F0000:error:1200007A:random number generator:RAND_write_file:Not a reg
reassign 990228 ssl-cert severity 990228 normal thanks So I think there is no bug in OpenSSL and the additional check being done in 3.0 makes sense. So I'm reassigning this to ssl-cert. Kurt
Bug#990228: [Pkg-openssl-devel] Bug#990228: Bug#990228: Bug#990228: openssl: breaks ssl-cert installation: 8022CB35777F0000:error:1200007A:random number generator:RAND_write_file:Not a regular file:..
On Thu, Jun 24, 2021 at 12:20:45AM +0200, Kurt Roeckx wrote: > > From the manpage: >Random State Options > >Prior to OpenSSL 1.1.1, it was common for applications to store >information about the state of the random-number generator in a >file that was loaded at startup and rewritten upon exit. On >modern operating systems, this is generally no longer necessary >as OpenSSL will seed itself from a trusted entropy source >provided by the operating system. These flags are still supported >for special platforms or circumstances that might require them. > > Reading something from /dev/urandom and then writing it back to it > doesn't make sense to me. > > The expected behaviour is that you can read back the file you've > written, which clearly is not what /dev/urandom does. > > If you need to save the file, you actually want a file that's still > there after a reboot. > > I would recommend to just remove the option from the config file. > > That being said, the manpage seems to indicate that a non-regular > file should also be supported for reading, but it's unclear if > that also applies to writing, and would assume it is, so this also > looks like a bug in OpenSSL. The reason for the check that it's not a regular file is that you actually want to be able to delete it's content, so that you're sure it's not reused. But OpenSSL APIs for actually properly implementing it aren't that great to start with. Kurt
Bug#990228: [Pkg-openssl-devel] Bug#990228: Bug#990228: Bug#990228: openssl: breaks ssl-cert installation: 8022CB35777F0000:error:1200007A:random number generator:RAND_write_file:Not a regular file:..
On Thu, Jun 24, 2021 at 12:20:45AM +0200, Kurt Roeckx wrote: > > From the manpage: >Random State Options > >Prior to OpenSSL 1.1.1, it was common for applications to store >information about the state of the random-number generator in a >file that was loaded at startup and rewritten upon exit. On >modern operating systems, this is generally no longer necessary >as OpenSSL will seed itself from a trusted entropy source >provided by the operating system. These flags are still supported >for special platforms or circumstances that might require them. > > Reading something from /dev/urandom and then writing it back to it > doesn't make sense to me. > > The expected behaviour is that you can read back the file you've > written, which clearly is not what /dev/urandom does. > > If you need to save the file, you actually want a file that's still > there after a reboot. > > I would recommend to just remove the option from the config file. > > That being said, the manpage seems to indicate that a non-regular > file should also be supported for reading, but it's unclear if > that also applies to writing, and would assume it is, so this also > looks like a bug in OpenSSL. The reason for the check that it's not a regular file is that you actually want to be able to delete it's content, so that you're sure it's not reused. But OpenSSL APIs for actually properly implementing it aren't that great to start with. Kurt
Bug#990228: [Pkg-openssl-devel] Bug#990228: Bug#990228: openssl: breaks ssl-cert installation: 8022CB35777F0000:error:1200007A:random number generator:RAND_write_file:Not a regular file:../crypto/rand
On Wed, Jun 23, 2021 at 09:05:03PM +0200, Sebastian Andrzej Siewior wrote: > On 2021-06-23 14:46:37 [+0200], Andreas Beckmann wrote: > > Writing new private key to '/etc/ssl/private/ssl-cert-snakeoil.key' > > - > > Warning: No -copy_extensions given; ignoring any extensions in the request > > Cannot write random bytes: > > 8022CB35777F:error:127A:random number > > generator:RAND_write_file:Not a regular > > file:../crypto/rand/randfile.c:190:Filename=/dev/urandom > … > > Hmm, well, yes, /dev/urandom is not a regular file. It's a character device > > node. > > This is from > -config $file > -> > RANDFILE= /dev/urandom > > The reject of file nodes is new in the 3.0.0 release. > In the past openssl used to have its .rnd where it keept track of a > random state. So it read the RANDFILE to seed and wrote it back to avoid > having the state on the next invocation. > This is gone since 1.1.0 (I think) and openssl uses getrandom() to > initialize its random generator. It is no longer needed to specify > /dev/urandom as RANDFILE to seed it initially. > In this case it will read urandom and use additionally getrandom() and > both provide pseude-random data from exactly the same pool. And then > after the operation, openssl will write it back… > > I would argue to remove RANDFILE from the template. On the other hand > there is nothing wrong with writting it back to a device node file. > > Kurt? >From the manpage: Random State Options Prior to OpenSSL 1.1.1, it was common for applications to store information about the state of the random-number generator in a file that was loaded at startup and rewritten upon exit. On modern operating systems, this is generally no longer necessary as OpenSSL will seed itself from a trusted entropy source provided by the operating system. These flags are still supported for special platforms or circumstances that might require them. Reading something from /dev/urandom and then writing it back to it doesn't make sense to me. The expected behaviour is that you can read back the file you've written, which clearly is not what /dev/urandom does. If you need to save the file, you actually want a file that's still there after a reboot. I would recommend to just remove the option from the config file. That being said, the manpage seems to indicate that a non-regular file should also be supported for reading, but it's unclear if that also applies to writing, and would assume it is, so this also looks like a bug in OpenSSL. Kurt
Bug#990228: [Pkg-openssl-devel] Bug#990228: Bug#990228: openssl: breaks ssl-cert installation: 8022CB35777F0000:error:1200007A:random number generator:RAND_write_file:Not a regular file:../crypto/rand
On Wed, Jun 23, 2021 at 09:05:03PM +0200, Sebastian Andrzej Siewior wrote: > On 2021-06-23 14:46:37 [+0200], Andreas Beckmann wrote: > > Writing new private key to '/etc/ssl/private/ssl-cert-snakeoil.key' > > - > > Warning: No -copy_extensions given; ignoring any extensions in the request > > Cannot write random bytes: > > 8022CB35777F:error:127A:random number > > generator:RAND_write_file:Not a regular > > file:../crypto/rand/randfile.c:190:Filename=/dev/urandom > … > > Hmm, well, yes, /dev/urandom is not a regular file. It's a character device > > node. > > This is from > -config $file > -> > RANDFILE= /dev/urandom > > The reject of file nodes is new in the 3.0.0 release. > In the past openssl used to have its .rnd where it keept track of a > random state. So it read the RANDFILE to seed and wrote it back to avoid > having the state on the next invocation. > This is gone since 1.1.0 (I think) and openssl uses getrandom() to > initialize its random generator. It is no longer needed to specify > /dev/urandom as RANDFILE to seed it initially. > In this case it will read urandom and use additionally getrandom() and > both provide pseude-random data from exactly the same pool. And then > after the operation, openssl will write it back… > > I would argue to remove RANDFILE from the template. On the other hand > there is nothing wrong with writting it back to a device node file. > > Kurt? >From the manpage: Random State Options Prior to OpenSSL 1.1.1, it was common for applications to store information about the state of the random-number generator in a file that was loaded at startup and rewritten upon exit. On modern operating systems, this is generally no longer necessary as OpenSSL will seed itself from a trusted entropy source provided by the operating system. These flags are still supported for special platforms or circumstances that might require them. Reading something from /dev/urandom and then writing it back to it doesn't make sense to me. The expected behaviour is that you can read back the file you've written, which clearly is not what /dev/urandom does. If you need to save the file, you actually want a file that's still there after a reboot. I would recommend to just remove the option from the config file. That being said, the manpage seems to indicate that a non-regular file should also be supported for reading, but it's unclear if that also applies to writing, and would assume it is, so this also looks like a bug in OpenSSL. Kurt
Re: VOTE: 3.0 beta1 readiness
On Tue, Jun 15, 2021 at 10:53:03AM +0100, Matt Caswell wrote: > topic: OTC approve the release of 3.0 beta1 on Thursday 17th June on the > basis >that: 1) all current approved PRs with the beta1 milestone are merged >2) issues #15755 and #15756 are resolved 3) We accept that VMS does > not >currently pass tests but expect it to do so before 3.0 final (issue >#15757) 0 Kurt
Re: OTC VOTE: Reject PR#14759
On Tue, Apr 20, 2021 at 01:23:56PM +0300, Nicola Tuveri wrote: > Following up on > https://www.mail-archive.com/openssl-project@openssl.org/msg02407.html we > had a discussion on this during last week OTC meeting, and opened a vote > limited exclusively to the matter of rejecting PR#14759. > > We lost the record of the votes collected during the call, so opening it > officially today with a clean slate. > > > > topic: Reject PR#14759 +1 Kurt
Re: OTC VOTE: Set PR 13817 milestone to Post 3.0
On Tue, Apr 20, 2021 at 12:17:17PM +0200, Tomas Mraz wrote: > topic: Set PR 13817 milestone to Post 3.0 0 Kurt
Re: OTC VOTE: Set issue 11164 milestone to Post 3.0
On Tue, Apr 20, 2021 at 12:15:19PM +0200, Tomas Mraz wrote: > topic: Set issue 11164 milestone to Post 3.0 > Proposed by Tim Hudson > Public: yes > opened: 2021-04-20 > closed: 2021-04-20 > accepted: yes (for: 6, against: 1, abstained: 0, not voted: 4) -1 Kurt
Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
On Tue, Apr 20, 2021 at 07:20:48PM +0200, Bernd Zeimetz wrote: > > I did not want to spend time on figuring out if voting --- in > our voting system is the same as not voting at all Ranking all options the same has no effect on the result. It does not have an effect on the quorum or majority. The only effect it has is that more people voted. Kurt
Re: Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
On Mon, Apr 19, 2021 at 05:32:40PM +0100, Barak A. Pearlmutter wrote: > Sam Hartman writes: > > For me though, even there, notice that we'd be choosing between options > > that the voters considered acceptable. > > Because of that, I am not bothered by the cycle. > > If the decision doesn't really matter but a non-FD option must be > chosen (like a hungry group picking a restaurant) then sure, whatever. > > But for something important, I think we *should* be bothered by a cycle. > > Let me give an example. Let's say we end up with ALPHA, BETA, and > GAMMA in a cycle: ALPHA>BETA, BETA>GAMMA, GAMMA>ALPHA. So we run our > resolution algorithm, and it picks ALPHA. Well that's nice. But note > that if we had not had BETA as an option on the ballot, then GAMMA > would have been the winner, without anyone changing their votes. You might want to read: https://en.wikipedia.org/wiki/Independence_of_irrelevant_alternatives#Criticism_of_IIA > Not > only is that odd, but it means that it would be reasonable for a > die-hard ALPHA supporter, seeing that GAMMA is going to beat ALPHA, > would propose adding BETA to the ballot. This means that we are > vulnerable to strategic (rather than honest) behaviour throughout the > process, including in proposing ballot options. So that would be: https://en.wikipedia.org/wiki/Strategic_nomination If the option is similar to an existing option, it should not have an effect for the Schulze method we use: https://en.wikipedia.org/wiki/Independence_of_clones_criterion No voting system is perfect. Kurt
Re: DEP-16 Confidential votes
On Sun, Apr 18, 2021 at 11:58:55PM -0400, Olek Wojnar wrote: > Hi zigo, > > On Sun, Apr 18, 2021 at 6:16 PM Thomas Goirand wrote: > > > > > I'd be very much for leaving the decision of open/close to our > > secretary, with most votes open, and the possibility for him to decide > > when it should be closed. I trust Kurt to do the right thing whenever a > > vote (like the RMS GR) needs to be closed. Otherwise, I very much prefer > > if most votes were staying open. > > > > Note that the RMS GR was, in fact, open. :) > > I respect Kurt's interpretation of the constitution and the reluctance to > single-handedly interpret vague sections. I personally believe that "lists > all the votes cast" (4.2.3) should be interpreted to mean "lists by hash" > or another non-personally-identifying means. Perhaps that will need to be > clarified in the constitution, one way or the other, in the future. My > point is that Kurt's interpretation (as I understand it) is that all > non-DPL votes are open. So I don't believe that Kurt would ever make the > decision to have a confidential non-DPL vote. Kurt: please correct me if I > misunderstand you! The only real difference between a secret and non-secret vote currently is knowing who voted what. In both cases a list of voters and a list of votes is published. Changing the interpretation that we don't publish who voted what would turn our non-secret vote in the same a secret vote. I do no believe that was ever the intention. For every GR we have published who voted what. Kurt
Re: DEP-16 Confidential votes
On Sun, Apr 18, 2021 at 09:22:38PM +, Andrew M.A. Cater wrote: > > No, please don't. We already have problems enough with HTML - a structured > form would need to be fully accessible, secure, validated. A signed email > is (relatively) more straightforward and has served us well for the last > 25 years. An other option is that we have software in Debian that makes it easy to vote using email. For instance, we could have a tool that generates the data that needs to be mailed and have it in a format that that's easy to send over email. Kurt
Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
On Sun, Apr 18, 2021 at 07:17:18PM +0100, Neil McGovern wrote: > On Sun, Apr 18, 2021 at 06:58:49PM +0100, Barak A. Pearlmutter wrote: > > If the winning option in an election is part of a preference cycle, > > then it (by definition) has the property that there exists some other > > option that a majority of the voters preferred. In some elections that > > is unavoidable: we need to pick one DPL, and if they're in a cycle so > > be it; if there's a tie we can just toss a coin. But in others, like > > the RMS GR, it seems like it would be a rather bad property and we'd > > be better off treating it as FD and trying again later. > > > > For info, we use cloneproof Schwartz sequential dropping to resolve > these ties. The simple version is that we work out the cycle, and then > drop the lowest margin, in this case the 1, so "Debian will not issue a > pubilc statement" would still win. > > A full description is at https://en.wikipedia.org/wiki/Schulze_method We drop the weakest defeat, not margin. My understanding is that the weakest defeat is the one with the lowest number for the first value in the defeats below (137, 139, ...) If the assume option 4 beats option 7 instead of the other way around, as far as I know, we would end up with the following defeats being removed: Option 2 defeats Option 1 by ( 137 - 113) = 24 votes. Which doesn't drop an option from the Schwartz set Option 1 defeats Option 3 by ( 139 - 131) =8 votes. Which has as effect that option 1 is no longer in the Schwartz set Option 3 defeats Option 4 by ( 150 - 140) = 10 votes. Which has as effect that option 3 is no longer in the Schwartz set Option 2 defeats Option 4 by ( 165 - 132) = 33 votes. Which leaves only option 4 in the Schwartz set. Note that the following defeat is not removed in the sequence above: Option 4 defeats Option 1 by ( 156 - 146) = 10 votes. Since at that time option 1 is no longer in the Schwartz set, and so that defeat is no longer relevant. Kurt
Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
On Sun, Apr 18, 2021 at 06:58:49PM +0100, Barak A. Pearlmutter wrote: > I hope it is on-topic here to note that options 1, 3, and 4 formed a > Condorcet preference cycle. So these *do* occur in the wild! And not > for low-ranked obscure options either. > > The winning option 7 has an arrow with a 1 on it to option 4, which is > as razor-thin as you can get. If that arrow had been reversed (which > could be done by switching the order of two adjacent options on TWO > BALLOTS) the winning option would have been in an enormous preference > cycle of FIVE (5) options! The most likely winner in that case would option 4. Kurt
General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
Hi, The results of the General Resolution is: Option 7 "Debian will not issue a public statement on this issue" The details of the results are available at: https://www.debian.org/vote/2021/vote_002 Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
Debian Project Leader Election 2021 Results
Hi, The winner of the election is Jonathan Carter. The details of the results are available at: https://vote.debian.org/2021/vote_001 Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | | 2001 | ?? | ?? | |311 | || | | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | | 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | | 2011 | 911 | 45.274 | 402 |392 | 93 | 43.030 | 8.65836 | | 2012 | 948 | 46.184 | 436 |403 | 72 | 42.511 | 8.72589 | | 2013 | 988 | 47.149 | 402 |390 | 73 | 39.474 | 8.27170 | | 2014 | 1003 | 47.505 | 412 |401 | 61 | 39.980 | 8.44117 | | 2015 | 986 | 47.101 | 364 |353 | 39 | 35.801 | 7.49454 | | 2016 | 1023 | 47.977 | 286 |282 | 74 | 27.566 | 5.87787 | | 2017 | 1062 | 48.882 | 327 |322 | 57 | 30.320 | 6.58729 | | 2018 | 1001 | 47.457 | 343 |333 | 53 | 33.266 | 7.01674 | | 2019 | 1003 | 47.505 | 389 |378 | 59 | 37.687 | 7.95701 | | 2020 | 1011 | 47.694 | 352 |339 | 33 | 33.531 | 7.10776 | | 2021 | 1018 | 47.859 | 469 |455 | 89 | 44.695 | 9.50706 | |--+--++---++-++---| Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
Hi, The results of the General Resolution is: Option 7 "Debian will not issue a public statement on this issue" The details of the results are available at: https://www.debian.org/vote/2021/vote_002 Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
Debian Project Leader Election 2021 Results
Hi, The winner of the election is Jonathan Carter. The details of the results are available at: https://vote.debian.org/2021/vote_001 Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | | 2001 | ?? | ?? | |311 | || | | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | | 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | | 2011 | 911 | 45.274 | 402 |392 | 93 | 43.030 | 8.65836 | | 2012 | 948 | 46.184 | 436 |403 | 72 | 42.511 | 8.72589 | | 2013 | 988 | 47.149 | 402 |390 | 73 | 39.474 | 8.27170 | | 2014 | 1003 | 47.505 | 412 |401 | 61 | 39.980 | 8.44117 | | 2015 | 986 | 47.101 | 364 |353 | 39 | 35.801 | 7.49454 | | 2016 | 1023 | 47.977 | 286 |282 | 74 | 27.566 | 5.87787 | | 2017 | 1062 | 48.882 | 327 |322 | 57 | 30.320 | 6.58729 | | 2018 | 1001 | 47.457 | 343 |333 | 53 | 33.266 | 7.01674 | | 2019 | 1003 | 47.505 | 389 |378 | 59 | 37.687 | 7.95701 | | 2020 | 1011 | 47.694 | 352 |339 | 33 | 33.531 | 7.10776 | | 2021 | 1018 | 47.859 | 469 |455 | 89 | 44.695 | 9.50706 | |--+--++---++-++---| Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
Re: Missing Last call for votes
On Fri, Apr 16, 2021 at 05:53:39PM +0300, Adrian Bunk wrote: > I noticed no No Last call for votes has been sent for either vote so far, > which is usually sent around 48 hours before the end of a vote. > > Looking at graphs for past votes (e.g. [1] where one can easily see when > the second and last calls for vote were) we seem to be disenfranchising > between 20 and 100 DDs when no Last call for votes is sent, which is a > significant proportion of the voting population. > > Many DDs might be only reading d-d-a, and might be used to using the > Last call for votes as reminder to finally vote. I thought that the 48 hours was this night, not last night. I'll sent it shortly. Kurt
Re: "gr_rms" rejected but "Debian Project Leader 2021 Election" worked
On Fri, Apr 16, 2021 at 08:59:24AM +0900, Osamu Aoki wrote: > Hi again, > > This is not GMAIL problem. This involves only My PC and Debian > servers. > > (I use gmail only for recieving mails. I send mail from my Debian > shell account using SSH when I use @debuian.org address to avoid mail > rejections. So Gmail has nothing to do with my problem.) > > $ date -u --iso=sec > 2021-04-15T23:44:44+00:00 > > So still in voting period as far as I am concerned. > > I think the problem is: > > >gpg: WARNING: unsafe permissions on homedir > > >'/srv/vote.debian.org/data/gr_rms' > > I think times execution of permission setting to close voting may have > kicked in too early. Hi Osamu, I've replied privately to the mail you've sent to secretary, but I'm not sure that you saw it. I see that you attempted to vote again, and that you got the same error. Your 3 messages for the RMS GR were not signed, while your mail to the DPL election was signed. The error message contained: gpg: no valid OpenPGP data found. Which is almost always that there is no signature. Please make sure that you actually sign the email. There is no permission problem, nor a problem that the vote is over. Other people are able to vote. Kurt
Re: "gr_rms" rejected but "Debian Project Leader 2021 Election" worked
On Fri, Apr 16, 2021 at 08:59:24AM +0900, Osamu Aoki wrote: > Hi again, > > This is not GMAIL problem. This involves only My PC and Debian > servers. > > (I use gmail only for recieving mails. I send mail from my Debian > shell account using SSH when I use @debuian.org address to avoid mail > rejections. So Gmail has nothing to do with my problem.) > > $ date -u --iso=sec > 2021-04-15T23:44:44+00:00 > > So still in voting period as far as I am concerned. > > I think the problem is: > > >gpg: WARNING: unsafe permissions on homedir > > >'/srv/vote.debian.org/data/gr_rms' > > I think times execution of permission setting to close voting may have > kicked in too early. Hi Osamu, I've replied privately to the mail you've sent to secretary, but I'm not sure that you saw it. I see that you attempted to vote again, and that you got the same error. Your 3 messages for the RMS GR were not signed, while your mail to the DPL election was signed. The error message contained: gpg: no valid OpenPGP data found. Which is almost always that there is no signature. Please make sure that you actually sign the email. There is no permission problem, nor a problem that the vote is over. Other people are able to vote. Kurt
Re: Making the RMS resolution a Secret Ballot
On Sun, Apr 11, 2021 at 09:29:21AM +0900, Charles Plessy wrote: > I agree for the GR vote to be secret. I understand others came to a > different conclusion. I trust Kurt for making the right decision. I > will not complain about it. As secretary, I do not intend to make the vote secret. Personally, I would like to see the vote secret. I think the best way to make the vote secret is that the DPL makes a decision. We have a process that can deal with people not agreeing with that decision. Kurt
Re: Making the RMS resolution a Secret Ballot
On Fri, Apr 09, 2021 at 10:59:16AM -0700, Russ Allbery wrote: > > * A secret ballot, while contrary to the constitution for GRs, is not > wholly irregular for the project. We use one every year for the DPL > election and the tradeoffs are well-understood. This vote poses an > additional challenge because we haven't been using the verification > method we use for DPL votes from the start of the vote, but I don't > think this is a serious enough issue to be decisive. At worst, we are > extending one-time trust to the Project Secretary that he will > accurately count the votes without normal verification processes in this > one unusual circumstance, and then will immediately return to regular > order to discuss how to handle this going forward. I fear that devotee will break in various ways changing from a non-secret to a secret in the middle of a vote. But I could remove all processing of the results so far, and then reprocess all the received emails. This would result in getting a new acknowledgement (or error) mail. Kurt
Re: Making the RMS resolution a Secret Ballot
On Fri, Apr 09, 2021 at 01:12:26PM -0400, Sam Hartman wrote: > > On another list, there was discussion of the DPL encouraging the > secretary to make the vote on the rms GR secret. If we're going to go this way, I would really like to make this change soon. Based on the outcome of this, people might want to change their vote, and I would like to give them sufficient time to do so. Kurt
Re: Re: What does FD Mean
On Mon, Apr 05, 2021 at 09:45:15AM +0100, Barak A. Pearlmutter wrote: > > Let's say a cohort of voters prefers option APRICOT to option BANANA, > but would like neither (FD) even better. However they are well aware > that there's no way FD will win. > > It is possible that if they vote their true preference, > > FD > APRICOT > BANANA > > then BANANA will win, while if they vote > > APRICOT > FD > BANANA > > then APRICOT will win, due to majority/quorum issues. In other words, > they are penalized for voting honestly. It's true that our system isn't perfect, and that if you know how others will vote you can manipulate the outcome. You can try to influence which options get dropped or not due to quorum or more likely majority requirements. I think in your scenario, I assume APRICOT was dropped due to the quorum or majority requirements and changing their vote to mark APRICOT as acceptable means it was considered and can now have more people that prefer it over BANANA. It can also be abused the other way around. People who prefer: BANANA > APRICOT > FD might vote: BANANA > FD > APRICOT in an attempt to drop APRICOT as an option, for instance because they know there are a lot of people who're going to vote FD > APRICOT > BANANA. I don't believe this is actually a problem in Debian for general resolutions and elections. I don't think we know enough details about what others will vote or have group coordination to abuse it. A possible solution is to drop the majority requirement and have a quorum on the number of people that vote, and this would work for most votes, except those where we now have a supermajority requirement. Kurt
Re: What does FD Mean
On Sun, Apr 04, 2021 at 10:20:15PM +0200, Adam Borowski wrote: > On Sun, Apr 04, 2021 at 09:49:01PM +0200, Wouter Verhelst wrote: > > On Fri, Apr 02, 2021 at 11:29:58PM +0200, Pierre-Elliott Bécue wrote: > > > I'd rather have a None of the Above default option all the time along > > > with FD. It'd probably help. > > > > FD effectively is the same as "none of the above". > > Not really, what FD means is: "I vote yes for all of options I ranked higher > than it, and no for all I ranked lower". > > Our voting scheme is a mix of Condorcet, and yes/no. An option must get at > least 50% or 75% of "yes" votes, no matter if it's Condorcet winner. > > This meaning is mostly destroyed by interpreting FD as "Further Discussion" > -- it makes people put all other options on the front, instead of just ones > they agree with. There are 2 ways the FD option has an effect on the result. The first option is the quorum requirement. For a GR the quorum is 3*Q, which is around 47 for this vote. 3*Q people need to put the option above FD to meet the quorum, or the option is dropped. But the reason for yes/no is the majority requirement. In this GR all options have a majority ratio of 1. This means more people need to put the option above of FD than people who put the option below FD, or the option gets dropped. Note that you can rank the option the same as FD, which is neither yes nor no. So it's more than 50% of those votes that voted yes or no for that option that need to vote yes for the option to be considered. There are also 2:1 and 3:1 majority requirements, which you could translate as 66.6% and 75% need to say yes. Kurt
Re: New option for the RMS/FSF GR: reaffirm the values of the majority
On Sun, Apr 04, 2021 at 06:09:53PM +0200, Milan Zamazal wrote: > > "MK" == Matthias Klumpp writes: > > MK> I did actually read this as satire and was quite amused by it > > I’m not amused by it. I liked the 1st April joke, but this is not fun > anymore and the fact that someone as respectful as Enrico does that > makes me thinking about some ballot options in a different light. > > I’d like to get rid of this matter and vote ASAP but considering > something important and related can happen in two weeks (e.g. the whole > FSF board may resign), is it possible to change a vote later during the > voting period? According to the constitution, 4.2.6, “The Secretary > determines for each poll whether voters can change their votes.” but I > can’t see this information in the ballot e-mail. The software always allows you to change your vote. Kurt
Re: Constitution A.6 - "V(A,D) is strictly great"
On Sun, Apr 04, 2021 at 09:31:46AM +0200, Niels Thykier wrote: > Hi, > > In https://www.debian.org/devel/constitution#item-A, there is the > following sentence under A.6. bullet 3.2.: > > > An option A defeats the default option D by a majority ratio N, if V(A,D) > > is greater or equal to N * V(D,A) and V(A,D) is strictly great > > The "... and V(A,D) is strictly great" looks like an incomplete > sentence. Is that something we can fix as an editorial correction (i.e. > without a vote)? See #896067. Kurt
Debian Project Leader election 2021: First call for votes
Hi,
This is the first call for votes on the DPL election of 2021.
Voting period starts 2021-04-04 00:00:00 UTC
Votes must be received by 2021-04-17 23:59:59 UTC
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at https://www.debian.org/devel/constitution.
For voting questions or problems contact secret...@debian.org.
The details of the candidate's platform can be found at:
https://www.debian.org/vote/2021/platforms/
Also, note that you can get a fresh ballot any time before the end of
the vote by sending a mail to
bal...@vote.debian.org
with the subject "leader2021".
To vote you need to be a Debian Developer.
HOW TO VOTE
First, read the full text of the platform.
You might also want to read discussions with the candidates at
https://lists.debian.org/debian-vote/
To cast a vote, it is necessary to send this ballot filled out to a
dedicated e-mail address, in a signed message, as described below.
The dedicated email address this ballot should be sent to is:
leader2...@vote.debian.org
The form you need to fill out is contained at the bottom of this
message, marked with two lines containing the characters
'-=-=-=-=-=-'. Do not erase anything between those lines, and do not
change the choice names.
There are 3 choices in the form, which you may rank with numbers between
1 and 3. In the brackets next to your preferred choice, place a 1.
Place a 2 in the brackets next to your next choice. Continue until you
reach your last choice. Do not enter a number smaller than 1 or larger
than 3.
You may skip numbers, leave some choices unranked, and rank options
equally. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices.
To vote "no, no matter what", rank "None Of The Above" as more desirable
than the unacceptable choices, or you may rank the "None Of The Above"
choice and leave choices you consider unacceptable blank. (Note: if the
"None Of The Above" choice is unranked, then it is equal to all other
unranked choices, if any -- no special consideration is given to the
"None Of The Above" choice by the voting software).
Finally, mail the filled out ballot to: leader2...@vote.debian.org.
Don't worry about spacing of the columns or any quote characters (">") that
your reply inserts.
NOTE: The vote must be GPG signed (or PGP signed) with your key that is
in the Debian keyring. You may, if you wish, choose to send a signed,
encrypted ballot: use the vote key appended below for encryption.
The voting software (Devotee) accepts mail that either contains only an
unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
(RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.
VOTING SECRECY
This is a secret vote. After the voting period there will be a record
of all the votes without the name of the voter. It will instead contain
a cryptographic hash. You will receive a secret after you have voted
that can be used to calculate that hash. This allows you to verify
that your vote is in the list.
VOTING FORM
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
f9533fc1-129b-41db-822c-be8fe8e9faa6
[ ] Choice 1: Jonathan Carter
[ ] Choice 2: Sruthi Chandran
[ ] Choice 3: None Of The Above
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
--
The responses to a valid vote shall be signed by the vote key created
for this vote. The public key for the vote, signed by the Project
secretary, is appended below.
-BEGIN PGP PUBLIC KEY BLOCK-
mQINBGBoxFUBEADPmDEjOVT7o4UHOYufHtynfdsX1EvnHywK3bd7nGSYX5CsLxty
eURvDYK1Mg3OIsS+JCbet/iHGN7HBBWCkgxOiJegYpX/iJnNQcBnR9Ge1TnhVtCc
a2fHLsGe7wNnN7wg42rH0MwUOKQgZnp2X5EVXSgUjRj/3xr761/rN4YXIS8QYNbk
c1nPCbNkaCk1ZqEXC+a2FwM7F83u6X6qjID79IWZ9Wg7KvCa98foe2Msk2cZpwd0
Z+EUsfgb1vcHkeUNpWDOzrgCTweoBzwX1ONJr+du0yxEGhglnh0Aqa++szM1wUiG
UlZ5Dx/XjINEtaPon30yMufPnB8125XS5bFGzJedFzEEP+MQvnI7SstLvGmdRVMg
EchieCwXF8YFz+MpKMgJUjrwgiEXALMEkVqTcicqTautn80p7b3k3+iKafUym920
ekBOozGGArZbEHrfdbtcSfEPe6sG+Ns61oCb7gHJxD0P/KUZa9ukYNDvN+3PSWuf
f16tHErTssxwupqb9QfvIUnBQJriQOQlzzYK3dHyFkBgp99NVI+MgtfvERiRFwYA
T8ftUyneIHQiUK9N1cCtGDIIRwu9luGRWeZCgYEO6+8flpfsGFeLOJkRbXqo8B1E
Q6DvJU+X6z2rHuNgDNjcYEYGOei+m3nmEh59UCvieDHfvCS3RQUACouvlwARAQAB
tCpEUEwgdm90ZSAyMDIxIDxsZWFkZXIyMDIxQHZvdGUuZGViaWFuLm9yZz6JAj4E
EwEIACgFAmBoxFUCGwMFCQAaXgAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJ
EJJTdxl8z20U0lYQAJvfawTmOL8wLmNgxFhiGk0XGuTQHj3YZu7CSrMCKB1Q+kvj
r/7CoGq/peuja5UT+jWRVclOh+9Z3/W1zMRVN35vOMAEOrU3IB44+y2xWZYeQ+Wz
WCcdJvIWpxXCXuvIl4HpFqZ+m1WduE3WzWaYds7UF11ndXRS5az4Kci4SvlXWKKt
V8jjtjQ2D1bjsOyoJzxTJ6j8hwZS3Wj3vCDWHbq3UP4mAdRAt/J9yFUZcd6SRVk2
0zDq29ZV/zerETby0o5cltGwFwW8yAh2JEUJcp2iIQgryUezkAn3UOqP2Nx9YKgO
cWbcW3e3Rzmzx1gFxuav4sW/Tzcie74/cRO6gVRkFytxOQnOjwfw6j7GEFb+EdqE
Wv6jlPNat/fEfrSCmWpYsO47E4KCzbZ35pogLYhFpBzw0xXIq2sf9c0LtUQv7dKO
General Resolution: Statement regarding Richard Stallman's readmission to the FSF board: First call for votes
Hi,
This is the first call for votes on the General Resolution about
a statement regarding Richard Stallman's readmission to the FSF board.
Voting period starts 2021-04-04 00:00:00 UTC
Votes must be received by 2021-04-17 23:59:59 UTC
The following ballot is for voting on a statement regarding Richard
Stallman's readmission to the FSF board.
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at https://www.debian.org/devel/constitution.
For voting questions or problems contact secret...@debian.org.
The details of the general resolution can be found at:
https://www.debian.org/vote/2021/vote_002
Also, note that you can get a fresh ballot any time before the end of
the vote by sending a signed mail to
bal...@vote.debian.org
with the subject "gr_rms".
To vote you need to be a Debian Developer.
HOW TO VOTE
To cast a vote, it is necessary to send this ballot filled out to a
dedicated e-mail address, in a signed message, as described below.
The dedicated email address this ballot should be sent to is:
gr_...@vote.debian.org
The form you need to fill out is contained below in this
message, marked with two lines containing the characters
'-=-=-=-=-=-'. Do not erase anything between those lines, and do not
change the choice names.
There are 8 choices in the form, which you may rank with numbers between
1 and 8. In the brackets next to your preferred choice, place a 1.
Place a 2 in the brackets next to your next choice. Continue until you
reach your last choice. Do not enter a number smaller than 1 or larger
than 8.
You may skip numbers, leave some choices unranked, and rank options
equally. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices.
To vote "no, no matter what", rank "Further Discussion" as more desirable
than the unacceptable choices, or you may rank the "Further Discussion"
choice and leave choices you consider unacceptable blank. (Note: if the
"Further Discussion" choice is unranked, then it is equal to all other
unranked choices, if any -- no special consideration is given to the
"Further Discussion" choice by the voting software).
Finally, mail the filled out ballot to: gr_...@vote.debian.org.
Don't worry about spacing of the columns or any quote characters (">")
that your reply inserts.
NOTE: The vote must be GPG signed (or PGP signed) with your key that is
in the Debian keyring. You may, if you wish, choose to send a signed,
encrypted ballot: use the vote key appended below for encryption.
The voting software (Devotee) accepts mail that either contains only an
unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
(RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.
VOTING SECRECY
This is a non-secret vote. After the voting period is over the details on
who voted what will be published. During the vote itself the only
information that will be published is who voted.
You can encrypt your message to the voting system to keep your vote secret
until the end of the voting period. The software will also try to keep
your vote secret and will encrypt the reply it sends to you.
VOTING FORM
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
4c932db2-1cdc-4ea0-a6f7-ac8ba2fc010c
[ ] Choice 1: Call for the FSF board removal, as in rms-open-letter.github.io
[ ] Choice 2: Call for Stallman's resignation from all FSF bodies
[ ] Choice 3: Discourage collaboration with the FSF while Stallman is in a
leading position
[ ] Choice 4: Call on the FSF to further its governance processes
[ ] Choice 5: Support Stallman's reinstatement, as in
rms-support-letter.github.io
[ ] Choice 6: Denounce the witch-hunt against RMS and the FSF
[ ] Choice 7: Debian will not issue a public statement on this issue
[ ] Choice 8: Further Discussion
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
--
BALLOT OPTIONS
Choice 1: Call for the FSF board removal, as in rms-open-letter.github.io
=
The Debian Project co-signs the statement regarding Richard
Stallman's readmission to the FSF board seen at
https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md.
The text of this statement is given below.
Richard M. Stallman, frequently known as RMS, has been a
dangerous force in the free software community for a long time. He
has shown himself to be misogynist, ableist, and transphobic, among
other serious accusations of impropriety. These sorts of beliefs
have no place in the free software, digital rights, and tech
communities. With his recent reinstatement to the Board of Directors
of the Free Software Foundation, we call for the entire Board of the
FSF to step down and for RMS to be removed from all leadership
positions.
We, the undersigned, believe in the necessity
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
On Sun, Apr 04, 2021 at 09:14:31AM +1000, Craig Sanders wrote: > On Sat, Apr 03, 2021 at 05:43:38PM +0200, Pierre-Elliott Bécue wrote: > > Move choice 7 to 8 and put it seven. > > > > [ ] Choice 7: Rejecting and denouncing a witch-hunt against RMS. > > > > (maybe Craig has a better idea) > > Thanks, looks goodexcept for two problems: > > 1. you've used the wrong article "a" instead of "the". It's gramatically > incorrect, this isn't one of multiple witch-hunts, there's only one, singular. > So "the" is the correct article. > > 2. the witch-hunt is against the FSF board as well as RMS - that's kind of > what makes it a witch-hunt, rather than just persecution of an individual. > > [ ] Choice 7: Rejecting and denouncing the witch-hunt against RMS & the FSF. I think I just changed all places from: Denounce a witch-hunt against RMS and the FSF to: Denounce the witch-hunt against RMS and the FSF (Website is rebuilding, should be online in about 5 minutes.) Kurt
Draft ballot statement regarding Richard Stallman's readmission to the FSF board
Here is the draft ballot:
Voting period starts 2021-04-04 00:00:00 UTC
Votes must be received by 2021-04-17 23:59:59 UTC
The following ballot is for voting on a regarding Richard Stallman's
readmission to the FSF board
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at https://www.debian.org/devel/constitution.
For voting questions or problems contact secret...@debian.org.
The details of the general resolution can be found at:
https://www.debian.org/vote/2021/vote_002
Also, note that you can get a fresh ballot any time before the end of
the vote by sending a signed mail to
bal...@vote.debian.org
with the subject "gr_rms".
To vote you need to be a Debian Developer.
HOW TO VOTE
To cast a vote, it is necessary to send this ballot filled out to a
dedicated e-mail address, in a signed message, as described below.
The dedicated email address this ballot should be sent to is:
gr_...@vote.debian.org
The form you need to fill out is contained below in this
message, marked with two lines containing the characters
'-=-=-=-=-=-'. Do not erase anything between those lines, and do not
change the choice names.
There are 8 choices in the form, which you may rank with numbers between
1 and 8. In the brackets next to your preferred choice, place a 1.
Place a 2 in the brackets next to your next choice. Continue until you
reach your last choice. Do not enter a number smaller than 1 or larger
than 8.
You may skip numbers, leave some choices unranked, and rank options
equally. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices.
To vote "no, no matter what", rank "Further Discussion" as more desirable
than the unacceptable choices, or you may rank the "Further Discussion"
choice and leave choices you consider unacceptable blank. (Note: if the
"Further Discussion" choice is unranked, then it is equal to all other
unranked choices, if any -- no special consideration is given to the
"Further Discussion" choice by the voting software).
Finally, mail the filled out ballot to: gr_...@vote.debian.org.
Don't worry about spacing of the columns or any quote characters (">")
that your reply inserts.
NOTE: The vote must be GPG signed (or PGP signed) with your key that is
in the Debian keyring. You may, if you wish, choose to send a signed,
encrypted ballot: use the vote key appended below for encryption.
The voting software (Devotee) accepts mail that either contains only an
unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
(RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.
VOTING SECRECY
This is a non-secret vote. After the voting period is over the details on
who voted what will be published. During the vote itself the only
information that will be published is who voted.
You can encrypt your message to the voting system to keep your vote secret
until the end of the voting period. The software will also try to keep
your vote secret and will encrypt the reply it sends to you.
VOTING FORM
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
4c932db2-1cdc-4ea0-a6f7-ac8ba2fc010c
[ ] Choice 1: Call for the FSF board removal, as in rms-open-letter.github.io
[ ] Choice 2: Call for Stallman's resignation from all FSF bodies
[ ] Choice 3: Discourage collaboration with the FSF while Stallman is in a
leading position
[ ] Choice 4: Call on the FSF to further its governance processes
[ ] Choice 5: Support Stallman's reinstatement, as in
rms-support-letter.github.io
[ ] Choice 6: Denounce a witch-hunt against RMS and the FSF
[ ] Choice 7: Debian will not issue a public statement on this issue
[ ] Choice 8: Further Discussion
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
--
BALLOT OPTIONS
Choice 1: Call for the FSF board removal, as in rms-open-letter.github.io
=
The Debian Project co-signs the statement regarding Richard
Stallman's readmission to the FSF board seen at
https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md.
The text of this statement is given below.
Richard M. Stallman, frequently known as RMS, has been a
dangerous force in the free software community for a long time. He
has shown himself to be misogynist, ableist, and transphobic, among
other serious accusations of impropriety. These sorts of beliefs
have no place in the free software, digital rights, and tech
communities. With his recent reinstatement to the Board of Directors
of the Free Software Foundation, we call for the entire Board of the
FSF to step down and for RMS to be removed from all leadership
positions.
We, the undersigned, believe in the necessity of digital autonomy
and the powerful role user freedom plays in protecting our
fundamental human rights. In order to realize the
Draft ballot DPL election
Here is a draft ballot for the DPL election:
Voting period starts 2021-04-04 00:00:00 UTC
Votes must be received by 2021-04-17 23:59:59 UTC
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at https://www.debian.org/devel/constitution.
For voting questions or problems contact secret...@debian.org.
The details of the candidate's platform can be found at:
https://www.debian.org/vote/2021/platforms/
Also, note that you can get a fresh ballot any time before the end of
the vote by sending a mail to
bal...@vote.debian.org
with the subject "leader2021".
To vote you need to be a Debian Developer.
HOW TO VOTE
First, read the full text of the platform.
You might also want to read discussions with the candidates at
https://lists.debian.org/debian-vote/
To cast a vote, it is necessary to send this ballot filled out to a
dedicated e-mail address, in a signed message, as described below.
The dedicated email address this ballot should be sent to is:
leader2...@vote.debian.org
The form you need to fill out is contained at the bottom of this
message, marked with two lines containing the characters
'-=-=-=-=-=-'. Do not erase anything between those lines, and do not
change the choice names.
There are 3 choices in the form, which you may rank with numbers between
1 and 3. In the brackets next to your preferred choice, place a 1.
Place a 2 in the brackets next to your next choice. Continue until you
reach your last choice. Do not enter a number smaller than 1 or larger
than 3.
You may skip numbers, leave some choices unranked, and rank options
equally. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices.
To vote "no, no matter what", rank "None Of The Above" as more desirable
than the unacceptable choices, or you may rank the "None Of The Above"
choice and leave choices you consider unacceptable blank. (Note: if the
"None Of The Above" choice is unranked, then it is equal to all other
unranked choices, if any -- no special consideration is given to the
"None Of The Above" choice by the voting software).
Finally, mail the filled out ballot to: leader2...@vote.debian.org.
Don't worry about spacing of the columns or any quote characters (">") that
your reply inserts.
NOTE: The vote must be GPG signed (or PGP signed) with your key that is
in the Debian keyring. You may, if you wish, choose to send a signed,
encrypted ballot: use the vote key appended below for encryption.
The voting software (Devotee) accepts mail that either contains only an
unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
(RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.
VOTING SECRECY
This is a secret vote. After the voting period there will be a record
of all the votes without the name of the voter. It will instead contain
a cryptographic hash. You will receive a secret after you have voted
that can be used to calculate that hash. This allows you to verify
that your vote is in the list.
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
f9533fc1-129b-41db-822c-be8fe8e9faa6
[ ] Choice 1: Jonathan Carter
[ ] Choice 2: Sruthi Chandran
[ ] Choice 3: None Of The Above
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
--
The responses to a valid vote shall be signed by the vote key created
for this vote. The public key for the vote, signed by the Project
secretary, is appended below.
-BEGIN PGP PUBLIC KEY BLOCK-
mQINBGBoxFUBEADPmDEjOVT7o4UHOYufHtynfdsX1EvnHywK3bd7nGSYX5CsLxty
eURvDYK1Mg3OIsS+JCbet/iHGN7HBBWCkgxOiJegYpX/iJnNQcBnR9Ge1TnhVtCc
a2fHLsGe7wNnN7wg42rH0MwUOKQgZnp2X5EVXSgUjRj/3xr761/rN4YXIS8QYNbk
c1nPCbNkaCk1ZqEXC+a2FwM7F83u6X6qjID79IWZ9Wg7KvCa98foe2Msk2cZpwd0
Z+EUsfgb1vcHkeUNpWDOzrgCTweoBzwX1ONJr+du0yxEGhglnh0Aqa++szM1wUiG
UlZ5Dx/XjINEtaPon30yMufPnB8125XS5bFGzJedFzEEP+MQvnI7SstLvGmdRVMg
EchieCwXF8YFz+MpKMgJUjrwgiEXALMEkVqTcicqTautn80p7b3k3+iKafUym920
ekBOozGGArZbEHrfdbtcSfEPe6sG+Ns61oCb7gHJxD0P/KUZa9ukYNDvN+3PSWuf
f16tHErTssxwupqb9QfvIUnBQJriQOQlzzYK3dHyFkBgp99NVI+MgtfvERiRFwYA
T8ftUyneIHQiUK9N1cCtGDIIRwu9luGRWeZCgYEO6+8flpfsGFeLOJkRbXqo8B1E
Q6DvJU+X6z2rHuNgDNjcYEYGOei+m3nmEh59UCvieDHfvCS3RQUACouvlwARAQAB
tCpEUEwgdm90ZSAyMDIxIDxsZWFkZXIyMDIxQHZvdGUuZGViaWFuLm9yZz6JAj4E
EwEIACgFAmBoxFUCGwMFCQAaXgAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJ
EJJTdxl8z20U0lYQAJvfawTmOL8wLmNgxFhiGk0XGuTQHj3YZu7CSrMCKB1Q+kvj
r/7CoGq/peuja5UT+jWRVclOh+9Z3/W1zMRVN35vOMAEOrU3IB44+y2xWZYeQ+Wz
WCcdJvIWpxXCXuvIl4HpFqZ+m1WduE3WzWaYds7UF11ndXRS5az4Kci4SvlXWKKt
V8jjtjQ2D1bjsOyoJzxTJ6j8hwZS3Wj3vCDWHbq3UP4mAdRAt/J9yFUZcd6SRVk2
0zDq29ZV/zerETby0o5cltGwFwW8yAh2JEUJcp2iIQgryUezkAn3UOqP2Nx9YKgO
cWbcW3e3Rzmzx1gFxuav4sW/Tzcie74/cRO6gVRkFytxOQnOjwfw6j7GEFb+EdqE
Wv6jlPNat/fEfrSCmWpYsO47E4KCzbZ35pogLYhFpBzw0xXIq2sf9c0LtUQv7dKO
vynVRDJsqiBGBdxzjNCjZUvtWpwODIiXkdYQLrNXdaQkYu4vmVAn6rPIuS0PUzTl
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
The option has been committed to the website, it should appear soon.
Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 08:12:50PM +0200, Michael Biebl wrote: > On Sat, Apr 03, 2021 at 10:56:45AM +1100, Craig Sanders wrote: > > Short and simple: > > > > TEXT OF OPTION 5 > > > > > > Debian refuses to participate in and denounces the witch-hunt against > Richard > > Stallman, the Free Software Foundation, and the members of the board of > the > > Free Software Foundation. > > > > > > I think this option should be on the ballot as well for a fair > representation off all sides. So seconded. This mail wasn't signed. There are more than enough seconds already. Kurt
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 07:15:22PM +0200, Micha Lenk wrote: > My previous attempt yielded an invalid signature for me, so, trying again with > a different mailer... This one worked. Kurt
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 07:07:54PM +0200, Micha Lenk wrote: > Am 03.04.21 um 01:56 schrieb Craig Sanders: > > Short and simple: > > > > TEXT OF OPTION 5 > > > > > > Debian refuses to participate in and denounces the witch-hunt > > against Richard Stallman, the Free Software Foundation, and the > > members of the board of the Free Software Foundation. > > > > > Seconded. Thanks. I can not verify this signature. Kurt
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 06:21:54PM +0200, Adam Borowski wrote: > On Sat, Apr 03, 2021 at 10:56:45AM +1100, Craig Sanders wrote: > > TEXT OF OPTION 5 > > > > > > Debian refuses to participate in and denounces the witch-hunt against > > Richard > > Stallman, the Free Software Foundation, and the members of the board of the > > Free Software Foundation. > > > > > > Seconded. > > I'd prefer a more positive wording, such as "Debian re-affirms the > Diversity Statement as written, and thus denounces ...", but your version is > good enough. I will not accept any changes other than what I think is minor at this point, except when there are enough people to confirm that change. Kurt
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 10:56:45AM +1100, Craig Sanders wrote: > Short and simple: > > TEXT OF OPTION 5 > > > Debian refuses to participate in and denounces the witch-hunt against Richard > Stallman, the Free Software Foundation, and the members of the board of the > Free Software Foundation. Someone please propose what the name of the option on the ballot should be, and where I should put it in the order. Kurt
Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 03:53:58PM +0300, Adrian Bunk wrote: > On Fri, Apr 02, 2021 at 06:20:47PM +1100, Craig Sanders wrote: > > > > TEXT OF OPTION 5 > > > > > > Debian refuses to participate in and denounces the witch-hunt against > > Richard > > Stallman, the Free Software Foundation, and the members of the board of the > > Free Software Foundation. > > > > > > Questions to the Project Secretary: > > Was this email (which is not the repost email) a validly signed email > proposing an amendment to the GR? I did verify the signature, and it was good. The subject of the email clearly indicates to me it's an amendment to the GR. It would have been nice that it said it replaced the whole proposal with that text, but I think it's clear enough what the intention is. So I think the answer to your question is yes. But note that at that time it's still just a proposal, it's not been accepted, nor has it received enough sponsors. > If yes: > > Since A.2.3. of our constitution says "calls" and not "called", > do you agree that a vote has not been called before the person who calls > for a vote has made a statement on what they believe the wordings of the > resolution and any relevant amendments are? I currently don't see why the call only happened after the other things happened. As far as I know, it's not exactly defined when the discussion period stops, and it seems you want a clear point. But since there is no clear point, I am flexible up to a certain point. A.2.3 also seems to that they should copy the full text all the options. The text is already on the website, so I see little point in doing that. Kurt
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 05:48:47AM -0700, Felix Lechner wrote: > Hi, > > On Sat, Apr 3, 2021 at 12:34 AM Kurt Roeckx wrote: > > > > The discussion period is over, no new options will be added. > > That does not seem right. The submission arrived during the discussion > period and was only formally deficient, yes? There was actually no signed amendment before the call for vote. But it still requires at least 5 people the sponsor it. > Since the discussion period was already shortened and we also rely on > a particular reading of unclear wording in the constitution, I think > it would further the sense of democratic expression to accept Craig's > submission. If you really think we need more options, you will need to have enough sponsor before 18 UTC, 4 hours from now. Kurt
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 10:59:53PM +1100, Craig Sanders wrote: > On Sat, Apr 03, 2021 at 01:56:32PM +0200, Kurt Roeckx wrote: > > A vote has been called. > > Nope, can't have been. > > The last amendment (before mine) was accepted on March 30th, which means the > earliest a vote can be called with a shortened 1 week discussion period is > April 7th. > > Any CFV before then is invalid. This has been discussed before. It did not reset the minimum discussion time. Kurt
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 10:38:23PM +1100, Craig Sanders wrote: > On Sat, Apr 03, 2021 at 09:33:48AM +0200, Kurt Roeckx wrote: > > On Sat, Apr 03, 2021 at 10:56:45AM +1100, Craig Sanders wrote: > > > Short and simple: > > > > > > TEXT OF OPTION 5 > > > > > > > > > Debian refuses to participate in and denounces the witch-hunt against > > > Richard > > > Stallman, the Free Software Foundation, and the members of the board of > > > the > > > Free Software Foundation. > > > > > > > > > > The discussion period is over, no new options will be added. > > Since when is it over? > > The DPL changing the *minimum* discussion period is a minimum only, it > does not set a maximum. A vote has been called. Kurt
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 10:56:45AM +1100, Craig Sanders wrote: > Short and simple: > > TEXT OF OPTION 5 > > > Debian refuses to participate in and denounces the witch-hunt against Richard > Stallman, the Free Software Foundation, and the members of the board of the > Free Software Foundation. > > The discussion period is over, no new options will be added. Kurt
Re: Call for votes on «Statement regarding Richard Stallman's readmission to the FSF board»
On Fri, Apr 02, 2021 at 09:53:30AM -0600, Gunnar Wolf wrote: > Kurt Roeckx dijo [Fri, Apr 02, 2021 at 09:29:06AM +0200]: > > On Fri, Apr 02, 2021 at 01:06:49AM -0600, Gunnar Wolf wrote: > > > Dear Debian Project Secretary, > > > > > > Given the DPL authorized a shortened discussion period, and that, while > > > said discussion period allowed for a wide range of voting choices to > > > be accepted in the ballots, the tone of the discussion is highly > > > confrontational and I judge we will not gain any further insights or > > > wordings merely by giving it more time. > > > > > > So, by following the Debian constitution (A.2), as a sponsor for one > > > of the amendments, I call for a vote, and ask you to draft the > > > corresponding ballot. > > > > Please suggest names and maybe an order of the options. > > Better done with the morning coffee than late at night :-) > > I suggest the following options and ordering to appear on the ballot: > > [A] Call for the FSF board removal, as in rms-open-letter.github.io > (proposed by Steve Langasek, currently base proposal) > > [B] Call for Stallman's resignation from FSF all bodies > (proposed by Sruthi Chandran, currently proposal B) > > [C] Discurage collaboration with the FSF while Stallman is in a leading > position > (proposed by Santiago Ruano Rincón, currently proposal C) > > [D] Call on the FSF to further its governance processes > (proposed by Jonathan Wiltshire, currently proposal D) > > [E] Debian will not issue a public statement on this issue > (proposed by Timo Weingärtner, currently proposal E) > > [F] Support Stallman's reinstatement, as in rms-support-letter.github.io > (proposed by Timo Weingärtner, currently proposal A) I've committed this to the webpage. The ballot will probably look like: [ ] Choice 1: Call for the FSF board removal, as in rms-open-letter.github.io [ ] Choice 2: Call for Stallman's resignation from all FSF bodies [ ] Choice 3: Discourage collaboration with the FSF while Stallman is in a leading position [ ] Choice 4: Call on the FSF to further its governance processes [ ] Choice 5: Support Stallman's reinstatement, as in rms-support-letter.github.io [ ] Choice 6: Debian will not issue a public statement on this issue [ ] Choice 7: Further Discussion Kurt
Re: "rms-open-letter" GR choice 2: sign https://rms-support-letter.github.io/
On Fri, Apr 02, 2021 at 07:30:58PM +0200, Pierre-Elliott Bécue wrote: > Ah I see! > > Thanks for this. > > I think your interpretation is the most relevant one for now but indeed > there is some place here for improvements. > > I intend to propose a Constitution change taking into account the secret > vote question and that. You might want to read the thread starting at: https://lists.debian.org/debian-vote/2019/11/msg00208.html Kurt
Re: "rms-open-letter" GR choice 2: sign https://rms-support-letter.github.io/
On Fri, Apr 02, 2021 at 07:15:32PM +0200, Pierre-Elliott Bécue wrote: > Le vendredi 02 avril 2021 à 08:56:33+0200, Kurt Roeckx a écrit : > > On Thu, Apr 01, 2021 at 09:11:29PM -0700, Russ Allbery wrote: > > > Phil Morrell writes: > > > > > > > Do the additional proposals made in that week mean the discussion period > > > > has automatically been extended? Is the Secretary simply being pragmatic > > > > here, executing discretion before announcing the start of the voting > > > > period? Or perhaps the DPL has likely requested another alteration? > > > > > > Debian constitution A.2: > > > > > > 1. The proposer or a sponsor of a motion or an amendment may call for a > > >vote, providing that the minimum discussion period (if any) has > > >elapsed. > > > > > > 2. The proposer or any sponsor of a resolution may call for a vote on that > > >resolution and all related amendments. > > > > > > The vote does not automatically commence after the end of the discussion > > > period. Someone who is a proposer or sponsor has to explicitly call for > > > it. > > > > There is also this in 4.2: > > 4. The minimum discussion period is 2 weeks, but may be varied by up > >to 1 week by the Project Leader. The Project Leader has a casting > >vote. There is a quorum of 3Q. > > > > The DPL changed the minimum time for the discussion period to 1 week. > > The discussion period is over when a vote is called. > > Not to wreck havoc, but there also is in A.2: > > 4. The minimum discussion period is counted from the time the last formal > amendment was accepted, or since the whole resolution was proposed if no > amendments have been proposed and accepted. > > So I guess since you acccepted the last amendment on March the 31st,, > we're up to the 7th April before the vote may be called for. > > Am I wrong? This is part where the constitution is really hard to parse, and it's something I've struggled with for a long time. The terms are used in conflicting ways. I hope someone will take the time to fix this. In A.1. there is: 2. A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match. 3. If a formal amendment is not accepted, or one of the sponsors of the resolution does not agree with the acceptance by the proposer of a formal amendment, the amendment remains as an amendment and will be voted on. It's my current interpretation that no formal amendment was accepted. Kurt
Re: Call for votes on «Statement regarding Richard Stallman's readmission to the FSF board»
On Fri, Apr 02, 2021 at 01:06:49AM -0600, Gunnar Wolf wrote: > Kurt Roeckx dijo [Fri, Apr 02, 2021 at 08:56:33AM +0200]: > > There is also this in 4.2: > > 4. The minimum discussion period is 2 weeks, but may be varied by up > >to 1 week by the Project Leader. The Project Leader has a casting > >vote. There is a quorum of 3Q. > > > > The DPL changed the minimum time for the discussion period to 1 week. > > The discussion period is over when a vote is called. > > Dear Debian Project Secretary, > > Given the DPL authorized a shortened discussion period, and that, while > said discussion period allowed for a wide range of voting choices to > be accepted in the ballots, the tone of the discussion is highly > confrontational and I judge we will not gain any further insights or > wordings merely by giving it more time. > > So, by following the Debian constitution (A.2), as a sponsor for one > of the amendments, I call for a vote, and ask you to draft the > corresponding ballot. Please suggest names and maybe an order of the options. Kurt
Re: "rms-open-letter" GR choice 2: sign https://rms-support-letter.github.io/
On Thu, Apr 01, 2021 at 09:11:29PM -0700, Russ Allbery wrote: > Phil Morrell writes: > > > Do the additional proposals made in that week mean the discussion period > > has automatically been extended? Is the Secretary simply being pragmatic > > here, executing discretion before announcing the start of the voting > > period? Or perhaps the DPL has likely requested another alteration? > > Debian constitution A.2: > > 1. The proposer or a sponsor of a motion or an amendment may call for a >vote, providing that the minimum discussion period (if any) has >elapsed. > > 2. The proposer or any sponsor of a resolution may call for a vote on that >resolution and all related amendments. > > The vote does not automatically commence after the end of the discussion > period. Someone who is a proposer or sponsor has to explicitly call for > it. There is also this in 4.2: 4. The minimum discussion period is 2 weeks, but may be varied by up to 1 week by the Project Leader. The Project Leader has a casting vote. There is a quorum of 3Q. The DPL changed the minimum time for the discussion period to 1 week. The discussion period is over when a vote is called. Kurt
Re: Amendment to RMS/FSF GR: Option 5
On Fri, Apr 02, 2021 at 12:08:52PM +1100, Craig Sanders wrote: > Short and simple: > > TEXT OF OPTION 5 > > > Debian refuses to participate in and denounces the witch-hunt against Richard > Stallman, the Free Software Foundation, and the members of the board of the > Free Software Foundation. > > Please sign your message. Kurt
Re: "rms-open-letter" GR choice 2: sign https://rms-support-letter.github.io/
The option is now on the website. Kurt
Re: Secret ballot and RMS Resolution
On Thu, Apr 01, 2021 at 10:18:08AM -0700, Felix Lechner wrote: > Hi, > > On Thu, Apr 1, 2021 at 9:59 AM Kurt Roeckx wrote: > > > > I could move to voting software like Belenios > > Moving to new software without preparation or a chance to practice > could discourage centrist voters—i.e. those who care least but provide > the gravity to hold the project together. > > It could perhaps harm the vote's legitimacy, especially in view of the > perceived rush and the already abbreviated discussion period. I'm not suggesting that for either the current DPL vote or the GR that's being discussed. Kurt
Re: Secret ballot and RMS Resolution
On Thu, Apr 01, 2021 at 09:47:51AM -0700, Russ Allbery wrote: > Stefano Zacchiroli writes: > > > This is probably something that should be fixed in the Constitution, by > > mandating secret voting for elections whereas living to the judgment of > > the secretary whether other GR votes should be secret or not. > > I didn't quite parse that, so I'm not sure if this is what you were > already proposing, but I wonder if we should just have secret ballots for > all votes. That avoids the argument over whether a given vote should be a > secret ballot. I admit to being endlessly curious about the opinions of > my fellow contributors, but that's just me being nosy and I don't have any > real reason to need to know. Secret ballots seem like they would be > reassuring for the people who are the least willing to be vocal on mailing > lists. > > In the current on-line landscape, I think it's also incumbent on any > organization to look for ways in which their procedures or tools could be > used for harassment and to try to make them safer, and secret ballots seem > like an obvious thing for us to do here. > > The obvious difficulty with secret ballots is that it requires a lot of > trust in the votetaker. We have a verification process for people to > check whether their vote was recorded correctly, but I don't think there's > any good way with our style of secret ballot to verify that the votetaker > didn't add new votes that no one actually sent. But (a) personally I am > not worried about the Project Secretary manipulating the vote, and (b) I > can think of a few ways to deal with that should that ever be enough of a > concern, such as having a small number of people trusted with confidential > information jointly double-check the tally. > > This obviously would have an impact on the Project Secretary, so I'd love > to hear Kurt and Neil's opinion about the possible merits of going to > secret ballots for all votes. I could move to voting software like Belenios that only supports secret votes and has a way that doesn't require trust in (just) the Secretary. Kurt
Re: Secret ballot and RMS Resolution
On Thu, Apr 01, 2021 at 04:40:59PM +0200, Stefano Zacchiroli wrote: > On Thu, Apr 01, 2021 at 12:42:01PM +, Jean Duprat (Avignon) wrote: > > Votes in leadership elections are kept secret even after the end of > > the voting period for obvious reasons: by knowing that the ballot is > > secret, voters can feel free to express their opinion as they see > > fit. This constitutional guarantee sadly does not apply to General > > Resolutions. > > I think we're at opposite ends of the voting spectrum here on this > matter, but I share your concern. > > In fact, I think that *any* position taken in this vote could result in > targeted harassment of the voters. > > As this is a vote on a person (even if an indirect one, in the sense > that is not an election), most democratic systems will treat it as a > vote where ballots should be secret. But I fear that the Debian > Constitution ties the hands of the secretary here, or am I missing > something here Kurt? This would be a vote I would also like to see as secret. The constitution says: 3. Votes are taken by the Project Secretary. Votes, tallies, and results are not revealed during the voting period; after the vote the Project Secretary lists all the votes cast. The voting period is 2 weeks, but may be varied by up to 1 week by the Project Leader. While for DPL election it says: 5. The next two weeks are the polling period during which Developers may cast their votes. Votes in leadership elections are kept secret, even after the election is finished. You could say that "all the votes cast" could mean what was voted, now who voted what, but I think that conflicts with the intention of the text. Kurt
Re: Announcing new decision making procedures for Debian
On Thu, Apr 01, 2021 at 10:28:16AM +0200, Christian Kastner wrote: > On 01.04.21 10:11, Santiago R.R. wrote: > > What happens if Kurt also wants to take part in the discussion? Should > > we decide on who will review the messages and announce the winner of > > that discussion? > > I was worried about this, too. > > I'm not sure that deciding on another reviewer is feasible. Actually, > that would probably set us back to right where we started. > > I think we have to differentiate between two cases: > (1) Kurs agrees with the winner > (2) Kurs disagrees with the winner > > (1) is a non-issue, I think. > > For (2), I could imagine that a best-of-5 rock-paper-scissors tournament > as a possible quick solution. That, of course, assumes that Kurt won't > manipulate the contest (he still chooses the opponent, after all) but > we're all assuming good faith here. Since I get to decide the winner, I'm clearly going to pick the one that gives me the most power. Kurt
Re: Amendment to RMS/FSF GR: Option 4, assert the need to learn and grow from recent events
This option is now also on the website. Kurt
Re: Amendement to GR Statement regarding Stallman's readmission to the FSF board
This option is now also on the website.
OTC VOTE: EVP_PKEY types are immutable once set
Hi, I just found this in votes.txt, it looks like it was not mailed to the list as required. topic: EVP_PKEY types are immutable once set. Types cannot be changed once set. To move from one type to another compatible type will require export/import. Comment: This will result in breaking changes compared to previous releases. Proposed by Tim Public: yes opened: 2021-03-23 closed: 2021-03-23 accepted: yes (for: 6, against: 0, abstained: 0, not voted: 5) Matt [+1] Mark [ ] Pauli [+1] Viktor [ ] Tim[+1] Richard[+1] Shane [+1] Tomas [+1] Kurt [ ] Matthias [+1] # 2021-03-23 Nicola [+1] # 2021-03-30 I'm voting +1 on this. Kurt
Re: Amendement to GR Statement regarding Stallman's readmission to the FSF board
On Mon, Mar 29, 2021 at 05:42:23PM +0300, Apollon Oikonomopoulos wrote: > > Seconded, thank you Santiago! Your message was not signed. Kurt
Re: Amendment to GR on RMS rejoining FSF
On Sun, Mar 28, 2021 at 12:40:56PM +0200, Pierre-Elliott Bécue wrote: > Le 27 mars 2021 13:55:23 GMT+01:00, Kurt Roeckx a écrit : > >On Sat, Mar 27, 2021 at 01:27:38PM +0100, Kurt Roeckx wrote: > >> On Sat, Mar 27, 2021 at 12:17:58AM +0530, Sruthi Chandran wrote: > >> > > belately conveyed [0] to FSF’s staff and supporters. > >> > >> I've changed that to "belatedly". > > > >The option has been committed, it should be on the website soon. > > > > > >Kurt > > > > I think you forgot my sponsorship on this one. Not that it makes any real > difference but maybe it is worth adding. I've committed the change, will appear on the website on the next rebuild. Kurt
Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms
On Sat, Mar 27, 2021 at 01:56:08PM +0100, Timo Weingärtner wrote: > Hallo Kurt Roeckx, > > 27.03.21 13:03 Kurt Roeckx: > > I've added this option on the website. I'm still processing emails. > > > > Note that it's my interpretation that if changes are accepts that > > there is no need to second it again. If you don't agree with the > > changes need to say so, and which point and become the proposer of > > a new option and need to look for seconds again. > > > > Please let me know if there is something that's currently on the > > website that you don't agree with. > > The content is fine, maybe the headings could be improved to look like (as a > recent example) in the systemd GR. I'm not sure what you mean, but I'm not really happy with the current wording of the option names. It's up to the one calling for vote to suggest the names. But I'm sure that any suggestions are welcome. Kurt
Re: Amendment to GR on RMS rejoining FSF
On Sat, Mar 27, 2021 at 01:27:38PM +0100, Kurt Roeckx wrote: > On Sat, Mar 27, 2021 at 12:17:58AM +0530, Sruthi Chandran wrote: > > > belately conveyed [0] to FSF’s staff and supporters. > > I've changed that to "belatedly". The option has been committed, it should be on the website soon. Kurt
Re: Amendment to GR on RMS rejoining FSF
On Sat, Mar 27, 2021 at 12:17:58AM +0530, Sruthi Chandran wrote: > > belately conveyed [0] to FSF’s staff and supporters. I've changed that to "belatedly". Kurt
Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms
I've added this option on the website. I'm still processing emails. Note that it's my interpretation that if changes are accepts that there is no need to second it again. If you don't agree with the changes need to say so, and which point and become the proposer of a new option and need to look for seconds again. Please let me know if there is something that's currently on the website that you don't agree with. Kurt
Re: Amendment to GR on RMS rejoining FSF
On Fri, Mar 26, 2021 at 10:45:57PM +0530, Sruthi Chandran wrote: > > > Dear fellow DDs, > > Second the amendment text if acceptable to you :) I'm getting a BAD signature on this and some other mails from you, and a Good one on others. Kurt
Re: Amendment to rms-open-letter GR
On Fri, Mar 26, 2021 at 01:48:39AM -0500, Richard Laager wrote: > > Seeking seconds: > > > > ===BEGIN > > > > Replace the entire text with: > > > > Under section 4.1.5 of the constitution, the Developers make the > > following statement: > > > > The Debian Project echoes and supports recent calls to remove Richard > > M. Stallman from positions of leadership within free software, for which > > we believe him to be inappropriate. > > > > We are disappointed by the actions of those responsible for restoring > > him to the Free Software Foundation's Board of Directors, and urge that > > that decision be reversed. > > > > ===END > > Seconded. Please sign your message. (It would turn into the 4th second.) Kurt
Re: General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io
On Thu, Mar 25, 2021 at 03:19:19PM -0400, Paul R. Tagliamonte wrote: > D'oh! > > Due to cascading failures, I had to clearsign to get around some GMail > issues I've been having. It looks to have line wrapped me, I've attached > the content from above. > > Additionally, my key expired, I've pushed an updated key to the > keyservers, as well as Debian's. I thought I did this last month but it > doesn't look to be updated fully. I don't know if it's A, B or A & B that's > flagging for you > > paultag That resulted in a Good signature. Kurt
Re: General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io
On Wed, Mar 24, 2021 at 10:37:26PM +0100, Sylvestre Ledru wrote: > Seconded I get a: *BAD* signature from: Sylvestre Ledru aka: Sylvestre Ledru aka: Sylvestre Ledru aka: Sylvestre Ledru aka: Sylvestre Ledru aka: Sylvestre Ledru aka: Sylvestre Ledru aka: Sylvestre Ledru Kurt
Re: General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io
On Wed, Mar 24, 2021 at 05:13:28PM -0400, Paul R. Tagliamonte wrote: > > Under 4.1.5 of the Constitution, the developers by way of GR are the body > > who has the power to issue nontechnical statements. > > > > > https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md > > is a statement which I believe Debian as a project, and not just > individual > > Debian developers, should consider signing on to. > > > > This is a proposal for Debian to sign on to the statement, by adopting the > > text from that open letter via GR. > > I second this GR. I get a: *BAD* signature from: Paul Tagliamonte Kurt
Re: OTC VOTE: Add a description field to OSSL_ALGORITHM
On Tue, Mar 23, 2021 at 09:12:40AM +, Matt Caswell wrote: > This vote has now closed: > > accepted: yes (for: 5, against: 1, abstained: 1, not voted: 4) It seems unclear to me that you can close the vote at this time. The result is not clear, the 4 people who didn't vote can vote -1 in which case it doesn't pass. The vote period is between 7 and 14 days, but no close date was specified as required by the bylaws. I think we normally use 14 days. Anyway, voting -1. Kurt > On 16/03/2021 10:10, Matt Caswell wrote: > > topic: Add a description field to the OSSL_ALGORITHM structure > > Comment: See Issue #14514 for background > > Proposed by Matt Caswell > > Public: yes > > opened: 2021-03-16 > > closed: 2021-mm-dd > > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > > > Matt [+1] > > Mark [ ] > > Pauli [-1] > > Viktor [ ] > > Tim [ ] > > Richard [+1] > > Shane [ 0] > > Tomas [+1] > > Kurt [ ] > > Matthias [ ] > > Nicola [+1]
Re: Clock tracking
On Mon, Mar 22, 2021 at 02:24:50PM -0700, Hal Murray via devel wrote: > > Since you mentioned PTP, can we use the PTP time stamping stuff to get better > time stamps for NTP packets? (without dragging in any/much PTP stuff) NTP can make use of some of the features that PTP hardware supports. NTP will not be able to use PTP support in switches, but your ethernet controller might have PTP support, and NTP can make use of it. Chrony has support for it, and also supports interleaved mode. Combining those 2 can give you very good results. On Linux you can query your hardware capability using ethtool -T. I have 2 hosts that supports hardware timestamps. The first returns: # ethtool -T eth0 Time stamping parameters for eth0: Capabilities: hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) software-system-clock (SOF_TIMESTAMPING_SOFTWARE) hardware-raw-clock(SOF_TIMESTAMPING_RAW_HARDWARE) PTP Hardware Clock: 0 Hardware Transmit Timestamp Modes: off (HWTSTAMP_TX_OFF) on(HWTSTAMP_TX_ON) Hardware Receive Filter Modes: none (HWTSTAMP_FILTER_NONE) all (HWTSTAMP_FILTER_ALL) ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) ptpv1-l4-delay-req(HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) ptpv2-l4-delay-req(HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC) ptpv2-l2-delay-req(HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) ptpv2-sync(HWTSTAMP_FILTER_PTP_V2_SYNC) ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ) The other returns: ethtool -T eno1 Time stamping parameters for eno1: Capabilities: hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) software-system-clock (SOF_TIMESTAMPING_SOFTWARE) hardware-raw-clock(SOF_TIMESTAMPING_RAW_HARDWARE) PTP Hardware Clock: 0 Hardware Transmit Timestamp Modes: off (HWTSTAMP_TX_OFF) on(HWTSTAMP_TX_ON) Hardware Receive Filter Modes: none (HWTSTAMP_FILTER_NONE) all (HWTSTAMP_FILTER_ALL) The difference is which received packets get timestamped. If you want to use hardware timestamping with NTP, the filter support doesn't really matter, there is no NTP filter support in hardware, so you'll end up timestamping all incoming packets. Here is an example of a host that doesn't do hardware timestamping: Time stamping parameters for enp1s0: Capabilities: software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) software-system-clock (SOF_TIMESTAMPING_SOFTWARE) PTP Hardware Clock: none Hardware Transmit Timestamp Modes: none Hardware Receive Filter Modes: none And yet an other: Time stamping parameters for eth0: Capabilities: software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) software-system-clock (SOF_TIMESTAMPING_SOFTWARE) PTP Hardware Clock: none Hardware Transmit Timestamp Modes: none Hardware Receive Filter Modes: none Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: OTC VOTE: Disallow SM2 with a non-SM2 curve
On Tue, Mar 09, 2021 at 10:24:32AM +, Matt Caswell wrote: > topic: In 3.0 it will not be possible to use SM2 with a non-SM2 curve. This >should be documented. +1 Kurt
Bug#985158: gpg: No longer reads .gnupg/options
Package: gpg Version: 2.2.27-1 Severity: important Hi, It seems that the config file ~/.gnupg/options is no longer read, and it's now reading (among others) ~/.gnupg/gpg.conf Jakub Wilk bisected it and pointed to this commit: https://github.com/gpg/gnupg/commit/a028f24136a062f5 It's not the type of change I expect in the 2.2 series. It's also not mentioned anywhere is a changelog or news entry. Kurt
Re: OTC VOTE: Disallow SM2 with a non-SM2 curve
On Wed, Mar 10, 2021 at 05:44:22AM +0200, Nicola Tuveri wrote: > Yes, in 1.1.1j the following is possible: > > - SM2 cryptosystem operations over the "SM2 curve" > - SM2 cryptosystem operations over arbitrary curve (including NIST ones) > - ECDSA/ECDH cryptosystem operations over the "SM2 curve" Is there any reason why we want to support the last 2? > In 3.0, we want to get rid of `EVP_PKEY_set_alias_type()` and make the > "type" of a key object immutable: this will be a breaking change for > applications that were using SM2 in 1.1.1. I assume that's because they got the wrong type when reading a file with that, but it's unclear to me what they should do instead. What I see is: - We'll change the parser so it sets the correct type and there is no need to change the type - Your proposal where you need to export it, and import it again using a different type, making it very complicated to work with SM2. Kurt
[Bug 1899878] Re: Python's test_ssl fails starting from Ubuntu 20.04
2) and 3) would never return 0, which is what the upstream OpenSSL version returns now. 2) would make it return TLS1_VERSION for the minimum and TLS1_3_VERSION for the maximum with default build options. If you enable SSlv3 support at compile time, the minimum would return SSL3_VERSION. Note that there is a TLS_MAX_VERSION define that's equal to TLS1_3_VERSION, but no such define for the minimum. 1) would just return what is set, which is 0 upstream and for Ubuntu for both minimum and maximum, where 0 is defined as no limit set. Debian sets the minimum to TLS1_2_VERSION, and so returns that value. But maybe if no limit is set (and so the value is 0), it can instead return the minimum/maximum version that's supported at compile time. 3) Would have as effect that upstream in 1.1.1 returns TLS1_VERSION and TLS1_3_VERSION, but TLS1_2_VERSION and TLS1_3_VERSION in 3.0. For Ubuntu and Debian it would return TLS1_2_VERSION and TLS1_3_VERISON, since that is what they do using a different method. Setting the default minimum to TLS1_2_VERSION (at compile time) will clearly fix your problem. But I think you're going to run in the same problem with 3.0, and we should probably add a new API in 3.0 for it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1899878 Title: Python's test_ssl fails starting from Ubuntu 20.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 1899878] Re: Python's test_ssl fails starting from Ubuntu 20.04
2) and 3) would never return 0, which is what the upstream OpenSSL version returns now. 2) would make it return TLS1_VERSION for the minimum and TLS1_3_VERSION for the maximum with default build options. If you enable SSlv3 support at compile time, the minimum would return SSL3_VERSION. Note that there is a TLS_MAX_VERSION define that's equal to TLS1_3_VERSION, but no such define for the minimum. 1) would just return what is set, which is 0 upstream and for Ubuntu for both minimum and maximum, where 0 is defined as no limit set. Debian sets the minimum to TLS1_2_VERSION, and so returns that value. But maybe if no limit is set (and so the value is 0), it can instead return the minimum/maximum version that's supported at compile time. 3) Would have as effect that upstream in 1.1.1 returns TLS1_VERSION and TLS1_3_VERSION, but TLS1_2_VERSION and TLS1_3_VERSION in 3.0. For Ubuntu and Debian it would return TLS1_2_VERSION and TLS1_3_VERISON, since that is what they do using a different method. Setting the default minimum to TLS1_2_VERSION (at compile time) will clearly fix your problem. But I think you're going to run in the same problem with 3.0, and we should probably add a new API in 3.0 for it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1899878 Title: Python's test_ssl fails starting from Ubuntu 20.04 Status in openssl package in Ubuntu: Incomplete Bug description: Please take a look at https://bugs.python.org/issue41561. Developers who work on Python think that the issue is due to a change in Ubuntu 20.04 that is best described by https://bugs.python.org/issue41561#msg378089: "It sounds like a Debian/Ubuntu patch is breaking an assumption. Did somebody report the bug with Debian/Ubuntu maintainers of OpenSSL already? Fedora also configures OpenSSL with minimum protocol version of TLS 1.2. The distribution does it in a slightly different way that makes the restriction discoverable and that is compatible with Python's test suite." To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1899878] Re: Python's test_ssl fails starting from Ubuntu 20.04
There are 3 things that can possibly returned by such a function: 1) The value that's set as minimum/maximum 2) The minimum and maximum version that's supported by the library, not depending on settings 3) The minimum and maximum version that's supported by the library, depending on current settings The function now does 1), and you seem to want 3). And I'm not sure it's a good idea to change the function, I would prefer a new function. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1899878 Title: Python's test_ssl fails starting from Ubuntu 20.04 Status in openssl package in Ubuntu: Incomplete Bug description: Please take a look at https://bugs.python.org/issue41561. Developers who work on Python think that the issue is due to a change in Ubuntu 20.04 that is best described by https://bugs.python.org/issue41561#msg378089: "It sounds like a Debian/Ubuntu patch is breaking an assumption. Did somebody report the bug with Debian/Ubuntu maintainers of OpenSSL already? Fedora also configures OpenSSL with minimum protocol version of TLS 1.2. The distribution does it in a slightly different way that makes the restriction discoverable and that is compatible with Python's test suite." To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Bug 1899878] Re: Python's test_ssl fails starting from Ubuntu 20.04
There are 3 things that can possibly returned by such a function: 1) The value that's set as minimum/maximum 2) The minimum and maximum version that's supported by the library, not depending on settings 3) The minimum and maximum version that's supported by the library, depending on current settings The function now does 1), and you seem to want 3). And I'm not sure it's a good idea to change the function, I would prefer a new function. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1899878 Title: Python's test_ssl fails starting from Ubuntu 20.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: OTC VOTE: Disallow SM2 with a non-SM2 curve
On Tue, Mar 09, 2021 at 03:57:32PM +0200, Nicola Tuveri wrote: > It is tangent to the vote in itself, but I'd like to highlight that in part > this vote is motivated by getting rid of cases where there is a need to > convert between compatible key types (e.g. SM2 & EC, DH & DHX). > > The vote of this text does not cover it, but another use case that we will > likely lose in 3.0 when this vote passes is using ECDH/ECDSA over the curve > identified by the SM2 OID. > > It's likely another niche use, not relevant for any production system, but > it is creating a precedent where OpenSSL accepts that the SM2 standard > overrides the SECG standard. > > In 1.1.1 we do _default_ to decode a key serialized as "SECG EC over the > SM2 OID curve" as a SM2 key, but we are not preventing developers from > creating an EC key object over that curve, nor an SM2 key object over any > other curve (serialization of such "weird" key objects would be identical, > deserialization would require an explicit set_alias call to mutate from the > default type). > > With the changes proposed as a corollary to this vote that were discussed > on the last OTC meeting, we would remove this ability: we could maybe still > create an ephemeral "EC over SM2 OID" key object but there would be no way > to deserialize one. > > > I would instead prefer to vote on requiring for 3.0 a mechanism to > "convert" key types: an EVP_PKEY_todata function to mirror > EVP_PKEY_fromdata. > It will be then up to the individual keymgmt of the source key object to > decide if it can be exported to OSSL_PARAMs, and to the receiving keymgmt > on which fromdata is called to determine if the input OSSL_PARAMs are valid > to create a proper key object. > Yes, we would still have a breaking change (set_alias needs to be replaced > by the todata/fromdata dance) but we wouldn't lose functionality. > > Such a mechanism could be useful also beyond the current problem of key > conversions within the builtin providers, and allow future proofing and > interoperability between different providers that might end up using > different names for compatible key types (for whatever reason it might > happen). This text does not seem to help me to make a vote, it seems I just get more questions. The EVP_PKEY_set_alias_type() manpage says that SM2 use the same encoding an ECDSA. I assume that during deserialization we don't know if we should create an ECDSA key or an SM2 key, because we don't look at the OID when deserializing and always create an ECDSA key. My understanding is that there is code that needs to know an SM2 key is stored in that object, and is not looking at the OID, but instead looks at what the pkey type is. My suggested fix for that would be to make the deserialization smarter so it sets the correct pkey type base on the OID. Assuming that we can get an SM2 key, I currently fail to see why ECDSA or ECDH wouldn't work with them, but I know very little about SM2. I also don't understand what the vote is really about. Can 1.1.1 do SM2 on one of the nist curves? Kurt
Re: OTC VOTE: EVP init functions and the provider interface
On Tue, Mar 09, 2021 at 10:25:50AM +, Matt Caswell wrote: > topic: EVP init functions take an OSSL_PARAM array to set parameters and > this >should be reflected in the equivalent provider interface. +1 Kurt
Re: OTC VOTE: EVP init functions and the provider interface
On Tue, Mar 09, 2021 at 10:25:50AM +, Matt Caswell wrote: > topic: EVP init functions take an OSSL_PARAM array to set parameters and > this >should be reflected in the equivalent provider interface. I need more information than the vote text to be able to vote on this. Kurt
Debian Project Leader Elections 2021: Call for nominations
Hi, According to the constitution (5.2. Appointment), project leader elections should begin "six weeks before the leadership post becomes vacant, or (if it is too late already) immediately." The new project leader term starts on 2021-04-21. The time line looks like: | Period | Start | End | |+---+-| | Nomination | Sunday 2021-03-07 | Saturday 2021-03-13 | | Campaign | Sunday 2021-03-14 | Saturday 2021-04-03 | | Vote | Sunday 2021-04-04 | Saturday 2021-04-17 | Prospective leaders should be familiar with the constitution, but just to review: there's a one week period when interested developers can nominate themselves and announce their platform, followed by a three week period intended for campaigning, followed by two weeks for the election itself. I intend to collect platform statements from the candidates, and publish them at http://www.debian.org/vote/2021/platforms/ at the end of the nomination period, which means around 2021-03-14. I suggest that the candidates send the platform, preferably in wml or HTML, to the secretary at least a day before the publication date. The format of the web page is open to discussion, but I suggest there be at least three sections: - Introduction / Biography - Major Goal / Meat of the platform - Rebuttal. The candidates can make a rebuttal. I would like to receive them in the first week of the campaign period, so I can publish them around 2021-03-22. Details and results for the vote will be published at: http://www.debian.org/vote/2021/vote_001 Please make sure that nominations are sent to (or cc:'d to) debian-vote, and are cryptographically signed. Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
[Touch-packages] [Bug 1899878] Re: Python's test_ssl fails starting from Ubuntu 20.04
My understanding of things is that Ubuntu does this: - Set the default security level to 2 (at compile time) - Disable TLS 1.0 and 1.1 at security level 2, only keeping TLS 1.2 by default This is what Debian does: - Set the default security level to 2 (using a config file) - Set the minimum version to TLS 1.2 (using a config file) To be able to use TLS 1.0 on Ubuntu you need to: - Change the security level to 1 To be able to use TLS 1.0 on Debian you need to: - Set the minimum allowed version to TLS 1.0 My understanding of the issue is that python doesn't know which TLS version can be negotiated, and uses or overrides the minimum TLS version which happens to currently work on Debian. But for the test suite it should also override the security level. Note that in upstream OpenSSL 3.0, TLS 1.0 and 1.1 no longer meet the requirements for security level 1, if you want to use TLS 1.0 in the test suite you need to set the security level to 0. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1899878 Title: Python's test_ssl fails starting from Ubuntu 20.04 Status in openssl package in Ubuntu: Incomplete Bug description: Please take a look at https://bugs.python.org/issue41561. Developers who work on Python think that the issue is due to a change in Ubuntu 20.04 that is best described by https://bugs.python.org/issue41561#msg378089: "It sounds like a Debian/Ubuntu patch is breaking an assumption. Did somebody report the bug with Debian/Ubuntu maintainers of OpenSSL already? Fedora also configures OpenSSL with minimum protocol version of TLS 1.2. The distribution does it in a slightly different way that makes the restriction discoverable and that is compatible with Python's test suite." To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Bug 1899878] Re: Python's test_ssl fails starting from Ubuntu 20.04
My understanding of things is that Ubuntu does this: - Set the default security level to 2 (at compile time) - Disable TLS 1.0 and 1.1 at security level 2, only keeping TLS 1.2 by default This is what Debian does: - Set the default security level to 2 (using a config file) - Set the minimum version to TLS 1.2 (using a config file) To be able to use TLS 1.0 on Ubuntu you need to: - Change the security level to 1 To be able to use TLS 1.0 on Debian you need to: - Set the minimum allowed version to TLS 1.0 My understanding of the issue is that python doesn't know which TLS version can be negotiated, and uses or overrides the minimum TLS version which happens to currently work on Debian. But for the test suite it should also override the security level. Note that in upstream OpenSSL 3.0, TLS 1.0 and 1.1 no longer meet the requirements for security level 1, if you want to use TLS 1.0 in the test suite you need to set the security level to 0. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1899878 Title: Python's test_ssl fails starting from Ubuntu 20.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 1899878] Re: Python's test_ssl fails starting from Ubuntu 20.04
I was expecting SSL_CTX_get_min_proto_version() to return the default value (TLS1_2_VERSION). It's currently documented that 0 means the lowest supported by the library. If it returns 0 and the library supports TLS 1.0, it should be able to negotiate TLS 1.0. On reflection, I'm not sure that for the get function 0 is ever a good value to return, it should always return a version. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1899878 Title: Python's test_ssl fails starting from Ubuntu 20.04 Status in openssl package in Ubuntu: Incomplete Bug description: Please take a look at https://bugs.python.org/issue41561. Developers who work on Python think that the issue is due to a change in Ubuntu 20.04 that is best described by https://bugs.python.org/issue41561#msg378089: "It sounds like a Debian/Ubuntu patch is breaking an assumption. Did somebody report the bug with Debian/Ubuntu maintainers of OpenSSL already? Fedora also configures OpenSSL with minimum protocol version of TLS 1.2. The distribution does it in a slightly different way that makes the restriction discoverable and that is compatible with Python's test suite." To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Bug 1899878] Re: Python's test_ssl fails starting from Ubuntu 20.04
I was expecting SSL_CTX_get_min_proto_version() to return the default value (TLS1_2_VERSION). It's currently documented that 0 means the lowest supported by the library. If it returns 0 and the library supports TLS 1.0, it should be able to negotiate TLS 1.0. On reflection, I'm not sure that for the get function 0 is ever a good value to return, it should always return a version. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1899878 Title: Python's test_ssl fails starting from Ubuntu 20.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: OTC VOTE: Change behaviour of EVP_PKEY_get0/EVP_PKEY_get1 functions
On Tue, Mar 02, 2021 at 10:20:30AM +, Matt Caswell wrote: > topic: EVP_PKEY_get0 functions will return a cached copy of the legacy key, > and > will be changed to return const. EVP_PKEY_get1 functions work as per > EVP_PKEY_get0 but are not const returns and up the reference count > Comment: See PR #14319 for background > Proposed by Matt Caswell > Public: yes > opened: 2021-03-02 > closed: 2021-02-02 It closed before it was opened. I'm voting 0. Kurt
Re: Fwd: Requesting to share OpenSSL commands to increase G Pramaeter length in DHE Cipher.
On Wed, Mar 03, 2021 at 04:14:17PM +0530, Vadivel P wrote: > Hi OpenSSL team, > > We are looking for the command line option or any other way to increase the > DHE G Parameter length to 256 bytes, by default it's 2 now, we need to > modify it as 256 byte on the server side for our testing either by command > line or with any other option.we need it for our local server bring up. > Please support us. The default generator is the value 2, not 2 bytes. And if you really need to generate your own DHE keys, using the generator 2 makes perfect sense. Using a larger generator does not add any security, it just makes it slower. But I really suggest that you use standardized parameters like the ones from RFC7919. Note that all the generators in that RFC also use 2 as the generator. OpenSSL has no support for generating safe primes with a 256 byte/2048 bit generator.
Re: [chrony-users] Will it EVER synch and start serving?
On Mon, Mar 01, 2021 at 11:10:41AM -0700, Aaron D. Gifford wrote: > On 3/1/21 11:02 AM, Kurt Roeckx wrote: > > You really should post the output of selectdata. It tells you why > > the peer is not selected. > > Yes, thanks, that is excellent advice > > (I posted just exactly that output earlier in this particular thread.) I still don't see it. I would output something like: chronyc selectdata S Name/IP AddressAuth COpts EOpts Last Score Interval Leap === * excelsior.roeckx.be N - -9 1.0 -8109us +6781us N + 192.168.0.2 N - - 25 1.0 -7452us +7958us N + 192.168.0.7 N - - 24 1.0 -7201us +7177us N + 192.168.0.8 N - -0 1.0 -7531us +7254us N Kurt -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Will it EVER synch and start serving?
You really should post the output of selectdata. It tells you why the peer is not selected. -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Bug#983722: [Pkg-openssl-devel] Bug#983722: libssl1.1: drop upgrade support from old-old-old-stable from maintainer script
On Sun, Feb 28, 2021 at 10:00:35PM +0100, Helmut Grohne wrote: > Hi Kurt, > > On Sun, Feb 28, 2021 at 09:48:04PM +0100, Kurt Roeckx wrote: > > I think you at least misunderstand the purpose of the script, but > > we've also not used it in a very long time. > > I think I do understand the purpose, but it does not presently serve the > stated purpose. Given that the checked version is so ancient, it is > effectively dead code. To activate it, the version in the postinst gets updated. But like I said, it's not been activated in a long time, so maybe it is dead code. > > It's meant to restart all services that make use of openssl when a > > security update is released. I guess I switched to "checkrestart" > > myself, so never had the need to use it myself anymore. > > That or needrestart. I don't think that the general expectation these > days is that upgrading a library restarts affected services. Exceptions > to this rule include nss (libc6) and pam updates as failing to restart > services can result in them becoming dysfunctional. For most other > cases, an external checker is the recommended best practice. I'm not sure users are aware that they need to restart the services (or reboot) to fix the security issues. We still lack a way to indicate that to the user. I would really like to see a general fix for this. > Unless you wish to reactivate this code with a current version, I think > it should be deleted. If you do, please close this bug with a wontfix > tag. I guess you mean "If you don't". Anyway, the template code and translations can all be deleted too if that patch is applied. Kurt
Bug#983722: [Pkg-openssl-devel] Bug#983722: libssl1.1: drop upgrade support from old-old-old-stable from maintainer script
On Sun, Feb 28, 2021 at 09:26:28PM +0100, Helmut Grohne wrote: > Package: libssl1.1 > Version: 1.1.1j-1 > Tags: patch > User: debian-d...@lists.debian.org > Usertags: dpkg-root-support > > The libssl1.1 package ships a maintainer script whose entire purpose is > supporting upgrades from old-old-old-stable. Since Debian does not > support skipping releases, it seems like this code can be safely > dropped. The good thing about dropping it is that code that isn't there > doesn't have to support DPKG_ROOT. Please consider applying the attached > patch. I think you at least misunderstand the purpose of the script, but we've also not used it in a very long time. It's meant to restart all services that make use of openssl when a security update is released. I guess I switched to "checkrestart" myself, so never had the need to use it myself anymore. Kurt
Re: New service: https://debuginfod.debian.net
On Thu, Feb 25, 2021 at 03:55:17PM -0500, Sergio Durigan Junior wrote: > As I said in the announcement message, I have proposed a Merge Request > against elfutils in order to enable the automatic usage of our > debuginfod server. I know that there are people who are not comfortable > with having a debugger consult a remote server "behind their backs", so > a possible mitigation to this issue would be to have a debconf question > asking whether the user wants to enable system-wide debuginfod usage or > not. The other option is that the application asks before downloading each time. Kurt
DPL vote timeline
I'm proposing the following vote timeline: Nomination period: Sunday 2021-03-07 - Saturday 2021-03-13 Campaigning period: Sunday 2021-03-14 - Saturday 2021-04-03 Voting period: Sunday 2021-04-04 - Saturday 2021-04-17 The new term will start on 2021-04-21 Kurt
Re: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely
On Tue, Feb 23, 2021 at 11:21:41AM +0100, Tomas Mraz wrote: > topic: The RSA_SSLV23_PADDING and related functions should be > completely removed from OpenSSL 3.0 code. +1 Kurt
Bug#983013: [Pkg-openssl-devel] Bug#983013: m2crypto: autopkgtest needs update for new version of openssl: M2Crypto.RSA.RSAError: sslv3 rollback attack
forwarded 983013 https://gitlab.com/m2crypto/m2crypto/-/issues/293 thanks I've created an upstream issue for it.
Bug#983013: [Pkg-openssl-devel] Bug#983013: m2crypto: autopkgtest needs update for new version of openssl: M2Crypto.RSA.RSAError: sslv3 rollback attack
forwarded 983013 https://gitlab.com/m2crypto/m2crypto/-/issues/293 thanks I've created an upstream issue for it.
Bug#982645: CVE-2018-3640 on N3160
Package: intel-microcode Version: 3.20201118.1~deb10u1 Hi, spectre-meltdown-checker reports: CVE-2018-3640 aka 'Variant 3a, rogue system register read' * CPU microcode mitigates the vulnerability: NO > STATUS: VULNERABLE (an up-to-date CPU microcode is needed to mitigate this > vulnerability) /proc/cpuinfo says: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 76 model name : Intel(R) Celeron(R) CPU N3160 @ 1.60GHz stepping: 4 microcode : 0x411 cpu MHz : 700.500 cache size : 1024 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 dmesg reports: [0.00] microcode: microcode updated early to revision 0x411, date = 2019-04-23 [...] [2.012058] microcode: sig=0x406c4, pf=0x1, revision=0x411 Can you clarify if a microcode update is missing, just not available or that spectre-meltdown-checker is wrong? Kurt
Bug#959469: buster-pu: package openssl/1.1.1g-1
On Thu, Jan 14, 2021 at 07:03:37PM +0100, Kurt Roeckx wrote: > There are a whole bunch of other issues and pull requests related to > this. I hope this is the end of the regressions in the X509 code. So there is something else now: https://github.com/openssl/openssl/issues/13931 https://github.com/openssl/openssl/pull/13982 Kurt
