feat: add sfw shims and checksum validation

[John-David Dalton (jdalton)]

Today, getting sfw to actually inspect your installs means remembering to write sfw in front of every package-manager command in your workflow. Miss one - run: npm install and that step quietly installs without sfw in the path — the job is green, the protection is not there, and nothing tells you.

With this change the action creates shims for the supported package managers, so npm install, pip install, cargo fetch and friends route through sfw on their own. Existing workflows that keep the sfw prefix still work; workflows that forget it are now covered instead of silently unprotected. Set shims: 'false' to keep the old explicit behaviour.

The second half is about trusting the binary you just downloaded. The sfw binaries are now pinned to a specific release with their SHA256 checksums embedded in the action, and every download is verified against those hashes before it is cached or run. Previously there was nothing checking that the bytes you got were the bytes that were published.

Shims — which commands are covered, and how a shim avoids calling itself

Shim scripts are created for the package managers sfw supports. The free edition covers npm, pnpm, yarn, pip, pip3, uv and cargo; enterprise adds bundler, gem, nuget and go. Both bash and .cmd shims are written, so Windows runners work from cmd.exe and PowerShell as well as Git Bash.

Each shim strips its own directory from PATH before invoking sfw, so sfw resolves the real package-manager binary instead of recursing back into the shim.

The shim directory is exported as SFW_SHIM_DIR, which lets a publish workflow temporarily turn the shims off (by renaming them to .disabled) for the steps where routing through sfw is not wanted.

Checksum validation — hardcoded hashes, no second download to trust

sfw binaries are pinned to v1.6.1, with a SHA256 recorded per platform and per edition (free and enterprise) directly in the action source. After download, the file is hashed and compared against that hardcoded value; a mismatch throws with both hashes printed rather than caching or executing the binary.

This deliberately avoids fetching a separate .sha256 file, since a checksum served from the same place as the artifact proves very little.

firewall-version still lets you override the version, but doing so now warns that checksum validation may fail, because the embedded hashes only describe the pinned release.

Windows path handling — MSYS paths confused sfw on Windows runners

Git Bash on Windows runners hands out MSYS-style paths such as /c/Users/.... sfw and PowerShell need the native form, C:\Users\..., to resolve binaries. Paths are now normalized to the native form before use.

Also in this PR — input ordering and README

• Inputs are alphabetized in action.yml and in src/main.js, so the two lists read in the same order.
• The README documents the shims, the checksum validation, which ecosystems are covered in the free versus enterprise editions, and how to bypass shims for publishing.

The test plan — unchecked; seven scenarios to confirm before merge

• Test firewall-free mode with shims enabled — verify npm install routes through sfw
• Test firewall-enterprise mode with socket-token
• Test checksum validation passes for a valid binary download
• Test shims: 'false' still requires explicit sfw prefix
• Test on Linux x64 and macOS arm64 runners
• Test Windows .cmd shim scripts work in cmd.exe and PowerShell
• Test MSYS path normalization on Windows runners

[John-David Dalton (jdalton)]

Landed on main in bad87d6.

This could not be merged as-is: #14 onboarded the repo into the Socket fleet and refactored src/main.js and src/tools/firewall.js from default imports to named exports, which conflicted with six hunks here. The feature was ported onto the new module shape rather than merged — shims, the per-platform and per-edition SHA256 table, and the Windows MSYS path normalization are all intact, and the build, lint, and test gates pass.

Two latent bugs were fixed during the port: shimCmdsEnterprise was a module-level array that push('go') mutated across invocations, and the PATH restore sat inside the try so a throw would have left PATH clobbered.

One deviation: clearing the shim directory used fs.rm, which the fleet routes through safeDelete, pulling in 454 KB of bundle. Since the recursion defense is stripping the shim directory from PATH rather than the delete, the clear was dropped in favor of an idempotent mkdir.