[gdal-dev] test failures on pkgsrc build of 3.3.2rc3

[Even Rouault]

Greg,

> an I wonder if this file (in some VFS?) has an associated mode?  I would
> sort of expect openssl to error if the private key file were readable by
> group or other, and I don't understand this filefromstring big.  (I get
> the concept; I just have no idea how it works.)

The file is indeed created in a VFS specific to GDAL, but GDAL then 
reads that file, extracts the private key from it and passes it as a 
string to the openssl API. What I notice now is that the test just 
before in that file, test_eedai_3, uses the same key, with a slightly 
different way of specifying credentials but ultimately this goes to the 
same function that invokes openssl API. One difference is that in 
test_eedai_GOOGLE_APPLICATION_CREDENTIALS there are explicit \n at the 
end of each Base64 encoded line.

Could you try removing those explicit \n (I'm really talking about the 2 
characters \ and n, not the line ending)

and/or apply that patch

diff --git a/gdal/port/cpl_google_cloud.cpp b/gdal/port/cpl_google_cloud.cpp
index 7cbe945ffe..6043f363b2 100644
--- a/gdal/port/cpl_google_cloud.cpp
+++ b/gdal/port/cpl_google_cloud.cpp
@@ -476,7 +476,7 @@ bool 
VSIGSHandleHelper::GetConfiguration(CSLConstList papszOptions,
              return false;
          }
          CPLString osPrivateKey = oDoc.GetRoot().GetString("private_key");
-        osPrivateKey.replaceAll("\\n", "\n");
+        osPrivateKey.replaceAll("\\n", "\n").replaceAll("\n\n", "\n");
          CPLString osClientEmail = 
oDoc.GetRoot().GetString("client_email");
          const char* pszScope =
              CSLFetchNameValueDef( papszOptions, "GS_OAUTH2_SCOPE",
@@ -518,7 +518,7 @@ bool 
VSIGSHandleHelper::GetConfiguration(CSLConstList papszOptions,
                  CPLFree(pabyBuffer);
              }
          }
-        osPrivateKey.replaceAll("\\n", "\n");
+        osPrivateKey.replaceAll("\\n", "\n").replaceAll("\n\n", "\n");

          CPLString osClientEmail = CSLFetchNameValueDef(papszOptions,
              "GS_OAUTH2_CLIENT_EMAIL",


My suspicion is that some openssl versions might not like 2 consecutive 
line endings.

Hum, I've actually tried that on our CI MacOSX instance and that doesn't 
help, so I'm not optimistic above my above suggestion.

Even


-- 
http://www.spatialys.com
My software is free, but my time generally not.