On Thu, Mar 26, 2020 at 11:33:40PM +, Matt Caswell wrote:
> On 26/03/2020 23:15, Viktor Dukhovni wrote:
> > On Thu, Mar 26, 2020 at 09:13:32PM +0100, Bernd Edlinger wrote:
> >
> >> we got into this situation because everything moves so quickly,
> >> why does everyone here think we should move
On 26/03/2020 23:15, Viktor Dukhovni wrote:
> On Thu, Mar 26, 2020 at 09:13:32PM +0100, Bernd Edlinger wrote:
>
>> we got into this situation because everything moves so quickly,
>> why does everyone here think we should move even faster now?
>>
>> What is the reason for this?
>
> We've publis
On 26/03/2020 20:13, Bernd Edlinger wrote:
>
>
> On 3/26/20 9:10 PM, Tim Hudson wrote:
>> We don't guarantee constant time.
>>
>
> #11411 does, I don't see why we hurry so much for 1.1.1f
>
> we got into this situation because everything moves so quickly,
We waited 6 months to release 1.1.1
On Thu, Mar 26, 2020 at 09:13:32PM +0100, Bernd Edlinger wrote:
> we got into this situation because everything moves so quickly,
> why does everyone here think we should move even faster now?
>
> What is the reason for this?
We've published a bug-fix release (1.1.1e) that's liable to cause more
On 3/26/20 9:10 PM, Tim Hudson wrote:
> We don't guarantee constant time.
>
#11411 does, I don't see why we hurry so much for 1.1.1f
we got into this situation because everything moves so quickly,
why does everyone here think we should move even faster now?
What is the reason for this?
Bern
We don't guarantee constant time.
Tim.
On Fri, 27 Mar 2020, 5:41 am Bernd Edlinger,
wrote:
> So I disagree, it is a bug when it is not constant time.
>
>
> On 3/26/20 8:26 PM, Tim Hudson wrote:
> > +1 for a release - and soon - and without bundling any more changes. The
> > circumstances justif
So I disagree, it is a bug when it is not constant time.
On 3/26/20 8:26 PM, Tim Hudson wrote:
> +1 for a release - and soon - and without bundling any more changes. The
> circumstances justify getting this fix out. But I also think we need to
> keep improvements that aren't bug fixes out of stab
+1 for a release - and soon - and without bundling any more changes. The
circumstances justify getting this fix out. But I also think we need to
keep improvements that aren't bug fixes out of stable branches.
Tim.
On Fri, 27 Mar 2020, 3:12 am Matt Caswell, wrote:
> On 26/03/2020 15:14, Short, T
On 26/03/2020 15:14, Short, Todd wrote:
> This type of API-braking change should be reserved for something like
> 3.0, not a patch release.
>
> Despite it being a "incorrect", it is expected behavior.
>
Right - but the question now is not whether we should revert it (it has
been reverted) - but
This type of API-braking change should be reserved for something like 3.0, not
a patch release.
Despite it being a "incorrect", it is expected behavior.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet."
> On Mar 26, 2020, at 11:03 AM, Dr. Matthias
Hi Ben,
Yes, a reply after a few weeks is still very useful, thanks!
You are right about the point that every library has an "expired" code,
though I start to see other differences. The number of errors itself wildly
differ – OpenSSL has over 75 of certificate-related errors, while GnuTLS
has onl
On 3/26/20 3:14 PM, Matt Caswell wrote:
> The EOF issue (https://github.com/openssl/openssl/issues/11378) has
> resulted in us reverting the original EOF change in the 1.1.1 branch
> (https://github.com/openssl/openssl/pull/11400).
>
> Given that this seems to have broken quite a bit of stuff, I p
> Please also consider reverting the change for the 3.0 alpha release as well,
> see Daniel Stenbergs comment
> https://github.com/openssl/openssl/issues/11378#issuecomment-603730581
Never mind my last comment. I noticed a lot of discussion has been going on in
issue #11378 and I was not
quite u
I agree, go ahead.
Please also consider reverting the change for the 3.0 alpha release as well,
see Daniel Stenbergs comment
https://github.com/openssl/openssl/issues/11378#issuecomment-603730581
Matthias
From: openssl-project On Behalf Of Dmitry
Belyavsky
Sent: Thursday, March 26, 2020 3:48
On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell wrote:
> The EOF issue (https://github.com/openssl/openssl/issues/11378) has
> resulted in us reverting the original EOF change in the 1.1.1 branch
> (https://github.com/openssl/openssl/pull/11400).
>
> Given that this seems to have broken quite a bit
On Thu, 2020-03-26 at 14:14 +, Matt Caswell wrote:
> The EOF issue (https://github.com/openssl/openssl/issues/11378) has
> resulted in us reverting the original EOF change in the 1.1.1 branch
> (https://github.com/openssl/openssl/pull/11400).
>
> Given that this seems to have broken quite a bi
On 3/26/20 3:14 PM, Matt Caswell wrote:
> The EOF issue (https://github.com/openssl/openssl/issues/11378) has
> resulted in us reverting the original EOF change in the 1.1.1 branch
> (https://github.com/openssl/openssl/pull/11400).
>
> Given that this seems to have broken quite a bit of stuff,
The EOF issue (https://github.com/openssl/openssl/issues/11378) has
resulted in us reverting the original EOF change in the 1.1.1 branch
(https://github.com/openssl/openssl/pull/11400).
Given that this seems to have broken quite a bit of stuff, I propose
that we do a 1.1.1f soon (possibly next Tue
On Wed, Mar 25, 2020 at 10:21:36PM -0700, Benjamin Kaduk wrote:
> I tihnk it's an interesting idea. To me, perhaps the most valuable part
> would be to accumulate a corpus of certificates/chains that are malformed
> or fail to validate due to a wide variety of errors, almost akin to a
> fuzzing co
19 matches
Mail list logo