Publication freshness

Check D10 · provenance family · automatic · one of the 11 Docker Desktop checks

The question this check asks: when was this extension's image last pushed to Docker Hub? Not when the repository was created — that is D2 — but how long the image you would install has sat unchanged. On most platforms that is a maintenance signal. On this one it is mostly a description of the marketplace, and D10 is weighted accordingly: a note on the report, never a point off the score.

Why it matters

The platform has moved under the extensions. In six weeks of 2026 Docker Desktop added a security notice to the Extensions settings page (4.72.0, 6 May: extensions "run with host-level privileges and are not audited by Docker"), turned extensions off by default (4.74.0, 19 May), moved marketplace installs and updates to a pinned manifest digest instead of a tag (4.77.0, 8 June, "protecting against tag mutation after publication"), and on 16 June paused new marketplace submissions "while Docker reviews Marketplace security" — a pause with no published reason and no resume date. Existing extensions may still update: the same callout says "You can still update existing extensions, and private Marketplace extensions are unaffected." Most have not. Of the 50 listed extensions, 33 had not pushed in the twelve months before 18 September 2026; the newest listed repository was registered in May 2024; the youngest listing is 853 days old and the median 1,447 — four years.

So the date matters as context rather than as an alarm. An image last pushed years ago was built for the SDK API named in its com.docker.desktop.extension.api.version label, against a Docker Desktop that has since changed its defaults around it. If that image also declares a backend beside the Docker socket (D7) or native binaries copied onto your machine (D6), the push date tells you how long that surface has stood unrevised — and, read the other way, that nothing has been slipped into it lately either. A roster that reads the Hub record has the date for free, and a report that says "last pushed 1,200 days ago" beside a socket mount is more honest than one that leaves the reader to look it up.

How RepoGates scores it

D10 reads one field of the Docker Hub repository record, last_updated — the time of the last push to the repository on any tag — and compares it with the engine's dde_stale_days threshold, 365. Past it, the finding is dde-stale, INFO, no points, with the report line "last pushed N days ago — most of the marketplace is; a note, not a fault". The scoring table's evidence note:

"D10; not pushed for a year — 33 of the 50 listed extensions; a note"

The verdict engine is the one behind all 11 checks: any CRITICAL finding is a BLOCK, any HIGH or MEDIUM finding is a REVIEW, and a report with nothing above INFO is a PASS — so D10 alone never moves a verdict, and a listing with D10 as its only finding scores 100. All three shipped profiles map INFO to allow, and none of them names dde-stale: the strict profile's block on the GitHub roster's stale finding is matched by its own name and does not reach this one. On the preflight the note rides along in the response and asks nothing. D10 feeds the Clone the source dimension with D1–D5 and D8; a dimension takes the worst of its checks, so a note leaves it where the others put it. Because the Hub record is what every verdict is built on, D10 is never listed as not checked: if the record cannot be read there is no verdict at all, and the report says the extension is not assessable rather than passing it.

False positives we know about

Thirty-three of fifty. In the 18 September 2026 measurement of all 50 listed extensions, run locally through the same code as /v1/dde/score, dde-stale fired on 33 — the majority of the marketplace, including extensions that are simply finished, a small tool with nothing left to change. Every one was a note; the run was 50 PASS, 0 REVIEW, 0 BLOCK, and no note moved a verdict. Weighted as the GitHub roster weights its stale-push finding, D10 would have put most of Docker's own marketplace into REVIEW for the crime of being frozen by Docker. That is the measurement behind the weighting, and it is why this page calls the check a description rather than a detection.

The threshold is a plain 365 days from the moment of the scan, so a listing crosses it on a particular morning with no change in the image. A push clears it the same way: the Hub record updates, and the next cold scan reads the new date.

What this check does not cover

