Skip to content

fix(cli): verify PTY binary integrity before execution#16

Open
Catafal wants to merge 1 commit into
lunel-dev:mainfrom
Catafal:fix/pty-binary-integrity
Open

fix(cli): verify PTY binary integrity before execution#16
Catafal wants to merge 1 commit into
lunel-dev:mainfrom
Catafal:fix/pty-binary-integrity

Conversation

@Catafal
Copy link
Copy Markdown

@Catafal Catafal commented Apr 10, 2026

Summary

Fixes #10 — PTY binaries downloaded and executed with no integrity verification.

The CLI fetches a native binary from GitHub Releases and spawns it directly. Without a checksum check, a compromised release asset, a MITM with a valid cert, or local filesystem tampering could cause arbitrary native code execution on the user's machine.

Changes

cli/src/index.ts

  • PTY_RELEASES: added sha256 field with pinned hashes for all three platform targets (verified against the published v0 release assets)
  • downloadPtyBinary: computes SHA-256 of the assembled Buffer in-memory before fs.writeFile. On mismatch: throws immediately — no bytes hit disk, no temp file left behind
  • ensurePtyBinaryReady: reads and hashes the cached binary after fs.access confirms existence. On mismatch: deletes the stale file and re-downloads (auto-recover rather than hard-fail, since a CLI version bump may bring a new binary)
  • crypto import: added createHash (Node built-in, no new dependencies)

Pinned hashes (v0 release assets, verified 2026-04-10)

Platform File SHA-256
linux:x64 lunel-pty-linux-x8664-0 422c260e...
darwin:arm64 lunel-pty-macos-arm64-0 8d2fc8cf...
win32:x64 lunel-pty-windows-x8664-1.exe c80c5220...

Note for maintainers: when a new PTY binary is published, the sha256 values in PTY_RELEASES must be updated alongside the fileName/url. The verification is intentionally fail-closed — an outdated hash will prevent the CLI from running the PTY until the hash is updated.

Testing

  • GIVEN a clean install (no cached binary); WHEN CLI starts; THEN binary downloaded, hash verified, execution proceeds normally
  • GIVEN a cached binary with correct hash; WHEN CLI starts; THEN hash verified, no re-download
  • GIVEN a cached binary with wrong hash; WHEN CLI starts; THEN binary re-downloaded, new hash verified
  • GIVEN a download returns a tampered binary; WHEN hash check runs; THEN hard error thrown, no file written to disk

The CLI was downloading a native PTY binary from GitHub Releases and
executing it without any integrity check. Cached binaries were also
trusted unconditionally on subsequent runs — a local filesystem
replacement would be silently executed.

- Pin SHA-256 hashes for all three platform targets in PTY_RELEASES
- Verify the downloaded binary's hash in-memory before writing to disk;
  a mismatch aborts cleanly with no artifact on the filesystem
- Verify cached binary hash in ensurePtyBinaryReady before returning
  the path; re-download automatically on mismatch (recover rather than
  hard-fail, since a stale cache from a previous CLI version is likely)
- Add createHash to the crypto import (no new dependencies)

Fixes lunel-dev#10

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CLI should verify integrity of downloaded PTY binaries before execution

1 participant