archipelagoandClaude Opus 5
cbfda30579
Demo images / Build & push demo images (push) Failing after 2m22s
The app store offered "update to 2.3.9" on a node already running 2.4.2 — the release that fixes an actively exploited 2FA bypass. Taking it would have rolled the node back onto the vulnerable version. Root cause: available_update_for_images compared tags for inequality only. Same repo + different tag meant "update available", with no ordering. Every version claim upstream of it can go stale — the signed catalog, a legacy catalog entry, the image-versions.sh baseline pin — and any one of them lagging turned into a backwards Update button. Guard added: when both tags parse as dotted-numeric versions, a lower pinned version is never offered. Tags that cannot be ordered (RELEASE.2024-11-07…, 14-vectorchord0.4.3) keep the previous behaviour rather than silently losing updates. This makes stale data fail safe, which matters more than any single pin being correct. Four sources still named 2.3.9, three of them able to act on it: - releases/app-catalog.json — a LEGACY `btcpay` entry, distinct from `btcpay-server`, carrying a concrete 2.3.9 image. catalog_primary_image treats that as authoritative, so this is what drove the button. Fixed, but held back from this commit: it needs re-signing. - scripts/image-versions.sh — the baseline pin used when the catalog does not cover an app. - stacks.rs — the legacy BTCPay installer, twice. The fallback install path would have deployed 2.3.9 outright. - neode-ui curatedApps/marketplaceData and public/catalog.json — the store's displayed version, hardcoded rather than read from the catalog, which is why it still showed 2.3.9 after the update landed. Audited every other installer for the same shape. The remaining literals are the immich stack, which currently agrees with its manifests; hits in set_config.rs and app_catalog.rs are test fixtures. To keep it that way, scripts/check-installer-image-pins.py asserts that any installer literal naming the same repository as an app manifest carries the same tag, and runs blocking in CI. Verified it catches a simulated revert to 2.3.9. Tests: 13/13 in image_versions including the exact BTCPay case, a genuine upgrade still offered, equal versions silent, prerelease suffixes ordered on their numbers, and opaque tags unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>