GoogleCloudStorageBuilder `with_skip_signature(true)` still attempting to fetch credentials

[andrewhamon]

Describe the bug
I have created a GcsStore with a custom HTTP connector and with_skip_signature(true). It was modeled after this gist: https://gist.github.com/alvarowolfx/fac50c9f2c0e08f1c0a0dd6eb4f8630e

My goal was to use very customized logic to fetch credentials and add them as a Bearer token.

The docs say this about with_skip_signature:

If enabled, GoogleCloudStorage will not fetch credentials and will not sign requests.

(emphasis added)

Despite this, I am observing that when using GoogleCloudStorageBuilder in this manner, it is attempting to fetch credentials. For example, if I delete ~/.config/gcloud/application_default_credentials.json entirely, then I observe object_store trying and failing to fetch a token from the instance metadata service. Here is a sample log from my custom http connector (note that this is not the exact same code as the gist I linked, just similar).

  2025-10-28T16:35:05.026635Z TRACE libdisget::store::google_auth_connector: Sending request, req: Request { method: GET, uri: http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token?audience=https%3A%2F%2Fwww.googleapis.com%2Foauth2%2Fv4%2Ftoken, version: HTTP/1.1, headers: {"metadata-flavor": "Google", "authorization": "Bearer <redacted>"}, body: HttpRequestBody(Bytes(b"")) }
    at discord_disget/libdisget/src/store/google_auth_connector.rs:117

The bearer token is getting attached in my HttpConnector as per the gist, which is why it is nonsensically (and somewhat ironically) in this request. Anyways, since this is on my local macbook these requests of course fail, and eventually cause the entire operation to fail.

If ~/.config/gcloud/application_default_credentials.json, does exist, then I observe object_store attempting to use that to refresh the credentials. This might succeed, or might fail, if the credentials are invalid/expired. This is how i first detected this issue - object_store was attempting to use the embedded refresh token to fetch a fresh access token, but this was failing.

So it seems that even when .with_skip_signature(true), object_store is still running through its standard credential fetching routine.

To Reproduce
Use a HttpConnector + .with_skip_signature(true) as per the linked gist. Add extra logs, and observe that object_store is attempting to retrieve credentials using its own logic.

Expected behavior
The documented behavior - object store does not attempt to retrieve credentials when using .with_skip_signature(true).

Additional context
We are using object_store in a developer-facing CLI tool. We have a very particular and customized priority order for different credential strategies to try which are more suited to the idiosyncrasies and variations in our development environments. This is why we are not using the built in credential fetching from object_store.

I am using object_store version 0.12.3

[kylebarron]

The relevant part of the code should be here:

arrow-rs-object-store/src/gcp/client.rs

Lines 159 to 164 in fc23712

	pub(crate) async fn get_credential(&self) -> Result<Option<Arc<GcpCredential>>> {
	Ok(match self.skip_signature {
	false => Some(self.credentials.get_credential().await?),
	true => None,
	})
	}

modeled after the AWS implementation here:

arrow-rs-object-store/src/aws/client.rs

Lines 217 to 238 in fc23712

	async fn get_session_credential(&self) -> Result<SessionCredential<'_>> {
	let credential = match self.skip_signature {
	false => {
	let provider = self.session_provider.as_ref().unwrap_or(&self.credentials);
	Some(provider.get_credential().await?)
	}
	true => None,
	};
	Ok(SessionCredential {
	credential,
	session_token: self.session_provider.is_some(),
	config: self,
	})
	}
	pub(crate) async fn get_credential(&self) -> Result<Option<Arc<AwsCredential>>> {
	Ok(match self.skip_signature {
	false => Some(self.credentials.get_credential().await?),
	true => None,
	})
	}

I don't have the time to track this down myself but I can point you in the right direction if you want to debug further