What the push changed. A rebuild of identical code moves last_updated as far as a rewrite does, and D10 reads the date, not the layers; what the image declares is read by D6 and D7 from the registry, and what it does is not read at all. Whether the extension still works with the Docker Desktop you run — the date says how old the build is, not whether it loads. Which tag the date belongs to: the Hub record is per repository, and a push to any tag counts. Whether anyone is answering for the code — for that the roster goes to the declared source repository, which D8 sends through the 22 GitHub checks, where C7 reads commits, releases and archive status; 23 of the 50 listed extensions declare no source, and for those the push date is the only activity signal there is. And the flip side of a frozen marketplace: a marketplace install since 4.77.0 is by pinned digest, but an image installed by reference from outside the index is whatever its tag points at, and a fresh push to such a tag is exactly the case D10 does not flag — freshness is not the shape it looks for.

RepoGates assesses a Docker Desktop extension on request — through the API, the MCP server (platform="dde") and the preflight for docker extension install. It does not see an extension installed from Docker Desktop's own Extensions Marketplace tab, which is the app's own fetch; the board inside Docker Desktop is not built, and cannot be — its marketplace is a native window no browser extension sees. The image is never pulled and its code is not read: a PASS means the provenance and the declared install surface are clean, never that the backend or the host binaries were inspected.

Check it yourself

The Hub's repository API answers without a token. For tailscale/docker-extension, the record carries the push date beside the fields D2 and D3 read:

curl -s https://hub.docker.com/v2/repositories/tailscale/docker-extension/ \
  | jq '{last_updated, date_registered, pull_count, star_count}'

To see which tag moved last, list the tags; each carries its own last_updated:

curl -s 'https://hub.docker.com/v2/repositories/tailscale/docker-extension/tags/?page_size=10' \
  | jq '.results[] | {name, last_updated}'

Then ask RepoGates for its reading. With a personal API token from the account page, the note is one row of the findings:

curl -s -H "Authorization: Bearer rgp1.…" \
  https://api.repogates.com/v1/dde/score/tailscale/docker-extension \
  | jq '.findings[] | select(.check == "dde-stale")'

From an agent, check_repo("tailscale", "docker-extension", platform="dde") on the MCP server returns the same rows; with the plugin installed in Claude Code, a line that reads docker extension install tailscale/docker-extension is sent to the preflight before it runs, and a note is a note — the command proceeds with Claude Code's own prompt, and the response carries the date for whoever reads it.

Questions

Is an extension that has not pushed in a year a red flag? No. In the 18 September 2026 measurement of all 50 listed extensions, dde-stale fired on 33 of them — the majority of the marketplace — as INFO with no points, and none of the 33 moved a verdict. Docker paused new marketplace submissions on 16 June 2026 and the newest listed repository was registered in May 2024, so a year of silence is what this marketplace looks like. D10 is a note, not a fault, and it says so in its own report line.

Where does the date come from? From the Docker Hub repository record — the last_updated field of /v2/repositories/{owner}/{name}/, the time of the last push to the repository on any tag. RepoGates compares it with the engine's dde_stale_days threshold, 365 days. The Hub record is read for every verdict, so D10 always runs when there is a verdict at all; there is no state in which it is listed as not checked.

Does a recent push mean the extension is maintained? It means an image was pushed. D10 does not see what changed — a rebuild of the same code moves the date as much as a rewrite does — and it does not read the image. Whether anyone is answering for the code is a question for the declared source repository, which D8 sends through the 22 GitHub checks, where C7 reads real activity. On this platform the freshest signal the roster has is a push to a listing that has been silent for years, and D10 records the silence so that the change is visible when it comes.

Related checks

D2 Extension age — the other date on the same Hub record: when the repository was created, and the check that fires on nothing listed today · C7 Maintenance activity — the GitHub analogue, which reads commits and releases and does carry weight · V10 Pre-release and re-publish cadence — the VS Code Marketplace's version of the timing question · D8 Source repository — where the maintained-or-not question gets a real answer, when a source is declared.

Add RepoGates to Chrome Pricing

Numbers on this page: the 18 September 2026 measurement of all 50 listed Docker Desktop extensions (50 PASS / 0 REVIEW / 0 BLOCK; 33 not pushed in a year; youngest listing 853 days, median 1,447; newest listed repository registered May 2024; 23 declare no source); Docker Desktop release notes for 4.72.0, 4.74.0 and 4.77.0 and the marketplace pause callout of 16 June 2026 on docs.docker.com; weights from the product's scoring table.