Robert,

Options 1, 2 and 3 sound reasonable to me.

For 3, you'd probably want to emit a deprecation warning during the transition period if the user relies on the functionality without having explicitly enabled it

For 4, the import from network exists as a separate function importFromUrl(), and that one is pretty much used for spatialreference.org (for the better or the worse given spatialreference.org not being updated since ages, but some MODIS products reference it...). There's no separate function for import from file (not sure how much this capability is used. gdalsrsinfo is one of the legitimate user of it I could think of)

> I haven't looked whether the XML parser can then go on to load external resources too

This is our very simple cplminixml.cpp parser. It cannot load external resources.

Even

Le 27/09/2022 à 13:32, Robert Coup a écrit :
Hi all,

Currently SetFromUserInput() accepts all sorts of things as input for
a CRS definition — flavours of WKT, various EPSG/ESRI/etc identifiers
& combinations, OGC URNs/UR:s, Proj4 definitions, a set of static
names, and ProjJSON. As well, it accepts arbitrary http(s) urls & file
paths (including VSI paths), which may contain WKT/XML/PROJ4. (I
haven't looked whether the XML parser can then go on to load external
resources too)

This is certainly a useful function: a parser that accepts EPSG:1234,
compound CRSs (EPSG:1234+5678, and the same via URNs), WKT, and useful
names like "NAD27" is great.

While network & filesystem access can be disabled via the C++
interface, this isn't exposed to the C or SWIG bindings, and there's
no config override/defaults. GDAL does refuse to load large files, and
the results are then parsed as WKT/XML/etc so it's not trivial to
exploit, but nevertheless.

*Personally* I'd prefer an opt-in behaviour to any filesystem or
network access for functions which are pitched as swiss-army-knife
string parsers.

I understand there's backwards compatibility concerns at play, but
maybe some/all/any of:

1. Expose the ALLOW_NETWORK_ACCESS & ALLOW_FILESYSTEM_ACCESS
limitation options to SetFromUserInput() to the SWIG & C interfaces

2. Have a config option that sets the defaults for the limitations.

3. Swap the default limitations from allowing to denying at a future
release so users would need to opt-in.

4. Split out file/network access to separate functions.

Opinions & ideas most welcome.

Thanks,

Rob :)
_______________________________________________
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

Reply via email to