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

Even Rouault even.rouault at spatialys.com
Sat Sep 4 03:25:17 PDT 2021


> 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 = 
          const char* pszScope =
              CSLFetchNameValueDef( papszOptions, "GS_OAUTH2_SCOPE",
@@ -518,7 +518,7 @@ bool 
VSIGSHandleHelper::GetConfiguration(CSLConstList papszOptions,
-        osPrivateKey.replaceAll("\\n", "\n");
+        osPrivateKey.replaceAll("\\n", "\n").replaceAll("\n\n", "\n");

          CPLString osClientEmail = CSLFetchNameValueDef(papszOptions,

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.


My software is free, but my time generally not.

More information about the gdal-dev mailing list