Hi, > -----Original Message----- > From: Christoph M. Becker [mailto:cmbecke...@gmx.de] > Sent: Wednesday, February 7, 2018 11:51 PM > To: Stanislav Malyshev <smalys...@gmail.com>; PHP Internals > <internals@lists.php.net> > Subject: Re: [PHP-DEV] Replaced the bundled libgd with upstream (aka. > system)libgd > > 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). > There's gdIOCtx in libgd, which allows usage of the PHP streams. Until similar is available for the memory management, we probably stick with a bundled lib in one or another form. Especially on 64-bit.
> >> 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>). > Certainly an external libgd is doable. Once the PHP compatibility is there, libgd could be added to the dependency lists. Same scenario as it was done for libzip in 7.2. From the current POV, it seems that bundling of the patched upstream version, that supports ZMM, would be the optimal solution for both maintenance and security. The unbundling topic can be revived, once libgd provides custom allocator functionality. Regards Anatol
