On Friday 10 November 2017 10:09:59 demerphq wrote: > Pali is there a concise summary of what we are arguing about here?
Short summary: 1. There are applications which misuse perl and DBD::mysql internals to pass blob or utf-8 text data from perl to MySQL database. We were not aware of them for a longer testing period of time as nobody complained until version 4.042 of DBD::mysql was released. There were trial releases, blog posts, asking testers for test, etc... 2. Unicode support in DBD::mysql is broken and cause data corruption. There are lot of reported bugs about it, e.g.: https://rt.cpan.org/Public/Bug/Display.html?id=25590 https://rt.cpan.org/Public/Bug/Display.html?id=53130 https://rt.cpan.org/Public/Bug/Display.html?id=60987 https://rt.cpan.org/Public/Bug/Display.html?id=87428 https://rt.cpan.org/Public/Bug/Display.html?id=119079 https://rt.cpan.org/Public/Bug/Display.html?id=120141 All those problems were fixed, but breaking applications which misuse internals. Basically Unicode support is opposite of the above. All fixes from 4.042 were reverted and version 4.043 was released. 3. DBD::mysql itself misuse libmysqlclient internals for a long time and now when MariaDB changed something, it cannot be used with DBD::mysql anymore. 4. Due to how Oracle (not) reacted and (not) fixed problems related to SSL, DBD::mysql has a security problems when SSL encryption is used. There are also other crashing problems in DBD::mysql. 5. Misusing internals of 3rd applications which use DBD::mysql is a problem because basically any change of low level parts in DBD::mysql can lead to breakage of those 3rd applications. And because nobody was able to detect it would break something there is a really big chance that bigger changes in DBD::mysql break something again. Fixing 3. is expected to be big change.
