Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101807
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.21 as permitted sender)
To: Stanislav Malyshev <smalyshev@gmail.com>,
 PHP Internals <internals@lists.php.net>
References: <12636a53-48a8-9be4-c2cc-a7e4a16a8ba8@gmx.de>
 <a3872c0c-eb52-1a51-7841-c88e24ef7769@gmail.com>
Message-ID: <1a4e2cea-3cbd-f330-adda-c7ca67b6ed2d@gmx.de>
Date: Wed, 7 Feb 2018 23:50:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <a3872c0c-eb52-1a51-7841-c88e24ef7769@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Replaced the bundled libgd with upstream (aka.
 system)libgd
From: cmbecker69@gmx.de ("Christoph M. Becker")

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