[PROJ] PROJ grid files CDN
Greg Troxel
gdt at lexort.com
Fri Sep 13 11:38:19 PDT 2019
Even Rouault <even.rouault at spatialys.com> 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.
More information about the PROJ
mailing list