On 07.02.2018 at 21:04, Stanislav Malyshev wrote: >> bundled libgd)[5]. Another important difference is that our bundled >> libgd uses ZendMM, but upstream libgd does not[6]. > > This one we need to find a solution for. GD is often exposed to the > unfiltered user input, has a potential to consume large amounts of > memory and not having ZendMM memory limits in place can be a serious issue.
I fully agree. Presumably few users are aware of this, and even if they were, it's not easy to cater to this generally. Until upstream libgd adds an API to attach custom memory allocators, we might have to patch the bundled copy (at least this would be a single, well located modification, instead of the current mess). >> For most Linux environments PHP is built with an upstream (system) >> libgd; on Windows usually the bundled libgd is used. Users targeting > > Windows is another concern - are there viable solutions for non-bundled > GD for Windows that we can recommend to the users? If not, that means we > still have to keep and maintain bundled GD, and if so, there's no point > to spend any time on un-bundling before we find solution to this. I don't see a real issue here. All other external PHP dependencies are provided by windows.php.net (amongst others, all GD dependencies, such as libjpeg), so a libgd.dll could also be provided, especially since upstream already provides a native Windows build "toolchain" which already relies on the dependencies provided by windows.php.net (see <https://github.com/libgd/libgd/tree/gd-2.2.5/windows>). -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
