What happened
The sha256sum input is silently ignored when a cached install is restored. Only the fresh-install path verifies the checksum, so pinning sha256sum and enabling use-cache at the same time gives weaker guarantees than the configuration suggests.
Details
In installTailscale() (src/main.ts:341), a cache hit installs and returns before any verification:
if (config.useCache && cacheKey) {
const cacheHit = await cache.restoreCache([toolPath], cacheKey);
if (cacheHit) {
core.info(`Found Tailscale ${config.resolvedVersion} in cache: ${toolPath}`);
if (runnerOS === runnerWindows) {
await installTailscaleWindows(config, toolPath, true);
} else {
await installCachedBinaries(toolPath, runnerOS);
}
return; // <- returns here; no checksum comparison above this point
}
}
// Install fresh if not cached
config.sha256Sum is only ever read afterwards, in installTailscaleLinux() (src/main.ts:416-438) and installTailscaleWindows() (src/main.ts:509-523) — both reachable only after that return. So on a cache hit, a user-supplied sha256sum has no effect at all.
Since @actions/cache is a remote cache writable by workflows in the repo, a poisoned or corrupted entry is installed without verification, and the binary then receives the tailnet credentials.
Why this matters
sha256sum is the only way to avoid trusting pkgs.tailscale.com to attest its own artifact — without it, the action fetches the .tgz.sha256 from the same host that serves the .tgz (src/main.ts:416-425), so a compromised CDN could serve a matching bad pair. Users who supply the input specifically to move that trust anchor into their own repo currently must also set use-cache: false to get the verification they asked for, which costs them the caching benefit entirely. The two features aren't composable today.
It's also a bit of a footgun: the config reads as "pinned and verified," and nothing in the log indicates the pin was skipped on a cache hit.
Expected
A supplied sha256sum is honored on every install path. Concretely, on a cache hit, hash the restored artifact and compare against config.sha256Sum, treating a mismatch as a cache miss (fall through to a fresh, verified download) rather than failing the run. calculateFileSha256() (src/main.ts:394) already exists for this. That would make use-cache: true + sha256sum safe to combine.
Workaround
Set use-cache: false whenever sha256sum is supplied, which is what we do.
Version
tailscale/github-action@v4
What happened
The
sha256suminput is silently ignored when a cached install is restored. Only the fresh-install path verifies the checksum, so pinningsha256sumand enablinguse-cacheat the same time gives weaker guarantees than the configuration suggests.Details
In
installTailscale()(src/main.ts:341), a cache hit installs and returns before any verification:config.sha256Sumis only ever read afterwards, ininstallTailscaleLinux()(src/main.ts:416-438) andinstallTailscaleWindows()(src/main.ts:509-523) — both reachable only after thatreturn. So on a cache hit, a user-suppliedsha256sumhas no effect at all.Since
@actions/cacheis a remote cache writable by workflows in the repo, a poisoned or corrupted entry is installed without verification, and the binary then receives the tailnet credentials.Why this matters
sha256sumis the only way to avoid trustingpkgs.tailscale.comto attest its own artifact — without it, the action fetches the.tgz.sha256from the same host that serves the.tgz(src/main.ts:416-425), so a compromised CDN could serve a matching bad pair. Users who supply the input specifically to move that trust anchor into their own repo currently must also setuse-cache: falseto get the verification they asked for, which costs them the caching benefit entirely. The two features aren't composable today.It's also a bit of a footgun: the config reads as "pinned and verified," and nothing in the log indicates the pin was skipped on a cache hit.
Expected
A supplied
sha256sumis honored on every install path. Concretely, on a cache hit, hash the restored artifact and compare againstconfig.sha256Sum, treating a mismatch as a cache miss (fall through to a fresh, verified download) rather than failing the run.calculateFileSha256()(src/main.ts:394) already exists for this. That would makeuse-cache: true+sha256sumsafe to combine.Workaround
Set
use-cache: falsewheneversha256sumis supplied, which is what we do.Version
tailscale/github-action@v4