CredentialHelper change broke unix domain socket support

We use a unix domain socket for our remote_executor and remote_cache endpoints, because we use a side-car proxy to handle SPIFFE mTLS negotiation. This stopped working with the release of bazel 5.3.0. With 5.3.0, bazel fails before issuing its first GetCapabilitiesRequest. The error message was “ERROR: Failed to query remote execution capabilities: UNAUTHENTICATED: Failed computing credential metadata.” When enabling verbose failures, the stack trace pointed to a failed precondition because the host portion of the URI was null. I played around with the code and got it working again, but the fix isn’t production-quality – it doesn’t handle the case where the remote cache endpoint differs from the remote executor endpoint, and might need different credentials. Because we’re using unix domain sockets, this shouldn’t affect us at all. Anyway, consider the following patch a place to start the conversation about what the correct fix might look like.

index a7d793ad56..d7db02bd6f 100644
--- a/src/main/java/com/google/devtools/build/lib/remote/RemoteModule.java
+++ b/src/main/java/com/google/devtools/build/lib/remote/RemoteModule.java
@@ -1055,6 +1055,22 @@ public final class RemoteModule extends BlazeModule {
       AuthAndTLSOptions authAndTlsOptions,
       RemoteOptions remoteOptions)
       throws IOException {
+
+    // TODO: this is a temporary hack.  Because remoteCache and remoteExecutor could be different, they might need
+    // different credentials.  If the endpoints used to access remote services are unix domain sockets, credential
+    // helpers aren't needed -- the service is running on the same machine.
+    //
+    // Also note that URI("unix://...") will replace "unix" with "https" for some reason that escapes me, but that
+    // makes it tricky to use.  Somewhere (not here because of the checks in the try clause below), that was
+    // happening, because by the time findCredentialHelper() is called, these URIs have been changed from "unix://"
+    // to "https://".  According to the bazel documentation, the "unix:" scheme is supposed to disable TLS.
+    if (remoteOptions.remoteCache != null && Ascii.toLowerCase(remoteOptions.remoteCache).startsWith("unix:/")) {
+           return null;
+    }
+    if (remoteOptions.remoteExecutor != null && Ascii.toLowerCase(remoteOptions.remoteExecutor).startsWith("unix:/")) {
+           return null;
+    }
+
     Credentials credentials =
         GoogleAuthUtils.newCredentials(
             credentialHelperEnvironment, commandLinePathFactory, fileSystem, authAndTlsOptions);

[Wyverald]

@bazel-io fork 5.3.1

[fmeum]

@bazel-io flag