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