[gdal-dev] GDAL, Proj and cacert

[Paul Harwood]

O dear - I seem to stepped into an active fire zone .... :) My question was
purely practical and about a problem that I experienced and that Even has
answered - but in the wider context I might make the following points...

- Working in Unity - which is .NET (or more precisely MONO) and x-platform
... there are some complexities about process contexts and environments
(basically - there are a lot of corner cases!). That just makes explicitly
setting options in the API a lot easier than implicitly through envvars.

- GDAL is actually very good at this - I have a lot of code like this and
it works well:

                //Other gdal configs
                Gdal.SetConfigOption("OGR_WFS_LOAD_MULTIPLE_LAYER_DEFN",
"NO");
                Gdal.SetConfigOption("OGR_WFS_PAGING_ALLOWED", "YES");
                Gdal.SetConfigOption("OGR_WFS_USE_STREAMING", "NO");

- The problem I have is actually with PROJ - but if I was calling PROJ
directly through some hypothetical C# binding then it would not be a
problem since PROJ has the method call to set the option explicitly.
However - since I am calling PROJ through the GDAL API call - that is not
an option. For some PROJ options, they do exist in the GDAL API - e.g.

                Osr.SetPROJEnableNetwork(true);

but I can see why most of them would not ...

- Aha - you might say - that is why env var setting is good because it
bypasses the GDAL API. But that just gets me back to the first bullet above
:)

- What would be nice would be an explicit way of setting the default for
PROJ. Since version 7 - PROJ has an ini file but it does not seem to
include the cacert file. I can see why that might be seen as being a
potential security hole - although I would point out that the ini file DOES
allow specification of the CDN URL. From a security point of view - those
two facts together kind of say "you can do a man in the middle attack if
and only if your attack is inherently insecure" ... :)

The bottom line is of course - GDAL does not help in this which is OK since
it is not really a GDAL problem and I will just have to make the env vars
work ...

On Fri, 11 Feb 2022 at 20:49, Jeff McKenna <jmckenna at gatewaygeomatics.com>
wrote:

> On 2022-02-11 3:48 p.m., Howard Butler wrote:
> >
> >> On Feb 11, 2022, at 1:41 PM, Jeff McKenna
> >> <jmckenna at gatewaygeomatics.com <mailto:jmckenna at gatewaygeomatics.com>>
> >> wrote:
> >>
> >> Unfortunately this issue comes up very often, as you said, so much of
> >> our stack relies heavily on environment variables.  My hope is that in
> >> the long run, the ini-style of settings can help battle this Windows
> >> Server x64 issue (yes googling this does return many
> >> unproven/non-reproducible reports for other projects, very
> disheartening).
> >
> > The frustrations of how to pass environment variables in different
> > computing environments is an issue that's orthogonal to how GDAL
> > expresses configuration through environment variables. I get that the
> > rules of environment variable resolution can be quite bespoke depending
> > on the computing platform and environment you are operating on, but it's
> > not legit to say "environment variables don't always work for me, we
> > should do config files, but I don't have a reproducible test case to
> > show that"
>
>
> I agree here.  But it's important to share and give thoughts, and by
> having an open discussion I'm sure other packagers will keep an eye open
> for such mysterious issues on Windows Server x64 with cacert environment
> variables.  (I hope to never see the issue reported again to me, ha)
>
> -jeff
>
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20220212/999ac06e/attachment.html>