Link to GDAL security thread

[rsbivand]

This thread https://lists.osgeo.org/pipermail/gdal-dev/2021-July/054470.html (based on https://lists.osgeo.org/pipermail/gdal-dev/2021-July/054466.html) has implications for packagers of GDAL, including packages with GDAL as a system requirement.

This particular case is for JSON, but Bob Rudis' @hrbrmstr blog remains relevant: https://rud.is/b/2018/02/16/pym-js-library-vulnerability-in-widgetframe-package/. When something upstream needs fixing, it is potentially important to know their policies, and GDAL's looks like being caveat emptor unless funding is forthcoming for alternatives.

Strictly, this is an "included source" problem, where the geojson OGR driver bundles an old version of json-c source, and uses it if libjson-c is not available (configure.ac line 4777). Defensively, the Windows and MacOS binary builds might need to provide the patched binaries of libjson-c (current F34 0.14-8), 0.15 latest. But this may mean that driver-specific tweaks are lost (see thread). Ideas?

[rsbivand]

Also see: https://developers.slashdot.org/story/21/08/01/223206/are-python-libraries-riddled-with-security-holes and https://www.theregister.com/2021/07/28/python_pypi_security/. We need to be more careful in bundling source code, and in communicating the issues. Few R-spatial users will know how to sandbox R sessions: https://support.rstudio.com/hc/en-us/articles/236144647-Why-doesn-t-RStudio-Workbench-RStudio-Server-sandbox-R-sessions-.

[rsbivand]

See also the starting of a mailing list here:

https://github.com/geopython/pygeoapi/blob/master/SECURITY.md