Re: PROJ grid files CDN

Even Rouault <[email protected]> writes:

>> I think there are also security considerations. Is PROJ proofed against
>> malicious grid files like our browsers are against malicious javascript?
>
> In that context, one should indeed have a deeper look at how it opens them and 
> try to secure that (with the curent raw formats which are quite simple, that 
> shouldn't be too challenging). That said, the resources it would fetch would 
> not be random, so unless a hostile party manages to upload a corrupted file in 
> the CDN storage (or changes entries in the local proj.db), the set of what is 
> access should be rather well defined.
>
> Note: those concerns about security are already valid currently. For example 
> if using a PROJ string with a geoidgrids/nadgrids parameter that points to a 
> local file that would be hostile.

Two separate issues:

  a file with an exploit

  just getting the wrong data.  packaging systems usually have crypto
  checksums, and hence I suggested having hashes.

> There's no such thing as a "correct result" regarding coordinate 
> transformation that involve changes of datum. There are results that are more 
> or less accurate given the possibilities offered in the database which are 
> themselves somewhat arbitrarily available according to what national geodetic 
> agencies have provided to EPSG, which tranformation methods are actually 
> implemented in PROJ, etc. So depending on what is available and what your 
> needs are, you could get a result that is correct with an accuracy of 100m, 
> 10m, 1m, 1cm...

But still, there is a notion that:

  With this input, and this conversion string, I ran proj, and I
  (silently) got different results.

So it's not that the output is wrong in an egregious sense, it is that
that it's different in a way which perhaps should be controlled and
isn't.
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj