v1.5.2-rc.3

v1.5.2-rc.3

Full Changelog: v1.5.2-rc.2...v1.5.2-rc.3

[1.5.2-rc.3] — 2026-07-11

Added

• Informational version visibility for pinned tags (#498). A specific-precision, unlabeled, non-loose pinned tag (e.g. nginx:1.25.3) still gets digest-only comparison for update actions — that pin-gate behavior from rc.2 is unchanged — but the container result now carries a new updateInsight: { tag, kind } field showing the best newer same-family tag that exists in the registry, purely as information. It reuses the exact same strict-style family matching used for actionable updates (prefix + suffix/variant compatibility + matching numeric-segment count + CalVer leading-zero rules) — no exception is carved out for major-version jumps; strict matching never restricted those to begin with. One narrow widening is scoped to this informational channel only: a prerelease-pinned tag (e.g. 1.5.2-rc.1) can see its own bare GA release (1.5.2) here, but that never makes the bare GA release an actionable update candidate — the actionable path rejects it just as before, even under dd.tag.family=loose or a permissive dd.tag.include filter. What's new is exposing this comparison at all for pinned tags, since the pin gate itself already blocks acting on any of it. Ties at the same numeric version prefer the tag whose suffix template exactly matches the pinned tag's. This is additive only: updateAvailable, updateKind, and trigger dispatch are all unaffected, so nothing new fires because of it. On by default; opt out per watcher with DD_WATCHER_{name}_TAG_PIN_INFO=false. Surfaced in the UI as an informational "Newer available" badge next to the existing update-state badges.

Fixed

• dd.tag.family=loose no longer bypasses the suffix/variant guard in isSemverFamilyMatch(). A pinned nginx:1.2.3-ls132 container could previously be offered a bare 1.2.4 (wrong variant) as an update candidate under loose policy — loose mode was only ever meant to relax prefix equality and CalVer leading-zero rules, not let updates cross a suffix/variant boundary entirely. The guard now applies unconditionally regardless of policy.
• The candidate sort in sortSemverDescending() now prefers the exact-suffix-template match over a merely-compatible one when two candidates tie at the same numeric version (e.g. preferring 1.2.5-alpine over 1.2.5-alpine3.21 for a 1.2.3-alpine reference). Semver treats the suffix as a prerelease field, so without this fix the wrong variant could outrank the exact match purely on prerelease-string ordering.

Warning

Upgrade notes: behavioral changes, please read before updating. Three security-hardening fixes that change runtime behavior first shipped in 1.4.6 and carry through the entire 1.5 line. Anyone updating from a release older than 1.4.6 is affected, whatever version you land on (1.4.6, any 1.5.x, or later), because these changes sit across the 1.4.6 boundary rather than in one specific version. These are not deprecations: there is no compatibility shim or grace period, so a previously-working deployment can change behavior on upgrade.

1. OIDC login now requires authorization_endpoint in your provider's discovery metadata. The authorization-redirect allowlist no longer falls back to a broad same-origin match. Mainstream identity providers (Keycloak, Authentik, Authelia, Okta, Google, Entra/Azure AD, Zitadel, …) publish this field and are unaffected. If your /.well-known/openid-configuration does not advertise authorization_endpoint, OIDC sign-in will now fail closed — make sure the discovery document exposes it.
2. Unauthenticated rate-limit buckets now key on the TCP peer address instead of X-Forwarded-For. Behind a reverse proxy (nginx / Traefik / Caddy), all unauthenticated clients now share a single bucket (the proxy's address), regardless of DD_SERVER_TRUSTPROXY. Internet-facing or multi-user instances may begin to see unexpected 429 Too Many Requests on unauthenticated endpoints. Authenticated requests are keyed per session and are unaffected.
3. HTTP-trigger proxy URLs must now use the http:// or https:// scheme. Any other scheme (e.g. socks5://) is rejected at config load. Such values were previously accepted but only ever treated as an HTTP proxy — switch to an http(s):// proxy URL.