DBD::mysql 4.047 Released
Dear Community, I'm pleased to announce the release of DBD::mysql 4.047! This release has the following changes (Thanks to Daniël van Eeden from Booking.com!) * Add options needed for public key based security. * Allow several spaces after LIMIT clause. * Basic GTID tracking. * Fix GCC 8.1 warnings * Fix warning: unused variable ‘buffer_len’ * Fix warning about bind->is_null assignment with incompatible pointer type * Get rid of warning about unused variable ssl_verify_set * Fix space/tab issue which leads to misleading indentation * Change spaces/tabs to get rid of GCC8 warning The github repo can be found here: https://github.com/perl5-dbi/DBD-mysql CPAN: https://metacpan.org/pod/DBD::mysql Thank you for using DBD::mysql! Regards, Patrick -- Patrick M. Galbraith http://patg.net p...@patg.net
Re: DBD::mysql 4.046 released
Yes, I will look at this later today. On 2/9/18 5:34 AM, H.Merijn Brand wrote: On Fri, 9 Feb 2018 05:20:25 -0500, "Patrick M. Galbraith" <p...@patg.net> wrote: Greetings! I'm pleased to announce the release of DBD::mysql 4.046: * Use API function for reconnect; fixes compilation on MariaDB 10.2.6+. Fix provided by Pali. * Fixed broken link to MySQL download page, provided by Mohammad S Anwar. * Spelling fixes, provided by Ville Skyttä. Could you please also address issue #232 https://github.com/perl5-dbi/DBD-mysql/issues/232 As DBD::mysql won't build at all on the affected systems Happy to help with questions you might have Many thanks to the Pali Rohár, Ville Skyttä, Michiel Beijen, and of course the community! -- -- Patrick M. Galbraith Principal Platform Engineer, Oracle + Dyn http://patg.net p...@patg.net patrick.m.galbra...@oracle.com
DBD::mysql 4.046 released
Greetings! I'm pleased to announce the release of DBD::mysql 4.046: * Use API function for reconnect; fixes compilation on MariaDB 10.2.6+. Fix provided by Pali. * Fixed broken link to MySQL download page, provided by Mohammad S Anwar. * Spelling fixes, provided by Ville Skyttä. Many thanks to the Pali Rohár, Ville Skyttä, Michiel Beijen, and of course the community! Have a great day! -- Patrick M. Galbraith Principal Platform Engineer, Oracle + Dyn http://patg.net p...@patg.net patrick.m.galbra...@oracle.com
DBD::mysql 4.044 released!
Dear Perl and MySQL community, I'm quite pleased to announce the release of DBD::mysql 4.044! This release in particular contains a re-application of an earlier SSL fix that was needed when we reverted a release last year. Per the Changelog: --- Reapply https://github.com/perl5-dbi/DBD-mysql/pull/114 "Improve SSL settings, reflect changes for BACKRONYM and Riddle vulnerabilities, enforce SSL encryption when mysql_ssl=1 is set" Thank you to Pali Rohar, Daniël van Eeden, Booking.com, et al:w * Fix parsing configure libs from mysql_config --libs output in Makefile.PL Libraries in mysql_config --libs output can be specified by library name with the -l prefix or by absolute path to library name without any prefix. Parameters must start with a hyphen, so treat all options without leading hyphen in mysql_config --libs output as libraries with full path. Partially fixes bug https://rt.cpan.org/Public/Bug/Display.html?id=100898 Fix by Pali Rohár. * Return INTs with ZEROFILL as strings. Reported by Knarf, fix by Pali Rohár. https://rt.cpan.org/Public/Bug/Display.html?id=118977 * Correct require on relative path for perl 5.26. Fix by Grinnz. https://github.com/perl5-dbi/DBD-mysql/pull/136 This release has been made possible with the excellent work of Pali Rohár, Daniël van Eeden (http://booking.com), Knarf, Grinnz, and my co-maintainer, Michiel Beijen. Also, thanks for Reggie Burnett (who recently set up a slack room for mysql), Matt Lord, Georg Richter, Paul Dubois, and other former MySQL colleagues who have been helpful in establishing communications about things that need to get done in the driver! I'm particularly please that this release also coincides with my 50th birthday! I have been maintaining DBD::mysql since 2004 now, and look forward to future releases containing further improvements as discussed on the mailing lists and supporting new features in both MySQL and MariaDB. Thank you! Patrick -- Patrick M. Galbraith Principal Platform Engineer, Oracle + Dyn http://patg.net p...@patg.net patrick.m.galbra...@oracle.com
Re: DBD::mysql next steps
Me too! I look forward to getting pull requests reviewed and in the driver as well as get your UTF-8 work in per my previous email. We can use all the help we can get. regards, Patrick On 11/11/17 3:53 AM, p...@cpan.org wrote: On Friday 10 November 2017 10:13:55 Patrick M. Galbraith wrote: Greetings all! Michiel and I have been talking, weighing options of what course to take in dealing with moving forward-- with the goal of both offering both stability and the choice to have the latest functionality and bug fixes as well as give contributors the opportunity to be part of overall improvements to the driver. What we are going to do is: Add to the connection the ability to turn on proper UTF handling with 'mysql_enable_proper_unicode'. This gives the user volition the option to knowingly toggle whether they want the new functionality and understand that data structures returned or accepted by the driver might be different than without this setting. The other options had their merits, but we think this will solve the issue while keeping the driver unified and prevent divergence. Thank you for your input over the last couple months-- we look forward to moving ahead! Patrick and Michiel Great! Thank you very much, I'm waiting for a new action which would bring DBD::mysql back to the active development.
DBD::mysql next steps
Greetings all! Michiel and I have been talking, weighing options of what course to take in dealing with moving forward-- with the goal of both offering both stability and the choice to have the latest functionality and bug fixes as well as give contributors the opportunity to be part of overall improvements to the driver. What we are going to do is: Add to the connection the ability to turn on proper UTF handling with 'mysql_enable_proper_unicode'. This gives the user volition the option to knowingly toggle whether they want the new functionality and understand that data structures returned or accepted by the driver might be different than without this setting. The other options had their merits, but we think this will solve the issue while keeping the driver unified and prevent divergence. Thank you for your input over the last couple months-- we look forward to moving ahead! Patrick and Michiel
Re: DBD::mysql path forward
Darren, Thank you. Yes, you are correct about prior discussions. How do we handle releases of having a DBD::mysql and a DBD::mysql2, in terms of people knowing "this is the old branch with no possibly breaking changes" vs. "this is the new branch" ? It's been pretty simple for the 14 years I've been working on DBD::mysql, my main concern being, how do the various distributions handle this sort of thing? I suppose deal with each OS distributor on a case-by-case basis. Michiel and Pali too - what do you think of what Darren is saying? My main concerns in all of these discussions are: 1. No fragmentation 2. Stability per Night Light's previous email 3. Choice for users to decide which driver to use 4. Single project under one roof 5. Contributors who work hard on this driver get credit Let's do this ! :) Regards, Patrick On 11/7/17 4:19 PM, Darren Duncan wrote: Patrick and Pali, each of you please respond to the lists to confirm that what I say below is what you also understand is the primary plan, and if not, then say why not; in prior discussion I recall you agreed with it. Assuming they agree, the concerns of Night Light and those he is speaking for should be handily satisfied. The whole discussion on the mailing lists that I recall and participated in seemed to consensus on branching DBD::sqlite in order to best satisfy the needs of all stakeholders. There would be one version control with 2 active release branches. A maintenance branch would exist starting from the 4.041/3 release on which further stable releases named DBD::mysql 4.x would be made, and the primary goal of this branch is to not break/corrupt anything that relied on 4.041 behavior. So people with legacy projects that just use DBD::mysql and made particular assumptions on its handling of Unicode or Blobs etc won't have corruption introduced because DBD::mysql changed its handling of those things. People without knowledge of CPAN or the development process will get something that just continues to work for them and doesn't corrupt. For all intents and purposes this branch would be frozen but could have select security or bug fixes that comply with the mandate and don't involve changing Unicode etc. The master branch would then have all the short term breaking changes including the 4.042 Unicode fixes and would have all the significant feature changes including compatibility with newer MySQL major versions. All of its releases would be under a new namespace such as DBD::mysql2 and start at version 5.0 to signify that large changes happened which might possibly break code or cause corruption if user code doesn't specifically account for the differences. Being a different name this is strictly opt-in, so the only ones using DBD::mysql2 are those that explicitly opted in to it, and by doing so they also opted in to fixing anything with their code that needed fixing to not corrupt data while using it. The concept of having a single driver with toggled behavior eg a mysql_enable_proper_unicode flag was already rejected as unwieldy to implement, especially for such deep rooted changes as properly handling Unicode. Note that I expect that most other higher-level projects that use MySQL would NOT branch like this, instead having internal logic or their own toggle to work with DBD::mysql vs DBD::mysql2, or a few may branch, but the key thing is that branching DBD::mysql does NOT necessitate doing so in the rest of the ecosystem. -- Darren Duncan On 2017-11-07 12:07 PM, Night Light wrote: Proposed, but no made decisions posted afterwards. The last proposal is to re-commit the rejected 4.042 changes into the 4.043 master branch and only work on fixes that came after June. The git issue that regards improperly encoding of BLOBs is opened on April 6th (hence me sending the message to prevent a recurring cycle). https://github.com/perl5-dbi/DBD-mysql/issues/117 On Tue, Nov 7, 2017 at 8:57 PM, Michiel Beijen wrote: To me, the only real option is to make a new option in DBD::mysql; mysql_enable_proper_unicode or the like which you would knowingly set in your application code, which will expose the new behaviour. I understand this is difficult, but I really think it's the only way. If in the short term this is not feasible, it *could* be possible, in my eyes, to release a DBD::mysql2 or similar that does *correct* behaviour. Also in that case this is something the application developer should set explicitly in his connection string. This DBD::mysql2 or similar could live in another git repository, but preferably in the same repo, and even in the same CPAN distribution as DBD::mysql, and eventually the goal should be that they re-unite and using DBD::mysql2 would really be the same as to use the 'mysql_enable_proper_unicode' option in DBD::mysql. -- Michiel On Tue, Nov 7, 2017 at 7:41 PM, Darren
Re: DBD::mysql path forward
Pali, I have given you co-maintainership to DBD::mysql and permissions on the repo - let's go ahead and move forward. Thank you, Patrick On 11/3/17 11:17 AM, Patrick M. Galbraith wrote: Pali, Sorry, I wanted to give it time for people, plus have been very busy. I'm ready, just let me know when we can get code merged back in-- what do you need me to do? I will need help with this. Regards, Patrick On 11/2/17 1:43 PM, p...@cpan.org wrote: On Tuesday 12 September 2017 11:40:31 Patrick M. Galbraith wrote: Hi all, After talking to Pali and looking at how other drivers have handled the issue, the best way forward will be to deal with solving the UTF-8 issue correctly as was attempted in May. This will be a problem for some, but only due to having to been accustomed to a work-around that relies on a intermittent and buggy implementation. The plan is to give ample time to let people prepare and comment as well as give them a chance to try the changes and adjust prior to stable release. I'm going to look through the mailing list and find particularly those who had problems back in May and June when we tried this before and work with them in advance of the change. DBD::mysql should be on par with all the other DBD drivers and allow transparent usage regardless of backing RDBMS, and this really is the only way. It will also allow for other fixes to proceed and the driver to continue improving and supporting all versions and enhancements of MySQL and MariaDB. Please do give us your thoughts on this as we want to be as helpful and transparent as possible. Thank you! Patrick Hi! Nearly another two months passed and there is no progress in unblocking development. Currently more people started reporting problems that new versions of both MySQL and MariaDB cannot be used for building DBD::mysql. As I stated two months ago, we are thinking about forking DBD::mysql as inability to build DBD::mysql with new version of MySQL or MariaDB is a real problem which needs to be fixed ASAP -- and not waiting another 6 months.
Re: DBD::mysql path forward
Pali, Great! Now we can start moving forward. Sorry if my responses have been intermittent - first week at new job. Regards, Patrick On 9/16/17 4:35 AM, p...@cpan.org wrote: On Friday 15 September 2017 04:06:57 Patrick M. Galbraith wrote: On 9/13/17 9:31 AM, p...@cpan.org wrote: On Tuesday 12 September 2017 11:32:36 Darren Duncan wrote: On 2017-09-12 11:05 AM, p...@cpan.org wrote: On Tuesday 12 September 2017 19:00:59 Darren Duncan wrote: I strongly recommend that another thing happen, which is re-versioning DBD::mysql to 5.0. 1. From now on, DBD::mysql versions 4.x would essentially be frozen at 4.041/4.043. 2. From now on, DBD::mysql versions 5.x and above would be where all active development occurs, would be the only place where Unicode handling is fixed and new MySQL versions and features are supported, and where other features are added. I'm fine with it. Basically it means reverting to pre-4.043 code and continue *git* development there with increased version to 5.x. And once code is ready it can be released to cpan as normal (non-engineering) 5.x release. Yes, as you say. With respect to Git I propose doing this immediately: 1. Create a Git tag/branch off of 4.043 which is the 4.x legacy support branch. This is up to Patrick. I agree that we can start there. I do like the discussion going on now and want to engage all those concerned and interested and have a plan. 2. Revert Git master to the pre-4.043 code and then follow that with a commit to master that changes the DBD::mysql version to 5.0. If everybody agree with this step, I can prepare pull request which revert tree to this state, plus re-apply/rebase commits which were newly accepted. I prepared branch master-new, which is based on current DBD-mysql master branch and revert state to pre-4.043 version, including all changes done after 4.043 release to master branch. I have this master-new branch in my fork. If you want you can use it... https://github.com/pali/DBD-mysql/tree/master-new Regardless, following point 2, mandate that all Git pull requests are made against the new 5.x master; the 4.x legacy branch would have no commits except minimal back-porting. New pull requests are by default created against "master" branch. So if 5.x development would happen in "master" and 4.x in e.g. "legacy-4.0" then no changes is needed. But on github it is not possible to disallow users to create new pull requests for non-default branch. When creating pull request there is a button which open dialog to change target branch.
Re: DBD::mysql path forward
Hi Paul! (long time!) we need to make sure we have these cases accounted for and test coverage. regards, Patrick On 9/14/17 9:24 PM, Paul DuBois wrote: On Sep 14, 2017, at 1:44 AM, p...@cpan.org wrote: MySQL server and its databases has some limitations, so reflect it: * it does not provide information if placeholder is TEXT, VARCHAR, VARBINARY or BLOB * placeholder's bind value does not have to point to column, it can be also SQL function --> for caller/user all placeholders are equivalent and caller itself needs to know how to treat bind variable and needs to specify if it is TEXT or BLOB * VARBINARY is right padded with 0x00 --> there is no difference between binary "\x01\x02\x00" and "\x01\x02" BINARY is padded (for storage), VARBINARY is not. https://dev.mysql.com/doc/refman/5.7/en/binary-varbinary.html
Re: DBD::mysql path forward
On 9/13/17 9:31 AM, p...@cpan.org wrote: On Tuesday 12 September 2017 11:32:36 Darren Duncan wrote: On 2017-09-12 11:05 AM, p...@cpan.org wrote: On Tuesday 12 September 2017 19:00:59 Darren Duncan wrote: I strongly recommend that another thing happen, which is re-versioning DBD::mysql to 5.0. 1. From now on, DBD::mysql versions 4.x would essentially be frozen at 4.041/4.043. 2. From now on, DBD::mysql versions 5.x and above would be where all active development occurs, would be the only place where Unicode handling is fixed and new MySQL versions and features are supported, and where other features are added. I'm fine with it. Basically it means reverting to pre-4.043 code and continue *git* development there with increased version to 5.x. And once code is ready it can be released to cpan as normal (non-engineering) 5.x release. Yes, as you say. With respect to Git I propose doing this immediately: 1. Create a Git tag/branch off of 4.043 which is the 4.x legacy support branch. This is up to Patrick. I agree that we can start there. I do like the discussion going on now and want to engage all those concerned and interested and have a plan. 2. Revert Git master to the pre-4.043 code and then follow that with a commit to master that changes the DBD::mysql version to 5.0. If everybody agree with this step, I can prepare pull request which revert tree to this state, plus re-apply/rebase commits which were newly accepted. Regardless, following point 2, mandate that all Git pull requests are made against the new 5.x master; the 4.x legacy branch would have no commits except minimal back-porting. New pull requests are by default created against "master" branch. So if 5.x development would happen in "master" and 4.x in e.g. "legacy-4.0" then no changes is needed. But on github it is not possible to disallow users to create new pull requests for non-default branch. When creating pull request there is a button which open dialog to change target branch.
Re: DBD::mysql path forward
Darren, I agree with this as well, with the exception of 4 and 5, keeping 5.0 "pure" to the new way of doing things. For releases, I think I want to understand what this will mean. Sooner or later, a release shows up in as a distribution package, installed on the OS, and I want to know what the way of communicating that to the users and vendors so expectations are met. That's another question of "how do we handle that?" and "how do we inform an OS packager/vendor, what to do? Thank you for the great discussion! Patrick On 9/12/17 2:05 PM, p...@cpan.org wrote: On Tuesday 12 September 2017 19:00:59 Darren Duncan wrote: On 2017-09-12 8:54 AM, Dan Book wrote: On Tue, Sep 12, 2017 at 11:04 AM, Patrick M. Galbraith wrote: Pali, Yes, I agree, we'll have to create a fork pre revert and stop accepting PRs How might we allow people time to test the fixes to give them time? Just have them use the fork, I would assume? To be clear, this sounds like a branch not a fork. If your plan is to reinstate the mysql_enable_utf8 behavior as in 4.042 rather than adding a new option for this behavior, then branching from 4.042 seems reasonable to me; but you should be very clear if this is your intended approach, as this is what led to many people corrupting data as they send blobs to mysql with the same mysql_enable_utf8 option, and expect them to accidentally not get encoded. Assuming that broken Unicode handling has been in DBD::mysql for a long time and that users expect this broken behavior and that fixing DBD::mysql may break user code making those assumptions... I strongly recommend that another thing happen, which is re-versioning DBD::mysql to 5.0. A declared major version change would signify to a lot of people that there are significant changes from what came before and that they should be paying closer attention and expecting the possibility that their code might break unless they make some adjustments. Without the major version change they can more easily and reasonably expect not having compatibility breaks. Part and parcel with this is that only DBD::mysql 5.0 would have the other changes required for compatibility with newer MySQL versions or features that would be the other more normal-sounding reasons to use it. So I specifically propose the following: 1. From now on, DBD::mysql versions 4.x would essentially be frozen at 4.041/4.043. They would expressly never receive any breaking changes (but see point 3) and in particular no Unicode handling changes. They would expressly never receive any new features. This is the option for people whose codebases and environments work now and want to leave it alone. 2. From now on, DBD::mysql versions 5.x and above would be where all active development occurs, would be the only place where Unicode handling is fixed and new MySQL versions and features are supported, and where other features are added. Version 5.0 specifically would have all of the backwards-breaking changes at once that are currently planned or anticipated in the short term, in particular fixing the Unicode. Anyone who is already making changes to their environment by moving to a newer MySQL version or want newer feature support will have to use DBD::mysql 5, and in the process they will have to go through their Perl codebase and fix anything that assumes Unicode is broken. 3. As an exception to the complete freeze otherwise mentioned, there could be one or more DBD::mysql 4.x release whose sole purpose is to back-port security fixes or select other bug fixes from 5.x. Also 4.x could gain minimalist documentation changes to indicate its new legacy status and point to 5.x. 4. Optional bonus 1: If it is reasonably possible to support both correct Unicode handling as well as the old broken handling in the same codebase, I suggest DBD::mysql 5.0 could also have a user config option where one could explicitly set it to make DBD::mysql use the old broken behavior, while the default would be to have the correct behavior. This would be analogous to Perl's "use experimental" feature. The idea is that it would provide a temporary stopgap for users migrating from 4.x where they could just make the minimal change of enabling that option but they otherwise wouldn't yet have to go through their codebase to fix all the assumptions of wrongness. Using this option would cause deprecation warnings to be emitted. Perhaps the feature could be lexical or handle-specific if appropriate to help support piecemeal migration to correct assumptions. Alternately it may be be best to not have this option at all and people simply have to fix their code on moving to 5.x. This matter is probably its own discussion, but the key part is it only applies to 5.x, and meanwhile the 5.x default is correct Unicode while 4.x freezes the old bad Unicode behavior. 5. Optional bonus 2: A user config option could be turned on but all that it does i
Re: DBD::mysql path forward
Pali, Yes, I agree, we'll have to create a fork pre revert and stop accepting PRs How might we allow people time to test the fixes to give them time? Just have them use the fork, I would assume? Regards, Patrick On 9/12/17 6:27 AM, p...@cpan.org wrote: On Tuesday 12 September 2017 05:40:31 Patrick M. Galbraith wrote: Hi all, After talking to Pali and looking at how other drivers have handled the issue, the best way forward will be to deal with solving the UTF-8 issue correctly as was attempted in May. This will be a problem for some, but only due to having to been accustomed to a work-around that relies on a intermittent and buggy implementation. The plan is to give ample time to let people prepare and comment as well as give them a chance to try the changes and adjust prior to stable release. I'm going to look through the mailing list and find particularly those who had problems back in May and June when we tried this before and work with them in advance of the change. Hi! To prove fact that other DBI drivers (e.g. Pg or SQLite) had fixed similar/same UTF-8 issue as MySQL has and behave Perl-correctly, I would provide test cases so you would see difference between Pg, SQLite and mysql DBI drivers. There are also many modules on cpan which uses mysql DBI driver. But I'm not sure if all those modules expects buggy behavior or not... DBD::mysql should be on par with all the other DBD drivers and allow transparent usage regardless of backing RDBMS, and this really is the only way. It will also allow for other fixes to proceed and the driver to continue improving and supporting all versions and enhancements of MySQL and MariaDB. Please do give us your thoughts on this as we want to be as helpful and transparent as possible. If we are going to have UTF-8 fix in DBD::mysql, I would suggest one thing right now: STOP MERGING AND ACCEPTING PULL REQUEST TO GITHUB DBD::MYSQL PROJECT! Reason is simple: Current git master repository at version 4.043 (against which are creating new pull requests) is reset to version 4.041 and couple of changes, including lot of bug fixes from 4.042 are missing People in 4.043 (and git master) re-discovered 4.041 bugs, which were fixed in 4.042 and started to fixing them again, either wrongly or in different way. Or just started complaining about them, that they are again present. Those (reverted) UTF-8 commits changes couple of lines, plus other fixes depends on it. Once git master repository starts to divergent, it would be very hard to incorporate UTF-8 fixes again. And speaking by myself, for me it would be easier to create a fork of DBD::mysql from point before big revert as trying to re-apply and rebase those patches on top of master with couple of changes...
DBD::mysql path forward
Hi all, After talking to Pali and looking at how other drivers have handled the issue, the best way forward will be to deal with solving the UTF-8 issue correctly as was attempted in May. This will be a problem for some, but only due to having to been accustomed to a work-around that relies on a intermittent and buggy implementation. The plan is to give ample time to let people prepare and comment as well as give them a chance to try the changes and adjust prior to stable release. I'm going to look through the mailing list and find particularly those who had problems back in May and June when we tried this before and work with them in advance of the change. DBD::mysql should be on par with all the other DBD drivers and allow transparent usage regardless of backing RDBMS, and this really is the only way. It will also allow for other fixes to proceed and the driver to continue improving and supporting all versions and enhancements of MySQL and MariaDB. Please do give us your thoughts on this as we want to be as helpful and transparent as possible. Thank you! Patrick
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, 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?
