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@mariadb.org