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
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
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
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
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
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
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
On Tue, Apr 20, 2021 at 12:17:17PM +0200, Tomas Mraz wrote:
> topic: Set PR 13817 milestone to Post 3.0
0
Kurt
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
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
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
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
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
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
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
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
|455 | 89 | 44.695 | 9.50706 |
|--+--++---++-++---|
Kurt Roeckx
Debian Project Secretary
signature.asc
Description: PGP signature
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
|455 | 89 | 44.695 | 9.50706 |
|--+--++---++-++---|
Kurt Roeckx
Debian Project Secretary
signature.asc
Description: PGP signature
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
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
>
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
>
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.
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
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
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
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.
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
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 *
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
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
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)
>
>
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
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
The option has been committed to the website, it should appear
soon.
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,
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
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
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
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
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
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 discu
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
> earli
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
> > >
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
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 auth
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
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 addi
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. T
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
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
The option is now on the website.
Kurt
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 discour
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
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,
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
This option is now also on the website.
Kurt
This option is now also on the website.
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
On Mon, Mar 29, 2021 at 05:42:23PM +0300, Apollon Oikonomopoulos wrote:
>
> Seconded, thank you Santiago!
Your message was not signed.
Kurt
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:
> >&g
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
>
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
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
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
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
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
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
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
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
> >
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
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.
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
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
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"
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
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 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
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
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
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
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
round 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
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
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
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
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
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:
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
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
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
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
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
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
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
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
forwarded 983013 https://gitlab.com/m2crypto/m2crypto/-/issues/293
thanks
I've created an upstream issue for it.
forwarded 983013 https://gitlab.com/m2crypto/m2crypto/-/issues/293
thanks
I've created an upstream issue for it.
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
>
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
301 - 400 of 14770 matches
Mail list logo