fix: keep egress-policy=block when the cache host can't be resolved (#675)

[JPHutchins]

What

Under egress-policy: block, harden-runner must never silently downgrade itself to audit. Today it does, whenever it can't resolve the Actions cache host during arming. This PR makes that path fail closed (keep block) instead of fail open.

Fixes #675.

Why

In src/setup.ts, block-mode arming fetches the harden-runner-cacheKey cache entry only to discover the cache blob host and add it to the allowlist:

const response = await twirpClient.GetCacheEntryDownloadURL(request);
const url = new URL(response.signedDownloadUrl);   // throws when the entry doesn't exist
...
} catch (e) {
  core.info(`Unable to fetch cacheURL ${e}`);
  if (confg.egress_policy === "block") {
    core.info("Switching egress-policy to audit mode");   // ← fail OPEN
    confg.egress_policy = "audit";
  }
}

When the cache entry is absent — a cold cache, or (commonly) when the bootstrapping saveCache a few lines above loses the reservation race (Unable to reserve cache with key harden-runner-cacheKey, another job may be creating this cache) so the entry is never created — GetCacheEntryDownloadURL returns no signedDownloadUrl, new URL(undefined) throws TypeError: Invalid URL, and the catch sets egress_policy = "audit". The job then runs with no egress enforcement while the workflow says block, and the only signal is one info line. That's a fail-open in a security control (details and repro in #675). The v1 branch has the identical pattern.

The change

Both the v2 and v1 cache-service branches now keep block and emit a core.warning on a cache-host resolution miss, instead of downgrading. The cache host is only needed to allowlist harden-runner's own cache traffic; failing to resolve it must not disable the user's configured egress policy. (Left the policy-store 5xx fallback untouched — that's a separate path.)

Validation

Reproduced and fixed on a repo that hits the reservation race, running a burst of concurrent block-mode jobs (example.com egress canary; example.com is never allowlisted, so connected = enforcement is off):

Action	Arm path	Agent EgressPolicy	Canary
step-security/harden-runner@v2.20.0	lost the reserve race → cold fetch	audit	connected (leak)
this branch	lost the reserve race → cold fetch	block	could not connect (enforced)

Same repo, same race, same commit — the official action downgraded to audit and let egress through; this branch kept block and the canary was blocked. The jobs that won the reservation race resolved the cache host and held block on both, unchanged. dist/ is rebuilt (npm run build).

Note

I've implemented this as fail-closed by default, since silently disabling a configured security control is the bug. If you'd prefer it gated behind an opt-in input (e.g. fail-on-policy-downgrade: true, as floated in #675), happy to adjust.

Warning

LLM Disclosure

This PR was authored by claude-opus-4-8 on behalf of @JPHutchins, after tracing the fail-open in dist/pre/index.js/src/setup.ts and validating the fix against the reservation-race repro described in #675.

[JPHutchins]

Moved to draft to avoid LLM slop merge. Consider as proof of concept.