Use registry host rather than URL for creds lookup

[itowlson]

There is an issue in GitHub actions where wkg publish fails with code DENIED even after a successful docker login.

The reason appears to be that wkg asks docker-credential to look up credentials for the schemeful server_url (e.g. https://ghcr.io), whereas ~/.docker/config.json contains bare hosts (e.g. ghcr.io). docker-credential does not normalise away the schema of the passed-in lookup key, so never matches the schemeful entry.

This PR proposes changing the lookup to use the oci_registry of the backend type, rather than the URL.

This also fixes an issue on WSL, where the docker-credential-desktop.exe store also requires matching the bare host.

That said, I don't know what else is relying on having the full URL. The current code has been there for nearly 18 months and I'm assuming it was done that way for a reason. So if we want to be more conservative, we can try a more complicated solution where we test with the oci_registry first, and if that fails, try with the constructed server_url. I'll let wiser heads decide whether that's worth it!

[lann]

keirlawson/docker_credential#7

I think the least-bad option here might be to check both with and without scheme.

[itowlson]

@lann I have added checking with scheme if checking without scheme fails. I'm not able to test with "with scheme" fallback because my creds helper is firmly team "no scheme." It sounds like you've needed scheme in the past so if you're able to give this a try then that would be super helpful - thanks!

[lann]

I believe "with scheme" is required for docker login credentials. @fibonacci1729 might be able to test before I get a chance.

[itowlson]

I know folks are busy but I'd be terribly grateful if someone was able to look at this - thanks!

[fibonacci1729]

Sorry @itowlson this fell off my radar. Forgive my dayquil brain, but how do I test this?

[itowlson]

@fibonacci1729 Unfortunately, I am not sure. I know that the current code does not work on GitHub actions or WSL, but clearly worked for the original authors, which suggests maybe it worked on... Mac and native Linux? @lann suggests a relationship to docker login, but docker login is what I used on WSL, and what you used in the GH action that hit the problem. I was hoping the repo maintainers had a bit more insight than I did to be honest!

I guess the answer is "find something that does require schemes and make sure it still works in that environment," but I'm afraid I don't know what that environment is: presumably whatever environment was used for the original work on wkg push...?

[fibonacci1729]

I've verified that things seem to work on my mac (not that we didn't know that already). @lann can you provide any clarify here?

[tbrockman]

Not sure if this was @lann 's intent, but looking into the related docker_credential source code one thing might be to verify the behavior in a system where rather than using .docker/config.json (or wherever DOCKER_CONFIG lies) for storing credentials, the credentials are stored by a credential store, which seems to be the case where a scheme like https:// is actually used for identification (?).

Writing a test for this in a platform-agnostic way seems like it'd be tricky though.

[itowlson]

@tbrockman Credential stores may vary - my WSL stores credentials in docker-credential-desktop.exe, and that was not using schemes, which is why wkg main failed for me.

[lann]

I've verified no regression in at least one scenario, which I think is good enough given the limited risk here.