feat(vscode): verify private registries with local Docker credentials

[CptSchnitz]

What

Implements #22. A developer already logged in with docker login now gets real verdicts for that registry's images instead of a blanket unverifiable, and one who is not logged in is told once, with the fix attached.

The credential chain lands in packages/oci-registry, reached only through the package's existing single entry point. All four mechanisms are here, because the shallow reading of "use local Docker credentials" silently fails on the registry most likely to matter:

• Plaintext auths entries, decoded and sent as basic credentials.
• The global credsStore, invoked as a docker-credential-* subprocess.
• Per-registry credHelpers, same mechanism.
• Identity tokens, exchanged at the registry's OAuth token endpoint with a refresh-token grant.

That last one is not optional. An Azure Container Registry auths entry carries both an auth field and an identitytoken, and the auth decodes to a null-GUID username with an empty password — a placeholder, not a credential. A client that reads auth first sends useless basic credentials and collects a 401 from what is, for this organisation, the primary registry. Reading identitytoken first, and spending it as a refresh-token grant rather than as a password, is what makes it work.

Registries outside a known-public table are never contacted anonymously. The anonymous attempt would disclose a private repository name to whoever answers and buy nothing, since its 401 says no more than the config already did. Those resolve to a new needs-login verdict carrying the host, which is what makes an actionable prompt possible.

missing-credential splits into needs-login and authentication-failure, because only the first is actionable. The host rides on the needs-login arm alone, so a "log in to X" prompt is unbuildable without a host and no other reason can pretend to have one. The invariant from #17 is untouched: both are unverifiable, and unverifiable still produces no diagnostic.

The editor surface in apps/vscode is a notification naming the host, an action opening a terminal on docker login <host>, an action dismissing that registry permanently, and a status bar count. None of it is a diagnostic. Not having logged in to a registry is a fact about the developer's machine, not a defect in the values file, and a Problems panel that mixes the two teaches people to stop reading it. Dismissals persist in extension state rather than settings — a dismissal is not configuration, and it should not accumulate in a file the whole team has checked in.

Closes #22

The bug this found, which predates the branch

a1f6e15 fixes a false positive in the existing existence check that has been there since #31. A manifest GET against docker.io is redirected to Docker's marketing site, which answers 200, and fetch follows redirects — so every Docker Hub image came back as existing, missing tags included. Verified against the live hosts:

https://docker.io/v2/library/nginx/manifests/no-such-tag-xyz  -> 302 -> https://www.docker.com/ -> 200
https://registry-1.docker.io/v2/library/nginx/manifests/no-such-tag-xyz  -> 401

A false checkmark is the one wrong answer this feature cannot survive: the whole point of the mark is that it means something, and one that appears for every Hub reference means nothing, silently, while looking like success. The old test asserted the wrong URL, so the suite was holding the bug in place.

Requests now go to registry-1.docker.io while the verdict keeps naming the registry the file named. Those are deliberately two values — the checkmark appends a registry only when it differs from the file's, so reporting the endpoint would put registry-1.docker.io after every Hub image on screen. The test pins both halves separately.

It predates this branch, but this branch is what put Docker Hub on the anonymous-request list and taught the credential chain to find its login, so it is this branch that made the claim it breaks.

Two things worth a reviewer's attention

• Docker picks exactly one credential store per registry. A credHelpers entry naming a registry replaces the global credsStore rather than being tried ahead of it, and whichever applies falls through on a miss to the plaintext entry, never to the other store. Trying both would let this package verify with a credential docker pull would not send — a quieter kind of wrong than a failure, because it looks like agreement with the developer's shell while being something else.
• The bearer challenge's realm is chosen by whoever answered the manifest request, and the request built from it carries the credential. An http:// realm would have put a password or a refresh token on the wire in the clear at the say-so of a response header. Only https is accepted, with loopback exempted so a local registry — no certificate, nothing leaving the machine — keeps working. Refusing costs an authentication-failure, which renders nothing, so being strict here fails silent rather than wrong.

Two deliberate additions beyond #17

Both are cheap and both are judgement calls a reviewer may want to overturn:

• Basic challenge handling. Verify Helm values image references against container registries #17 specifies only the bearer-token challenge flow. A plain registry:2 answers with Basic, and the branch is three lines.
• DOCKER_CONFIG support and a helper-name guard. The helper name comes out of a config file any process can write and is interpolated into a command name, so it is validated at the spawn boundary rather than trusted.

Testing

• packages/oci-registry: 32 tests. Every acceptance criterion in Local Docker credentials end to end #22, driven through checkImageExistence with the Docker config contents and the helper subprocess runner injected, per Verify Helm values image references against container registries #17's testing decision — no test reaches into credentials.ts or authorize.ts.
• The ACR ordering rule is asserted by a test pairing an identity token with a usable password, so only the order can decide it. The ACR entry alone cannot prove the rule, because its empty password reaches the identity token whichever order the code reads in.
• apps/vscode: 44 tests. The prompt surface, plus wiring assertions that a needs-login registry notifies and raises no diagnostic, and that it notifies once per registry across files rather than once per file.
• local-docker-credentials.ts gained the tests it never had: DOCKER_CONFIG resolution, an absent config reading as "no config", the helper-name guard refusing a; rm -rf /, and a missing helper rejecting so the chain reads it as a miss.
• Mutation-checked rather than assumed: breaking the Docker Hub endpoint mapping, the store precedence, the realm guard, and the once-per-session prompts wiring each fails exactly its own test and nothing else.
• Full workspace format, lint, type-check, build, test, package via turbo, plus knip, all pass.

Known gaps

• The Docker config is re-read and a credential helper re-spawned for every image reference (oci-registry: the Docker config is re-read and a credential helper re-spawned for every image reference #38). Ten images on one private registry means ten keychain round trips. Left out deliberately: caching is Persistent result cache and request concurrency cap #27's subject and the fix should fall out of that design rather than be guessed at twice.
• common/nginx and other references naming no host are still unverifiable — nothing resolves a registry for them yet. That is Document registry and the Docker Hub fallback #23 (document-declared registry and the Docker Hub fallback) and Registry override set #25 (the override set).
• Verify Helm values image references against container registries #17's "unsupported registry" reason is still not modelled; unexpected-response absorbs it. The "authentication failure" gap flagged in feat(vscode): checkmark and hover for image reference results #37 is now closed.
• The status bar carries the login count only, not the override count. The override set is Registry override set #25.

🤖 Generated with Claude Code