Re: Fork DBD::mysql

2017-09-01 Thread Patrick M. Galbraith 

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?

Re: Fork DBD::mysql

2017-09-01 Thread pali 
On Friday 01 September 2017 13:36:13 H.Merijn Brand wrote:
> On Fri, 1 Sep 2017 13:08:17 +0200, p...@cpan.org wrote:
> 
> > On Tuesday 29 August 2017 22:08:09 Dan Book wrote:
> > > 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  
> > 
> > Ok, I understood Dan's email as there are already users who cannot
> > upgrade to the last DBD::mysql version (where revert happened) as it
> > contains bugs...
> > 
> > And due to big silent, I would say that DBD::mysql is really dead.
> 
> I doubt that. Maybe the active maintainer is on holiday. It is the
> season you know.
> 
> June is indeed a few months ago, but it was still this year. NOT dead.
> Please try to contact Michiel first.

I already did it and also I CCed him in my first email in this thread.

> Author: Michiel Beijen   2017-06-29 11:25:48
> Committer: Michiel Beijen   2017-06-29 11:30:07
> Tags: 4.043
> Parent: 1ece6b4b8630a1cf348373aa41cbe5f748dcd62a (Merge pull request #137 
> from pali/versions)
> Branch: remotes/origin/master
> Follows: 4.042
> Precedes: 
> 
> New version 4.043 - the same as 4.041

Re: Fork DBD::mysql

2017-09-01 Thread H.Merijn Brand 
On Fri, 1 Sep 2017 13:08:17 +0200, p...@cpan.org wrote:

> On Tuesday 29 August 2017 22:08:09 Dan Book wrote:
> > 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  
> 
> Ok, I understood Dan's email as there are already users who cannot
> upgrade to the last DBD::mysql version (where revert happened) as it
> contains bugs...
> 
> And due to big silent, I would say that DBD::mysql is really dead.

I doubt that. Maybe the active maintainer is on holiday. It is the
season you know.

June is indeed a few months ago, but it was still this year. NOT dead.
Please try to contact Michiel first.

Author: Michiel Beijen   2017-06-29 11:25:48
Committer: Michiel Beijen   2017-06-29 11:30:07
Tags: 4.043
Parent: 1ece6b4b8630a1cf348373aa41cbe5f748dcd62a (Merge pull request #137 from 
pali/versions)
Branch: remotes/origin/master
Follows: 4.042
Precedes: 

New version 4.043 - the same as 4.041

-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.27   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/


pgpRKXC3u_LpT.pgp
Description: OpenPGP digital signature

Re: Fork DBD::mysql

2017-09-01 Thread pali 
On Tuesday 29 August 2017 22:08:09 Dan Book wrote:
> 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

Ok, I understood Dan's email as there are already users who cannot
upgrade to the last DBD::mysql version (where revert happened) as it
contains bugs...

And due to big silent, I would say that DBD::mysql is really dead.