> Guys, I must confess I'm completely lost in your discussions. I intend
> to produce another round of 2.1 and 2.0 tomorrow as time permits, so if
> you want me to get anything merged into it, please let me know. Lukas,
> I'll count on you to summarize and suggest what's expected from me to
> do at this point, I guess it will be easier :-)

You can merge the patch I posted today, as there is consensus for this
particular fix:

It should be backported to 2.0 (or even 1.9 - I forgot to mention that
in the commit message).

Further discussion is needed for some remaining points, which I doubt
can be fully clarified for the release tomorrow.

On Fri, 20 Dec 2019 at 19:53, Илья Шипицин <chipits...@gmail.com> wrote:
>> On Wed, 27 Nov 2019 at 07:11, Илья Шипицин <chipits...@gmail.com> wrote:
>> >
>> > -#if (HA_OPENSSL_VERSION_NUMBER >= 0x1010000fL)
>> > +#if (HA_OPENSSL_VERSION_NUMBER >= 0x1010000fL) || 
>> > [...]
>> > -#if defined(USE_THREAD) && (HA_OPENSSL_VERSION_NUMBER < 0x10100000L)
>> > +#if defined(USE_THREAD) && (HA_OPENSSL_VERSION_NUMBER < 0x10100000L) && 
>> > [...]
>> > -#if defined(USE_THREAD) && (HA_OPENSSL_VERSION_NUMBER < 0x10100000L)
>> > +#if defined(USE_THREAD) && (HA_OPENSSL_VERSION_NUMBER < 0x10100000L) && 
>> > [...]
>> I'm confused. This is not required in my environment for the build to
>> succeed and I don't see any reason why HA_OPENSSL_VERSION_NUMBER would
>> be smaller here? Can you elaborate why the HA_OPENSSL_VERSION_NUMBER
>> comparison would fail to do its job in those comparisons?
> what is the lowest openssl we support ?
> those callbacks are required if threads are used for non-deprecated builds 
> and for early openssl versions like 1.0.0

Are you saying this is for openssl 1.0.2 with no-deprecated, is that
what fails without this? I have troubles understanding what it is
*exactly* that requires this change.

If your question is, which openssl releases should we support with
no-deprecated, I'd say 1.1.0 and newer. I don't believe there is any
reason to support openssl 1.0.2 with no-deprecated. Sure we support
old releases. But I would not waste any time/changes and especially
complexity on adding support for "no-deprecated" feature for obsolete
openssl releases (1.0.2 is EOL in a few days, nobody turns on
no-deprecated on 1.0.2 now).

What I am saying is that this change is not needed in my environment
for the build to succeed, which is against openssl 1.1.1d with
no-deprecated option. Maybe there is something that I don't see from
my build machine here, that's why I need more information.

If you see a build failure after the SSL_CTX_set_ecdh_auto() fix on
top of current master, please elaborate how that build failure looks
like and how openssl was compiled.


Reply via email to