sha256sum input is ignored on the use-cache hit path

Inizia in src/main.ts, in installTailscale(), nel return in caso di cache hit e in calculateFileSha256() intorno alla riga 394; confronta questi elementi con la gestione dei checksum in installTailscaleLinux() e installTailscaleWindows(). Verifica che un artefatto in cache corrispondente proceda, mentre un checksum non corrispondente porti a un nuovo download verificato, e conferma che il comportamento dell'installazione esistente rimanga invariato.

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