Tags: docker/model-runner
Tags
fix(distribution): honor proxies in the guarded token-exchange client (… …#1040) * fix(distribution): honor proxies in the guarded token-exchange client The SSRF guard added for the pull and re-challenge paths validated the address handed to DialContext. With a proxy configured — which production transports always carry via http.ProxyFromEnvironment — that address is the proxy's, not the token realm's. Proxies commonly live on private or loopback addresses (corporate proxies, Docker Desktop's embedded proxy), so the guard rejected the proxy itself and every token fetch failed: failed to fetch anonymous token: Get "https://auth.docker.io/token?...": proxyconnect tcp: realm URL contains a disallowed IP address 127.0.0.1 Model pulls from any authenticated registry, Docker Hub included, broke in proxied deployments. Split the guarded client per request: direct connections keep the validating dialer pinned to the resolved IP (DNS-rebinding safe), while proxied connections validate the realm host at the request level and let the proxy connect. Exchange() now uses the same guarded client, which also fixes the hand-rolled push path silently bypassing the proxy by dialing the realm directly. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(distribution): address review feedback on guarded auth transport Wrap the proxied-path validation error as "realm URL rejected" to match Exchange(), and document that the local DNS resolution during proxied validation is a deliberate fail-closed choice. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
fix(distribution): validate token realm on pull and re-challenge paths ( #1038) * fix(distribution): validate token realm on pull and re-challenge paths CVE-2026-33990 was fixed only in the hand-rolled Exchange() used by the push flow. The pull path (remote.Image -> createResolver) and the push re-challenge authorizer build containerd's default authorizer, which follows the realm URL from a 401 WWW-Authenticate challenge without validating it, so a malicious registry can drive a token fetch at an internal address and turn Model Runner into an SSRF proxy. Guard the HTTP client containerd uses for token fetches via docker.WithAuthClient. Its dialer validates the resolved IP against the private/loopback/link-local blocklist and dials that exact address, covering the pull, push, and fallback resolvers uniformly instead of only the hand-rolled Exchange(). * test(distribution): add endpoint-level SSRF regression for model pull Drive the pull from POST /models/create through the manager, distribution client, and containerd resolver against a malicious registry that advertises a loopback token realm. Asserts the registry is contacted but the realm is never followed, so the internal service receives nothing. Fails without the WithAuthClient guard.
ci(release): keep image release on its own v* track (#1004) * ci(release): keep image release on its own v* track The release.yml resolver picked the newest release repo-wide via `gh release list --limit 1`, with no prefix filter. When the separate standalone-dmr track published `dmr-v0.1.0` (newest release overall), the container-image release grabbed it and ran it through the v* auto-bump logic. `${LATEST_TAG#v}` only strips a leading `v`, so `dmr-v0.1.0` was mangled into the invalid tag `vdmr-v0.1.1`, which was then baked into the server image, pushed as a git tag, and propagated downstream — breaking verify-docker-ce (server `vdmr-v0.1.1` vs CE client `v1.2.5`). Restrict the resolver to this workflow's own strict-semver (vX.Y.Z) scheme: - filter the GitHub release lookup to `^v[0-9]+\.[0-9]+\.[0-9]+$` - filter the git-tag fallback the same way (the `v*` glob also matched stray tags like `vdmr-v0.1.1`) - add a post-resolve guard that aborts prepare if RELEASE_TAG is not valid vX.Y.Z, so a malformed tag can never reach the image build or downstream release triggers The standalone `dmr` binary continues to release independently via release-dmr.yml on `dmr-v*` tags. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci(release): centralize semver pattern, harden release lookup Address PR review feedback: - Centralize the strict-semver pattern in a single RELEASE_TAG_PATTERN variable, reused by the release lookup, git-tag fallback, explicit-tag validation, and the final guard, so the rule can't drift between them. - Make the git-tag fallback trigger on "no semver match found" (not just "no releases exist"), covering the case where the newest 100 releases are all off-track (e.g. a burst of dmr-v*) and the true latest vX.Y.Z release falls outside the release-list window. git tag is unbounded, so it always finds the real latest semver tag. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci(release): surface gh failures and fix pipefail in tag fallback Address second-pass review feedback: - Stop swallowing `gh release list` stderr with `2>/dev/null`. Capture it and, on failure, emit a `::warning::` before falling back to git tags, so a broken release lookup is visible in the logs instead of silently degrading. - Document why `--limit 100` is sufficient (the unbounded git-tag fallback backstops the window). - Fix a pipefail hazard the previous commit introduced: under the default `bash -eo pipefail` shell, a no-match `grep` in the git-tag fallback exits non-zero and would abort the step (breaking the legitimate "fresh repo, no tags -> start at v0.1.0" path). Wrap it in `{ grep ... || true; }`. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Merge pull request #1002 from docker/llamacpp chore: bump llama.cpp verrsion for macOS and Windows
fix(registry): preserve mirror URL path prefix when resolving/pulling… … backend images (#987) * fix(registry): preserve mirror URL path prefix when building registry hosts RegistryHosts dropped the path component of a configured registry mirror and hardcoded the Registry v2 API root to "/v2" on the bare host. Mirrors served under a path prefix — notably a JFrog Artifactory repository path such as /artifactory/api/docker/<repo> — were therefore queried at the host root, missed, and the resolver fell back to registry-1.docker.io (403 behind a corporate proxy with no Hub egress). Preserve the mirror's path and append "/v2" to it, and re-parse scheme-less mirrors as https so the host and path are separated correctly. This applies to both tag resolution (ResolveDigest) and the image pull (PullPlatform), since both build hosts via RegistryHosts. Refs CSESC-1468. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(registry): handle scheme-less IP:port mirrors A scheme-less mirror using an IP address with a port (e.g. "127.0.0.1:5000") errored on the first url.Parse ("first path segment in URL cannot contain colon") and was silently skipped. Prepend the https scheme before parsing when the mirror has no scheme, so IP:port and host:port mirrors are parsed uniformly, and skip only when the resulting host is empty. Addresses review feedback on #987. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(registry): avoid doubling /v2 when mirror path already ends with it A mirror configured with an explicit "/v2" suffix (e.g. https://host/artifactory/api/docker/repo/v2) would otherwise produce a duplicated "/v2/v2" path. Only append "/v2" when the configured path does not already end with it. Addresses review feedback on #987. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * refactor(registry): extract mirror URL normalization into parseMirror helper Move the scheme-less parsing, path-prefix preservation and /v2 suffix handling out of the RegistryHosts closure into a documented parseMirror helper, keeping the host-building loop small and the normalization rules in one place. Addresses review feedback on #987. No behavior change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ci: remove fragile bump-pinata and update-docs jobs from release work… …flow (#933) Remove the bump-pinata and update-docs jobs from the release workflow. These jobs create PRs in external repos (docker/pinata and docker/docs) and are prone to failure due to private dependency authentication issues, which blocks the github-release job from creating the GitHub Release. The pinata bump and docs update PRs should be created manually or via separate dedicated workflows that don't gate the release.
PreviousNext