maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Vladislav!

On Nov 21, Vladislav Vaintroub wrote:
>> H Serg,
>> >> I read in openssl/NEWS.md at master · openssl/openssl
>> >> (github.com)  that “SSL 3, TLS 1.0, TLS 1.1, and DTLS 1.0 only
>> >> work at security level 0”
>> >this means the documentation is wrong?
> 
>> This means exactly that. I changed th comment like you suggested.
> 
>> >I think the "former" (or, rather existing, conventional) approach is
>> >easier to use - assume all CMAKE_REQUIRED_* variables are empty, set
> 
>> I’m not doing to dive into discussion here, so I changed it the way
>> you like more, especially since this makes the patch even smaller
> 
>> >It's not that exciting a task to do it many times, I think. Might be
>> >better just to do it once, and be done with it. A good argument not
>> >to do it (that is, to do it in two steps) could be, that new API
>> >that one has to use in 3.0 is incompatible with 1.1, so we'd need to
>> >double the number of #ifdef's If this is the case then, indeed,
>> >better to wait, say, 5 years, as you suggest, for OpenSSL 1.x to
>> >reach EOL
> 
>> A good argument is not to change something if it is not broken, and
>> also keep the patch sizes to minimum, which I think happened here.
> 
>> This patch is hopefully applicable back to 10.2 . I do not think we’d
>> have a zero porting work for any new version of OpenSSL, since they
>> like to change API to the new API-du-jour.

That's true. 1.0->1.1 wasn't exactly trivial.

>> But, a good argument to change anything is to remove the ifdefs. I
>> think it would be possible for 10.4+, in case WolfSSL’s OpenSSL
>> compatibility is good enough. I think ideally, it would be done when
>> 10.3 is no more supported, so that YASSL , at least is no more
>> concern. By that time, OpenSSL 1.0 might no be supported either.

Okay. I don't have a strong opinion about it.
Let's use your minimal approach, as long as it works.

Which, I guess, means practically, as long as no major distro ships
openssl 3.0 with compatibility API disabled.

>> I also think too much time is spend on discussing SHAx hashing here,
>> it is a relatively small thing, after all.

I don't understand what you mean, I didn't touch SHAx topic at all.

>> >I think we should rather deprecate DES_ENCRYPT and DES_DECRYPT
>> >functions. It should've been done long time ago.
> 
>> Ok, but there is also a deprecation procedure for us. We can’t remove
>> those functions right now, and DES_XXX would be in deprecated mode
>> for a while until they would be removed, in a couple of years.

MDEV-27104

Regards,
Sergei
VP of MariaDB Server Engineering
and security@xxxxxxxxxxx