Re: [External] Fork DBD::mysql

[Dan Book]

On Tue, Aug 29, 2017 at 3:36 AM,  wrote:

> Then users of MySQL would stay with DBD::mysql and they would not have
> fixed DBD driver. We were thinking about choosing DBD::mariadb name
> for our fork. But without dropping MySQL support, so also MySQL users
> could benefit from it.
>
> On Monday 28 August 2017 18:08:20 Daniël van Eeden wrote:
> > What about splitting it in DBD::mysql and DBD::mariadb ?
> >
> >
> > On 28 August 2017 5:55:09 p.m. 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?
> > >
>

My reply yesterday seems to not have gone through, so I am replying again
here.

Though the reversion was made with good intentions of preserving back
compat in the short term, it was accompanied by a promise of reapplying the
many important fixes that were reverted (
https://github.com/perl5-dbi/DBD-mysql/compare/4.041...4.042 ) as well as
re-adding a correct utf8 encoding option, as it is still necessary to fix
this broken behavior one way or another. Since nothing has happened,
forking may be the only reasonable option. We are currently version pinned
to 4.042 as "upgrading" to 4.043 would be a massive regression in our
codebase.

-Dan

Re: [External] Fork DBD::mysql

[pali]

Then users of MySQL would stay with DBD::mysql and they would not have
fixed DBD driver. We were thinking about choosing DBD::mariadb name
for our fork. But without dropping MySQL support, so also MySQL users
could benefit from it.

On Monday 28 August 2017 18:08:20 Daniël van Eeden wrote:
> What about splitting it in DBD::mysql and DBD::mariadb ?
> 
> 
> On 28 August 2017 5:55:09 p.m. 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?
> >