Closed ekhabarov closed 3 weeks ago
It looks like introduced in #602 cc @msiebuhr
I'm getting this same issue on wsl2 under Windows
+1 same issue. I'm working around it for now locally by passing in dummy creds for the registry it's failing to find creds for:
echo '{"ServerURL":"gcr.io","Username":"none"}' | docker-credential-osxkeychain store
I'm guessing your .docker/config.json
looks something like the following, right?
{
"credsStore": "osxkeychain"
}
My guess is that the built-in client tries to use any authentication method given to it, regardless of the upstream actually requiring authentication or not. (That used to be safe, as it only looked at explicitly configured registry names).
Now that my patch also makes it return the generic credentialsStore, the client will use that regardless of the registry actually requires authentication or not.
Off the bat, I can think of two fixes:
@msiebuhr my ~/.docker/config.json
looks like this
{
"auths": {
...
},
"credsStore": "desktop",
}
while gcr.io
is a public registry I'm trying to pull an image from is not in auths
list.
Same for me. The credentials helper should not be called when the registry is not defined in the auths
section.
No problem with a revert of https://github.com/bazel-contrib/rules_oci/pull/602
+1 confirming same issue
Same for me. The credentials helper should not be called when the registry is not defined in the
auths
section. No problem with a revert of #602
If we need to copy the behavior of Docker, we should copy it if the upstream registry returns HTTP 401 when trying to fetch from it.
On the down-side, the Bazel downloader won't let us look at the WWW-Authenticate
-header (https://github.com/bazel-contrib/rules_oci/blob/main/oci/private/authn.bzl#L7-L8):
# Unfortunately bazel downloader doesn't let us sniff the WWW-Authenticate header, therefore we need to
# keep a map of known registries that require us to acquire a temporary token for authentication.
On the flip-side, it looks like @thesayyn de-facto fixed the issue in 9f0079bd by adding an allow_fail = True
for this case:
+def _fetch_auth_via_creds_helper(rctx, raw_host, helper_name, allow_fail = False):
if rctx.os.name.startswith("windows"):
executable = "{}.bat".format(helper_name)
rctx.file(
@@ -120,7 +119,10 @@ exec "docker-credential-{}" get <<< "$1" """.format(helper_name),
)
result = rctx.execute([rctx.path(executable), raw_host])
if result.return_code:
- fail("credential helper failed: \nSTDOUT:\n{}\nSTDERR:\n{}".format(result.stdout, result.stderr))
+ if not allow_fail:
+ fail("credential helper failed: \nSTDOUT:\n{}\nSTDERR:\n{}".format(result.stdout, result.stderr))
+ else:
+ return {}
response = json.decode(result.stdout)
@@ -183,7 +185,7 @@ def _get_auth(rctx, state, registry):
# look for generic credentials-store all lookups for host-specific auth fails
if "credsStore" in config and len(pattern.keys()) == 0:
- pattern = _fetch_auth_via_creds_helper(rctx, registry, config["credsStore"])
+ pattern = _fetch_auth_via_creds_helper(rctx, registry, config["credsStore"], allow_fail = True)
# cache the result so that we don't do this again unnecessarily.
state["auth"][registry] = pattern
fixed by https://github.com/bazel-contrib/rules_oci/pull/664, thank you @msiebuhr
Mmmm, a credential helper which should not be called is different from a credential helper which can failed. This issue is not really fixed but just mitigated IMHO.
Mmmm, a credential helper which should not be called is different from a credential helper which can failed. This issue is not really fixed but just mitigated IMHO.
Calling the global cred helper is a fix for https://github.com/bazel-contrib/rules_oci/issues/388, we can't fix both without doing something like this.
I thought I'd tested with a custom credential helper and a ~/.docker/config.json
without the auths
section, but I've just retested and this custom credential helper is well called. Sorry for the noice.
Encountered the error after upgrading rules_oci v1.7.6 => 1.8.0 on Mac M2.
repro: https://github.com/ekhabarov/rules_oci_1_8_0
WORKSPACE:
.bazelversion