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 secur...@mariadb.org _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
