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, p...@cpan.org 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?
