Re: Fork DBD::mysql

Hi Pali,

I would very much like to address these issues and fix the UTF issue you 
so kindly had a patch for that people had problems with and do so in a 
way that doesn't require forking. I'm very sorry about this as I was in 
between jobs and distracted but am free next week to discuss this. I am 
also talking to my former Mysql colleagues at Oracle and MariaDB 
(Reggie, Matt, Georg) about moving this forward and get the driver MySQL 
8 compatible. I would like to have a discussion to make this happen. How 
would you-- and everyone interested in this list-- like to work with me 
and others to solve this issue?

Kind regards,

Patrick

On 8/28/17 11:55 AM, [email protected] wrote:
> Hello, 2 months passed since two security problems related to DBD::mysql
> were reported, namely CVE-2017-10789 and CVE-2017-10788. Looking at the
> DBD::mysql github project page and RT bugtracker, it can be seen that
> nothing has happened for 2 months. Some people are asking or waiting for
> reported problems to be fixed... Without an answer.
>
> A long discussion was started in April by a group of people who didn't
> like the improvements and didn't want to see the bugs fixed in
> DBD::mysql driver due to the fact that they probably had old and buggy
> legacy code which wouldn't work after DBD::mysql starts fixing bugs.
>
>  From what happened it looks like that this group of people forced
> DBD::mysql maintainers to revert all DBD::mysql changes (with all bug
> fixes including security ones). And because nothing has happened for 2
> months, that looks like fixing those bugs is not planned.
>
> This means just one thing:
>
>    DBD::mysql is dead right now :-(
>
> There are no new commit for 2 months, no evidence of any activity. And
> it looks like this is what that group of people wanted. They haven't
> written anything, neither any comment about open security issues, nor
> any comment that they forced maintainers to revert a security related
> bug fix. Probably they don't have to fix their own code and they can use
> the last released version of DBD::mysql. Perfect for them, probably a
> catastrophe for all others which don't want to use probably-vulnerable
> code.
>
> But it also means that it isn't possible to compile the last DBD::mysql
> with the new MySQL 8 or new MariaDB versions. More linux distributions
> started to pack/bundle their own DBD::mysql patches just because they
> need to build DBD::mysql into their repositories with upgraded MariaDB.
>
> I need to say that such situation is not acceptable for *any* future or
> new development in Perl which uses either MySQL or MariaDB database.
>
> DBD::mysql has couple of bugs (some are security released) and fully
> non-working UTF-8/Unicode support. It means that any internationalized
> applications which use MySQL are hard to write in Perl.
>
> Because of the current situation we in the GoodData company are thinking
> about forking DBD::mysql. We use DBI not only with DBD::mysql, but also
> with DBD::Pg. The annoying bugs in DBD::mysql still require hacks and
> workarounds, while similar bugs were fixed in DBD::Pg years ago. Also,
> inability to use the new version of MySQL or MariaDB is a problem. Same
> for the open security issues.
>
> I would like to ask, whether somebody else is interested in DBD::mysql
> fork? Either as a user or as a developer? Maintaining a fork isn't a
> simple task, but with supporting users and contributing developers it
> should be easier.
>
> And specially, are MariaDB developers interested in fixing/improving
> DBD::mysql fork, so Perl could work better with MariaDB servers? At
> least it would be able to compile against the new MariaDB C-client?