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@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@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
