Hello list — I recently built GDAL 3.9.0 from source on a new Amazon Linux 2023 system, which sadly lacks all of the wonderfulness of EPEL, which previously provided most of the necessary stuff on the RHEL-family operating systems we used before. Since we've historically provided support for exporting KML in our web applications, I concluded I ought to build the libkml dependency during the process, which is where the fun started...
GDAL's documentation page ( https://gdal.org/en/latest/drivers/vector/libkml.html#vector-libkml ) says to use the latest libkml release (version 1.3.0, a 2015 vintage) or build from master (currently commit 916a801, a 2017 vintage). The libkml release makefiles have instructions to grab various (old) release packages from hardcoded web-URLs and silently build and install(!!) them without asking if this is okay or suggesting that the latest packages be made available by the user. Some breakage led me to have a closer look and I found that a failing dependency was the result of a dead hard-coded URL pointing to a URIparser 0.7.5 release, which has had known vulnerabilities since 2018 ( https://www.cvedetails.com/version/1531247/Uriparser-Project-Uriparser-0.7.5.html ). The URIparser maintainer very nicely added warnings to that release, directing people to upgrade for security reasons. More looking around from there showed that minizip 1.3.0 also has issues ( https://www.cvedetails.com/vulnerability-list/vendor_id-17534/product_id-43048/version_id-1233835/Minizip-Project-Minizip-1.1-4.html ), as does boost 1.50.0 (https://www.cvedetails.com/vulnerability-list/vendor_id-7685/product_id-13033/version_id-499391/Boost-Boost-1.50.0.html) alongside expat 2.1.0 (https://www.cvedetails.com/version/1175174/Libexpat-Project-Libexpat-2.1.0.html) and zlib 1.2.8 (https://www.cvedetails.com/version/1618219/Zlib-Zlib-1.2.8.html). Though other dependencies won't be downloaded on libkml master 916a801, I believe boost 1.50.0 will still automatically be downloaded and built if another version cannot be found locally, at least in some cases. For folks just looking to build gdal as a dependency for something else e.g. GEOS or PostGIS, I think it would be easy overlook the above issues. As such, I'd argue that the documentation on gdal.org that relates to libkml should be adjusted to note that users building libkml should take care to make its dependencies available locally before it (the 1.3.0 package especially and to a lesser degree the latest commit of their main branch) goes and downloads vulnerable packages and installs them without asking. Obviously, GDALers aren't directly responsible for libkml (at least at this time) and the cleanest fix here lies on the libkml end, wherein they'd post a new release and likely freshen master slightly, ideally testing it against newer versions of the required dependencies. Of course, this will likely take time, so in the meanwhile, it might be nice for GDAL's documentation to reflect the reality that building with full KML features should be done carefully to avoid opening applications (and/or the users of those applications) to attack via carefully-constructed KML-files which could be used to perform malicious actions, modify an application to attack its users, etc. My question for anyone distributing pre-compiled versions of GDAL via package repositories (e.g. EPEL) or other mechanisms is whether they are aware of these issues, at least if they are building with full KML support via libkml. I take it they likely ARE aware, given libkml was discussed at the last maintainer meeting, but it behooves me to be sure. - Patrick O'Toole P.S. I may not be of great use in terms of coding on this issue, as my C++ is not very current and I don't have familiarity with the relevant internals, but I would be happy to contribute documentation as it relates to the libkml driver and how to build it for use with modern versions of GDAL. I may also be able to support some testing if there's action taken here. P.P.S. I am explicitly including Even because the maintainers-meeting summary asked that LIBKML-users make comment to Even... Some review of conversations relating to the filetypes my group currently supports reveals that a tool called OnX that's used by some of our biologists is compatible with KML, which makes it nice to have the option to export data to KML format. In addition, we sometimes work with partners from other organizations who use Google Earth to visualize geospatial features, because ArcGIS is expensive and QGIS is either not known or too cumbersome to learn or open for lighter tasks such as simply viewing data. For these reasons, I concluded that having libkml might be better than only GDAL's internal KML driver, although I have not done side-by-side comparisons to see which features or options work better on one driver versus the other for output, so I will refrain from making the strong statement, "We must have libkml and I know this for a fact." Hope that helps.
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
