<div dir="ltr">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...<div><br></div><div>- 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.<br><br>- GDAL is actually very good at this - I have a lot of code like this and it works well:</div><div><br></div><div> //Other gdal configs<br> Gdal.SetConfigOption("OGR_WFS_LOAD_MULTIPLE_LAYER_DEFN", "NO");<br> Gdal.SetConfigOption("OGR_WFS_PAGING_ALLOWED", "YES");<br> Gdal.SetConfigOption("OGR_WFS_USE_STREAMING", "NO");<br></div><div><br></div><div>- 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.</div><div><br></div><div> Osr.SetPROJEnableNetwork(true);<br></div><div><br></div><div>but I can see why most of them would not ...<br><br>- 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 :)<br><br>- 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" ... :)<br><br>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 ...</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 11 Feb 2022 at 20:49, Jeff McKenna <<a href="mailto:jmckenna@gatewaygeomatics.com">jmckenna@gatewaygeomatics.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2022-02-11 3:48 p.m., Howard Butler wrote:<br>
> <br>
>> On Feb 11, 2022, at 1:41 PM, Jeff McKenna <br>
>> <<a href="mailto:jmckenna@gatewaygeomatics.com" target="_blank">jmckenna@gatewaygeomatics.com</a> <mailto:<a href="mailto:jmckenna@gatewaygeomatics.com" target="_blank">jmckenna@gatewaygeomatics.com</a>>> <br>
>> wrote:<br>
>><br>
>> Unfortunately this issue comes up very often, as you said, so much of <br>
>> our stack relies heavily on environment variables. My hope is that in <br>
>> the long run, the ini-style of settings can help battle this Windows <br>
>> Server x64 issue (yes googling this does return many <br>
>> unproven/non-reproducible reports for other projects, very disheartening).<br>
> <br>
> The frustrations of how to pass environment variables in different <br>
> computing environments is an issue that's orthogonal to how GDAL <br>
> expresses configuration through environment variables. I get that the <br>
> rules of environment variable resolution can be quite bespoke depending <br>
> on the computing platform and environment you are operating on, but it's <br>
> not legit to say "environment variables don't always work for me, we <br>
> should do config files, but I don't have a reproducible test case to <br>
> show that"<br>
<br>
<br>
I agree here. But it's important to share and give thoughts, and by <br>
having an open discussion I'm sure other packagers will keep an eye open <br>
for such mysterious issues on Windows Server x64 with cacert environment <br>
variables. (I hope to never see the issue reported again to me, ha)<br>
<br>
-jeff<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>