On Tue, Jun 19, 2018 at 11:47 PM, Lester Caine <les...@lsces.co.uk> wrote:
> On 19/06/18 21:48, Stanislav Malyshev wrote: > >> What Bug! >>> It's passing all the test that I run on it perfectly stably otherwise I >>> would not even bother with PHP7. But the problem supporting ANY driver >>> is the exotic nature of PHP is just as difficult as the tools it needs >>> to interface with to make a fully functional stack ... >>> >> I have four bugs for interbase and four for firebird submitted just >> recently, as security issues. Do you want to take care of them? I can >> assign them to you if you want to take care of them. >> > > The last time I managed to patch php was over 15 years ago, I have not > been able to get a handle on the new structure used by PHP7 in part because > I've not had time to do any C coding since. I'm still working on moving > PHP5.2 code to work on PHP7 while keeping the stack working on W10 and > maintained versions of SUSE Linux. And some of the stuff I thought I'd > finished upgrading is not working again :( > > I'm not seeing any bugs listed in bugs.php.net that are security risks. I > don't touch PDO_firebird as it does not handle key Firebird features so > looking at 'InterBase related' only returns 8 bugs, and one of them is > missing documentation on the fbird_ aliases that I use in the ADOdb > Firebird driver. THAT is something I do spend time keeping tidy, and fixes > some of the niggles raw access encounters, but I will have a look at the > 2017 bugs that I'd not been aware of ... the other bugs are somewhat exotic > but not security matters. Just to clarify which bug I was referring to in that mail, it's this one: https://bugs.php.net/bug.php?id=72175 There are three issues that must be addressed: * The issue in the original bug report: Connecting to the same DB multiple times does not work. * The use of zend_list_delete() in *_close() functions, which is memory-unsafe. * Incorrect interaction of closing and multiple shared connections. While the underlying connection is shared, closing one resource should not close all the other ones, but also not result in any leaks (this ties into the previous point -- you can't just use zend_list_delete for that!) You may need to implement a double resource indirection to properly handle this, one holding the actual connection and another holding the connection resource. If you or someone who is familiar with interbase could fix these issues, that would be highly appreciated. Thanks, Nikita