feat: supply-chain pinning (go commit hash + gh SHA256) via --pin on add/ensure/upgrade

[mcraq]

Summary

Adds opt-in supply-chain verification for both runtimes via a new --pin flag on add, ensure, and upgrade.

What is pinned

Runtime	Pin type	Verification point
go	Git commit hash from proxy.golang.org (Origin.Hash)	Before go install — re-fetches from proxy to detect substitution
gh	Per-platform SHA256 archive digest (asset.GetDigest())	After download, before extraction — hard-fails on mismatch

Usage

# Pin when adding
toolset add --pin go github.com/golangci/golangci-lint/cmd/golangci-lint@v1.64.8
toolset add --pin gh golangci/golangci-lint@v2.5.0

# Re-pin an existing tool
toolset ensure --pin go github.com/golangci/golangci-lint/cmd/golangci-lint@v1.64.8

# Upgrade to latest and re-pin
toolset upgrade --pin go github.com/golangci/golangci-lint/cmd/golangci-lint

The pin is stored in .toolset.json alongside the version. toolset sync enforces it on every fresh install. Tools without --pin are fully backward compatible.

Key design decisions

• Opt-in: existing lock files without pin unmarshal cleanly to optional.Empty
• go-runtime: uses ResolvedModPath (module root, not the cmd/ sub-path) to query the proxy — avoids 404s for tools like golangci-lint/cmd/golangci-lint
• gh-runtime: loops knownPlatforms (7 OS/arch combinations) at pin time and records a digest per platform, enabling cross-platform reproducibility
• Private go modules: silently return empty pin with a warning (proxy not accessible)
• upgrade --pin: clears stale pin then immediately fetches the new one

Testing

• go test ./... — all packages pass (unit tests for SHA256, mock proxy, findPinnedAsset, PIN mismatch rejection for both runtimes)
• task test:pin — 8 integration scenarios: add/ensure/upgrade happy path + tamper-rejection for both runtimes

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 61.62791% with 66 lines in your changes missing coverage. Please review.
✅ Project coverage is 38.62%. Comparing base (e1f45e5) to head (dfec057).

Files with missing lines	Patch %	Lines
internal/workdir/workdir.go	0.00%	24 Missing ⚠️
...nal/workdir/runtimes/runtime-github-release/pin.go	72.97%	9 Missing and 1 partial ⚠️
internal/workdir/runtimes/runtime-go/pin.go	70.58%	7 Missing and 3 partials ⚠️
cmd/toolset/main.go	0.00%	6 Missing ⚠️
.../workdir/runtimes/runtime-github-release/assets.go	78.26%	3 Missing and 2 partials ⚠️
internal/workdir/runtimes/runtime-go/runtime_go.go	73.33%	2 Missing and 2 partials ⚠️
...s/runtime-github-release/runtime_github_release.go	81.25%	2 Missing and 1 partial ⚠️
.../workdir/runtimes/runtime-github-release/verify.go	77.77%	1 Missing and 1 partial ⚠️
internal/workdir/runtimes/runtime-go/private.go	60.00%	1 Missing and 1 partial ⚠️
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #79      +/-   ##
==========================================
+ Coverage   31.77%   38.62%   +6.85%     
==========================================
  Files          20       23       +3     
  Lines        1775     1908     +133     
==========================================
+ Hits          564      737     +173     
+ Misses       1142     1076      -66     
- Partials       69       95      +26     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mcraq]

Fixes in this branch

1. Deterministic TestLocks rewrite

The problem
The original test used wall-clock timeouts to reason about lock state:

// Wait 1s — if ch hasn't closed, the goroutine must still be blocked
select {
case <-ch:
    t.Fatal("File should be locked")
case <-time.After(1 * time.Second):
}
unlock()
// Wait 1s — goroutine should have acquired the lock by now
select {
case <-ch:
case <-time.After(1 * time.Second):
    t.Fatal("File should be unlocked")
}

The second select is where it failed. flock.TryLockContext retries on a timer (retryDelay). After unlock(), the background goroutine could be anywhere in its retry sleep — worst case it needs nearly a full retryDelay before it tries again. The test's 1s window wasn't always enough.
No matter how you tune retryDelay, you're still playing a game of margins — not eliminating the race.
The fix: use context cancellation as a synchronization primitive
The key insight: flock.TryLockContext respects context cancellation. If the context is done and the lock can't be acquired, it returns an error immediately. This gives us a deterministic signal.
Subtest 1: Proving a held lock blocks

t.Run("held_lock_blocks_concurrent_locker", func(t *testing.T) {
    unlock, err := fs.Lock(ctx, file    unlock, err := fs.Lock(ctx, f
    defer unlock()
    // Cancel the context immediately before attempting a second     /    ca    // Cancel the context immediancel(ctx)
    cancel() // already cancelled
    _, err = fs.Lock(cancelCtx, filename)
    require.Error(t, err, "second Lock must fail while first is held")
})

With an already-cancelled context, TryLockContext attempts the lock once, fails (file is held), checks the context, sees it's done, and returns an error — no waiting, no scheduling races. The assertion is: "an already-cancelled lock attempt on a held file must error." That's alwayWith an already-cancelled context, TryLockContext attempts the releases the lock*

t.Run("unlock_allows_re_lock", func(t *testing.T) {
    unlock, err := fs.Lock(ctx, filename)
    require.NoError(t, err)
    unlock() // release
    unlock2, err := fs.Lock(ctx, filename)
    require.NoError(t, err)
    unlock2()
})

No goroutines. Lock, unlock, lock again — sequentially. If unlock didn't work, the second fs.Lock would block forever (caught by Go's test timeout). Deterministic because there's no concurrent actor to race against.
What was eliminated

Before	After
1 goroutine	0 goroutines
2x time.After(1s)	0 timers
~2s minimum runtime	~0ms runtime
Flaky under scheduler pressure	Always deterministic

---

2. Lint fix: remove unused helpers in pin_test.go

pin_test.go had three helper functions scaffolded during development that were never called in any test: ptr, makeRelease, makeAsset. golangci-lint's unused linter flagged all three. Removed them along with the now-unused go-github import.

[kazhuravlev]

Thanks for the contribution. This is an important change, so I’d like to review it carefully over the next few days.

[kazhuravlev]

Great work on this MR — the implementation is clean and well thought out. Thanks for the excellent contribution!