[gdal-dev] zlib vulnerability CVE-2018-25032 affecting GAL

[Jeff McKenna]

Thank-you Greg, this is exactly my earlier comment directly on the 
associated ticket this morning, but you explain it much better: 
https://github.com/OSGeo/gdal/issues/5587

It has caused so much grief downstream (zlib inside GDAL), that I 
believe it is time to remove it.

-jeff





On 2022-04-07 10:08 a.m., Greg Troxel wrote:
> 
> Even Rouault <even.rouault at spatialys.com> writes:
> 
>> Most GDAL binary distributions don't use that internal copy but the
>> external zlib library provided by the operating system / distribution
>> channel.
> 
> I realize you are accomodating people who can somehow get and build gdal
> sources but can't first install zlib, but from the packaging viewpoint
> having included copies is a bad thing.  Yes, it shouldn't get used, but
> if a dependency isn't declared it would be hidden or not provided and
> then be used anyway.
> 
> I therefore think it would be good to consider removing the vendored
> copies, or at least requiring explicit config to turn them on.  (I just
> looked in the sources for how to build and didn't find it in README.  I
> know I have figured out how to build and this isn't a request for help,
> but in terms of the cmake migration the instructions are missing.)  It
> looks like internal will just be used if zlib is not found.
> 
> I wonder if it's still really necessary/helpful to have included libs
> like zlib.
>