Theodore Brockman (Nov 02 2025 at 05:34): Theodore Brockman (Nov 02 2025 at 05:34):Following along the docs for publish WIT (https://component-model.bytecodealliance.org/composing-and-distributing/distributing.html#distributing-wit-and-components-by-package-name-with-wkg-publish ) and ran into the following:
$ wkg publish witmproxy\:plugin@0.0.1.wasm
Error: registry error: Authentication failure: {"errors":[{"code":"DENIED","message":"requested access to the resource is denied"}]}
Caused by:
Authentication failure: {"errors":[{"code":"DENIED","message":"requested access to the resource is denied"}]}
Which after cloning wasm-pkg-tools and poking around, seems to be due to a call to docker_credential::get_credential failing, claiming I have no credentials configured (which is quietly eaten, and anonymous auth is used instead):
2025-11-02T05:03:05.532227Z DEBUG wasm_pkg_client::oci: Failed to look up OCI credentials: User has no credential configured
This seems to be a mistake (as I do have a credential provided by docker login), and it seems that the code which prepends https:// to self.oci_registry (https://github.com/bytecodealliance/wasm-pkg-tools/blob/5b80fab1dfb0767f8c7ec12875ea797966a80261/crates/wasm-pkg-client/src/oci/mod.rs#L115) causes the failure, at least for my current version of docker (client v28.1.1, api1.48), as the auth information is stored under the "ghcr.io" key in my .docker/config.json sans protocol.
Removing the format!() call fixes the issue and allows me to publish successfully.
I'd assume that this is working for others, so I guess I'm curious as what's different in my environment or usage, or whether this is an actual bug.
Lann Martin (Nov 02 2025 at 12:13):There is indeed an issue with the upstream docker-credential crate but the fix is slightly less straightforward. This pr should work around the problem but needs further testing: https://github.com/bytecodealliance/wasm-pkg-tools/pull/176
Theodore Brockman (Nov 02 2025 at 18:33):@Lann Martin thanks for the link! Is there any strong belief that this PR would cause any issues, given that it still falls back to the old behavior (I guess there could be an issue introduced with the precedence now preferring credentials in .docker/config.json over native credential helpers)? It doesn't seem ideal to worry about the unknown potential issues this might cause at the cost of further prolonging the verified current one.
Lann Martin (Nov 02 2025 at 18:35):Well to be clear the existing code is currently working in some configurations so there is a real risk of regression, though I agree it isn't obviously likely.
Theodore Brockman (Nov 02 2025 at 18:52):Yeah, it should work as is for anyone with a credsStore configured (any other reasons aren't immediately apparent to me), but I guess it's difficult for me to imagine a reason trying both (and switching the PR to prefer the credential helper case which uses the hier-part for matching the server to be first) wouldn't work (and improve the situation for people with similar environments as I and the others), or I would be inclined to try it out and leverage any ensuing people complaining as data for why it didn't :grimacing: (but I can understand why as a maintainer that might not be appealing)
Theodore Brockman (Nov 02 2025 at 19:33):Err, correction, I didn't yet realize there's a distinction between a cred store and cred helper, so was wrong about the current precedence.
Lann Martin (Nov 10 2025 at 20:44):I was finally able to reproduce a working configuration in a test environment to confirm no regression. wkg 0.13 was just released with the above fix.
Theodore Brockman (Nov 19 2025 at 20:30):@Lann Martin thanks for merging the fix, finally got back around to what I was doing here (setting up a GitHub Action to publish WIT changes), and can confirm that it now works as expected!
Last updated: Dec 06 2025 at 06:05 UTC