Re: [PHP-DEV] Concerns about syncing bundled libgd to upstream 2.4 (GH-22532)

Hi Giovanni,

On Wed, Jul 8, 2026 at 5:06 PM Giovanni Giacobbi <[email protected]> wrote:
>
> Greetings,
>
> For many years, PHP shipped with a bundled libgd as an alternative to the system version. The bundled libgd is a custom version of upstream, originally based on GD-2.0, and over time cherry-picked backports and customizations, , have been made. Due to this divergence, it is difficult to assess exactly what the changes are in the bundled library compared to upstream, as diffing against any upstream branch or tag yields a massive diff with a lot of noise.

Mainly custom memory allocators since it was done.

> A proper resync with upstream has been due for a long time, and very needed, and I think it's great that this is happening, but I have some concerns I would like to highlight, just to be on the safe side of things.

Indeed.

> In the past few years, upstream libgd repository has seen very low activity, but recently development was restarted at a very fast pace, with a lot of new interesting features being added to master and several fixes to the stable branch.
>
> Last week GH-22532 [1] was opened for php-src to "Sync bundled libgd to 2.4.0".

It is purely a sync, with no BC but bug fixes in two functions which
were not working properly.
Volker ran audits and has been approved.


> Here is a quick recap on the upstream repository [2] at the time of writing:
>
> libgd/GD-2.3:
>  - Last release 2.3.3, september 2011
>  - Activity until may 2026 (src/ only): 38 commits, 21 files changed, 179 insertions(+), 102 deletions(-)
>  - Activity since may 2026 (src/ only): 21 commits, 21 files changed, 1.234 insertions(+), 386 deletions(-)
>
> libgd/master (GD-2.4):
>  - Never released
>  - Activity since may 2026 (src/ only): 68 commits, 136 files changed, 67.954 insertions(+), 47.472 deletions(-)

Many additions. And that's the 2nd PR I like to propose actually
making additions to the extension itself (draft here
https://wiki.php.net/rfc/ext-gd-2.4)

> Moreover, this is what i obtain by diffing the tip of the PR with the current libgd/master:
>   $ diff -ur libgd-src/src php-src/ext/gd/libgd | diffstat | tail -1
>   84 files changed, 93.108 insertions(+), 15.278 deletions(-)

I don't consider LOCs of any relevant values. However the breakdown if
you remove the new additions, which are not used by php in this PR,
they are CS (both sides), merge features that should be in both or add
what is needed so that both provide the same level of quality and
features.

> I am NOT questioning the quality of the work, the new features in the library look very promising and they would be a great addition to PHP, but I have the following concerns I wanted to share:
>
>  1) This code was introduced in the upstream repository less than a month ago, so it is relatively "young"

No. It was in master at that time.

>  2) libgd-2.4.0 was never released nor tagged, thus no major distros are shipping it

Because I want to follow the 8.6 release so both are available at the
same time. The 1st PR being a pure sync with no actual changes in the
behavior of the PHP extension but better support for quite a few
codecs and safer (full corpus codecs conformance for 90% of the
codecs),

>  3) PHP-8.6 already tagged alpha1, giving overall a short timespan to test the new bundled library

I mailed RMs before alpah1 was tagged, and also along other things
(sec issue on gh not part of releases), I did not get any answer so
far. And alpha1 was always still time for additions.

>  4) Introducing features in ext/gd that exist only in libgd-2.4 would in fact force the bundled library as the only build option

As I mentioned in the PR and here, nothing from what exists is
affected. Also I am not sure about that point. We have hundred of
featues in php depending on libraries versions, system libs available,
or even specific functions. Having functions requiring a library
version, bundled or not, is extremely common too.

> Given the above, I'd like to hear people's opinions on the matter. My concern is that hitting the PHP-8.6 timeline may end up forcing rushed decisions, and it would be preferable to wait for libgd-2.4.0 to have an actual upstream release, and to give time to a broader audience to test the new features before we commit to shipping them.

I would have appreciated you would let the PR itself go through RFC
when I pointed it out to you in mail about deprecation for 8.6 (with
or without that). That would have given a much more complete, and
positive, introduction about that specific PR and what is the one
following once it can be approved, adding actual new features to php's
ext. I am fuine with this mail but it just comes here with incomplete
information and not mentioning the reviews, audits (PHPF's Volker
security team) and full tests passing. That mail focused on LOCs
changed instead :)


Cheers,

--
Pierre

@pierrejoye