<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>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 (<a class="moz-txt-link-freetext" href="https://github.com/rashadkm">https://github.com/rashadkm</a>) but he seems to have
disappeared from github (at least @ pings were ineffective)<br>
</p>
<p>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
<a class="moz-txt-link-freetext" href="https://github.com/conda-forge/libkml-feedstock/tree/main/recipe/patches">https://github.com/conda-forge/libkml-feedstock/tree/main/recipe/patches</a>),
that should be worth exploring upstreaming. Possibly fixes &
enhancements in its CMake build system?<br>
</p>
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.<br>
<p>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)<br>
</p>
<p>@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.</p>
<p>@Peter You're welcome to submit a PR enhancing GDAL libkml driver
doc.</p>
<p></p>
<p>Even<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">Le 04/10/2024 à 01:47, Simon Eves a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAJf0KTRSgUCgXAm32GOs13LRKYwadtT+dzsNQm4N9ZEZymodeA@mail.gmail.com">
<div dir="ltr">We include <b>libkml</b> 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).
<div><br>
</div>
<div>The build script for it predates me, but it appears we also
had issues with <b>uriparser</b>. We build that (v0.9.8)
separately (pretty much stock) and then hack the <b>libkml</b>
build to use it in preference, as follows:</div>
<div><br>
</div>
<div>unzip -u libkml-master.zip<br>
cd libkml-master<br>
# Don't use bundled third_party uriparser.<br>
# It results in duplicate symbols when linking some of our
tests,<br>
# and is missing symbols used by arrow because it is an old
version.<br>
rm -Rf third_party/uriparser-*<br>
find . -name Makefile.am -exec sed -i 's/ liburiparser\.la//'
{} +<br>
find . -name Makefile.am -exec sed -i '/uriparser/d' {} +<br>
# Delete trailing backslashes that precede a blank line left
from prior command.<br>
find . -name Makefile.am -exec sed -iE
':a;N;$!ba;s/\\\n\s*$/\n/m' {} +<br>
./autogen.sh<br>
CURL_CONFIG=$PREFIX/bin/curl-config \<br>
CXXFLAGS="-std=c++03" \<br>
LDFLAGS="-L$PREFIX/lib -luriparser" \<br>
./configure --with-expat-include-dir=$PREFIX/include/
--with-expat-lib-dir=$PREFIX/lib --prefix=$PREFIX
--enable-static --disable-java --disable-python --disable-swig<br>
makej<br>
make install<br>
</div>
<div><br>
</div>
<div>Of the other deps you mentioned, we are using <b>expat</b>
2.6.2 (prompted by a Python 3.12 and <b>gdb</b> issue on
Ubuntu 24.04) and <b>boost</b> 1.84. We don't seem to include
<b>minizip</b> explicitly. We build with system <b>zlib</b>.</div>
<div><br>
</div>
<div>Maybe this is helpful. Maybe not. This is all on Linux (we
do both RHEL and Ubuntu builds).</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Oct 3, 2024 at 4:18 PM
P O'Toole via gdal-dev <<a
href="mailto:gdal-dev@lists.osgeo.org"
moz-do-not-send="true" class="moz-txt-link-freetext">gdal-dev@lists.osgeo.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote">
<div class="msg-840516237209857243">
<div dir="ltr">
<div>
Hello list —</div>
<div>
<br>
</div>
<div>
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...</div>
<div>
<br>
</div>
<div>
GDAL's documentation page ( <a
href="https://gdal.org/en/latest/drivers/vector/libkml.html#vector-libkml"
id="m_8074551910166500617OWAed4bdc09-607b-cdaa-b8d1-2cf043c32c6c"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">
https://gdal.org/en/latest/drivers/vector/libkml.html#vector-libkml</a> )
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
(
<a
href="https://www.cvedetails.com/version/1531247/Uriparser-Project-Uriparser-0.7.5.html"
id="m_8074551910166500617OWA8c7ccd54-aca2-45fe-a1fe-c72b7e95f729"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">
https://www.cvedetails.com/version/1531247/Uriparser-Project-Uriparser-0.7.5.html</a> ).
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 ( <a
href="https://www.cvedetails.com/vulnerability-list/vendor_id-17534/product_id-43048/version_id-1233835/Minizip-Project-Minizip-1.1-4.html"
id="m_8074551910166500617LPlnk" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">
https://www.cvedetails.com/vulnerability-list/vendor_id-17534/product_id-43048/version_id-1233835/Minizip-Project-Minizip-1.1-4.html</a> ),
as does boost 1.50.0 (<a
href="https://www.cvedetails.com/vulnerability-list/vendor_id-7685/product_id-13033/version_id-499391/Boost-Boost-1.50.0.html"
id="m_8074551910166500617LPlnk" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.cvedetails.com/vulnerability-list/vendor_id-7685/product_id-13033/version_id-499391/Boost-Boost-1.50.0.html</a>)
alongside expat 2.1.0 (<a
href="https://www.cvedetails.com/version/1175174/Libexpat-Project-Libexpat-2.1.0.html"
id="m_8074551910166500617LPlnk" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.cvedetails.com/version/1175174/Libexpat-Project-Libexpat-2.1.0.html</a>)
and zlib 1.2.8 (<a
href="https://www.cvedetails.com/version/1618219/Zlib-Zlib-1.2.8.html"
id="m_8074551910166500617LPlnk" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.cvedetails.com/version/1618219/Zlib-Zlib-1.2.8.html</a>).
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.</div>
<div>
<br>
</div>
<div>
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 <a href="http://gdal.org"
target="_blank" moz-do-not-send="true">gdal.org</a>
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.</div>
<div>
<br>
</div>
<div>
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.</div>
<div>
<br>
</div>
<div>
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.</div>
<div>
<br>
</div>
<div>
- Patrick O'Toole</div>
<div>
<br>
</div>
<div>
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.</div>
<div>
<br>
</div>
<div>
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.</div>
</div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</div>
</blockquote>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>