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

[Jeff McKenna]

On 2022-04-07 11:07 a.m., Andrew C Aitchison wrote:
> 
> On Thu, 7 Apr 2022, 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.
> 
> I wondered whether it made a difference to driver plugins and "DLL hell"
> - the PNG driver uses zlib/libz and libpng -
> but it seems that we outlaw building gdriver plugins and internal 
> libraries, so that would not be a reason to keep the internal libraries.
> 

I can confirm the 'DLL hell' on Windows builds, with GDAL's internal 
zlib clashing (even with trying to disable all references to the 
internal code).

-jeff


-- 
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/