sha256sum input is ignored on the use-cache hit path

Bắt đầu trong src/main.ts tại installTailscale(), phần return khi cache hit và calculateFileSha256() quanh dòng 394; so sánh các phần này với cách xử lý checksum trong installTailscaleLinux() và installTailscaleWindows(). Xác minh rằng artifact được lưu trong cache có checksum khớp sẽ tiếp tục được xử lý, trong khi checksum không khớp sẽ chuyển sang một lượt tải xuống mới đã được xác minh, đồng thời xác nhận rằng hành vi cài đặt hiện có vẫn được giữ nguyên.

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