[gdal-dev] libkml: providing more information about builds that include LIBKML to steer users away from security pitfalls and questions for packagers who may build with libkml

[Even Rouault]

Hi,

My thought would be that a few people (at least 2 as being a sole 
maintainer isn't a good idea) from the community would stand up and act 
as the new keepers of libkml. I guess we could host it at OSGeo/libkml 
because I'm not optimistic we can recover libkml/libkml. A few years ago 
I tried to contact its past maintainer (https://github.com/rashadkm) but 
he seems to have disappeared from github (at least @ pings were ineffective)

Functionally I believe libkml is feature-full or close to be. So this is 
"just" about maintenance. Existing pull requests to review. Patches 
hanging around here and there (like at 
https://github.com/conda-forge/libkml-feedstock/tree/main/recipe/patches), 
that should be worth exploring upstreaming. Possibly fixes & 
enhancements in its CMake build system?

Howard mentioned me as a POC because I raised the topic, but I'm not 
super willing to act as the primary maintainer of libkml, filling 
already that role too many times.

So another opportunity for the community to stand up, otherwise each 
interested party will have the miserable experience of acting separately 
as a maintainer, and probably we'll finally get into the situation where 
the thing is not usable anymore (it started causing issues for 
conda-forge builds some time ago, and they were considering dropping it)

@SimonEves I was confused by your mention of autogen.sh and stuff. I 
presume you're still using google/libkml. You'd probably have a slightly 
better experience with libkml/libkml which has only a CMake build system.

@Peter You're welcome to submit a PR enhancing GDAL libkml driver doc.

Even


Le 04/10/2024 à 01:47, Simon Eves a écrit :
> We include *libkml* in our GDAL build. We are still using v1.3.0 from 
> August 12, 2015. It still works fine for our requirements with GDAL 
> 3.7.3 (current production) and 3.9.2 (imminent deps bump).
>
> The build script for it predates me, but it appears we also had issues 
> with *uriparser*. We build that (v0.9.8) separately (pretty much 
> stock) and then hack the *libkml* build to use it in preference, as 
> follows:
>
> unzip -u libkml-master.zip
> cd libkml-master
> # Don't use bundled third_party uriparser.
> # It results in duplicate symbols when linking some of our tests,
> # and is missing symbols used by arrow because it is an old version.
> rm -Rf third_party/uriparser-*
> find . -name Makefile.am -exec sed -i 's/ liburiparser\.la//' {} +
> find . -name Makefile.am -exec sed -i '/uriparser/d' {} +
> # Delete trailing backslashes that precede a blank line left from 
> prior command.
> find . -name Makefile.am -exec sed -iE ':a;N;$!ba;s/\\\n\s*$/\n/m' {} +
> ./autogen.sh
> CURL_CONFIG=$PREFIX/bin/curl-config \
> CXXFLAGS="-std=c++03" \
> LDFLAGS="-L$PREFIX/lib -luriparser" \
> ./configure --with-expat-include-dir=$PREFIX/include/ 
> --with-expat-lib-dir=$PREFIX/lib --prefix=$PREFIX --enable-static 
> --disable-java --disable-python --disable-swig
> makej
> make install
>
> Of the other deps you mentioned, we are using *expat* 2.6.2 (prompted 
> by a Python 3.12 and *gdb* issue on Ubuntu 24.04) and *boost* 1.84. We 
> don't seem to include *minizip* explicitly. We build with system *zlib*.
>
> Maybe this is helpful. Maybe not. This is all on Linux (we do both 
> RHEL and Ubuntu builds).
>
> On Thu, Oct 3, 2024 at 4:18 PM P O'Toole via gdal-dev 
> <gdal-dev at lists.osgeo.org> wrote:
>
>     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 <http://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 at lists.osgeo.org
>     https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20241004/35836cf6/attachment.htm>