[PR #751] [MERGED] fix(firmware): validate configured executables #2213

New issue

Closed

opened 2026-10-16 21:15:45 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:15:45 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/751
Author: @kaoru0822-kitauji
Created: 10/6/2026
Status: ✅ Merged
Merged: 10/6/2026
Merged by: @N0zoM1z0

Base: main ← Head: fix/firmware-executable-validation

📝 Commits (1)

4503a82 fix(firmware): validate configured executables

📊 Changes

2 files changed (+101 additions, -6 deletions)

View changed files

➕ src/firmware/FirmwareCommand.test.ts (+79 -0)
📝 src/firmware/FirmwareCommand.ts (+22 -6)

📄 Description

Summary

require configured Binwalk/Unblob commands to resolve to readable, executable regular files before hashing or launch
require the configured prlimit resource limiter to be an executable regular file
report unusable paths as firmware capability/configuration failures instead of generic adapter or process failures

No separate issue: this is a reproduced configuration-admission gap in the newly added firmware provider.

Problem and evidence

resolveFirmwareCommand previously checked only X_OK after resolving the engine path. A directory therefore passed admission and failed later in launcher hashing with an untyped Error. Engine access/hash failures also escaped the capability error contract.

The resource-limiter path likewise checked only X_OK, so an executable directory was accepted and returned as launch configuration.

The two directory regressions failed on unchanged main:

the engine directory threw bare Error: Not a regular file
the limiter directory resolved successfully

A third regression covers a regular but non-executable engine file.

Change and scope

Validate the engine as readable, executable, and regular, and keep the existing SHA-256 computation inside the same admission boundary. Validate the limiter as executable and regular. Failures retain the exact configured/canonical path in AnalysisCapabilityUnavailableError.

Absolute-path requirements, pinned version checks, launch arguments, resource limits, process ownership, report parsing, and successful provider results are unchanged.

Validation

Passed:

focused firmware command/report tests (8 tests)
npm exec --package=typescript@5.9.3 -- tsc --noEmit
npm run lint
targeted oxfmt --check
npm run knip
npm run metadata:check
git diff --check

Baseline evidence:

both new directory regressions failed on unchanged main with the incorrect behaviors described above

Materially unverified locally:

no real Binwalk, Unblob, or util-linux prlimit workflow was run
the broader firmware boundary suite cannot verify owned-process cleanup because this sandbox has no mounted /proc
npm run check reaches the repository TypeScript 7 binary, which cannot resolve /proc/self/exe in this sandbox; the stable TypeScript 5.9.3 check passed, and hosted CI covers the repository gate

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/751 **Author:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Created:** 10/6/2026 **Status:** ✅ Merged **Merged:** 10/6/2026 **Merged by:** [@N0zoM1z0](https://github.com/N0zoM1z0) **Base:** `main` ← **Head:** `fix/firmware-executable-validation` --- ### 📝 Commits (1) - [`4503a82`](https://github.com/morluto/rea/commit/4503a82338213f801303114687b3146ca9f54baa) fix(firmware): validate configured executables ### 📊 Changes **2 files changed** (+101 additions, -6 deletions) <details> <summary>View changed files</summary> ➕ `src/firmware/FirmwareCommand.test.ts` (+79 -0) 📝 `src/firmware/FirmwareCommand.ts` (+22 -6) </details> ### 📄 Description ## Summary - require configured Binwalk/Unblob commands to resolve to readable, executable regular files before hashing or launch - require the configured `prlimit` resource limiter to be an executable regular file - report unusable paths as firmware capability/configuration failures instead of generic adapter or process failures No separate issue: this is a reproduced configuration-admission gap in the newly added firmware provider. ## Problem and evidence `resolveFirmwareCommand` previously checked only `X_OK` after resolving the engine path. A directory therefore passed admission and failed later in launcher hashing with an untyped `Error`. Engine access/hash failures also escaped the capability error contract. The resource-limiter path likewise checked only `X_OK`, so an executable directory was accepted and returned as launch configuration. The two directory regressions failed on unchanged `main`: - the engine directory threw bare `Error: Not a regular file` - the limiter directory resolved successfully A third regression covers a regular but non-executable engine file. ## Change and scope Validate the engine as readable, executable, and regular, and keep the existing SHA-256 computation inside the same admission boundary. Validate the limiter as executable and regular. Failures retain the exact configured/canonical path in `AnalysisCapabilityUnavailableError`. Absolute-path requirements, pinned version checks, launch arguments, resource limits, process ownership, report parsing, and successful provider results are unchanged. ## Validation Passed: - focused firmware command/report tests (8 tests) - `npm exec --package=typescript@5.9.3 -- tsc --noEmit` - `npm run lint` - targeted `oxfmt --check` - `npm run knip` - `npm run metadata:check` - `git diff --check` Baseline evidence: - both new directory regressions failed on unchanged `main` with the incorrect behaviors described above Materially unverified locally: - no real Binwalk, Unblob, or util-linux `prlimit` workflow was run - the broader firmware boundary suite cannot verify owned-process cleanup because this sandbox has no mounted `/proc` - `npm run check` reaches the repository TypeScript 7 binary, which cannot resolve `/proc/self/exe` in this sandbox; the stable TypeScript 5.9.3 check passed, and hosted CI covers the repository gate --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-16 21:15:45 +00:00