[PR #4573] [MERGED] fix(firmware): state that Unblob link targets are extraction-relative #6316

New issue

Closed

opened 2026-10-31 01:13:31 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:13:31 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/4573
Author: @Ganesh2325
Created: 10/16/2026
Status: ✅ Merged
Merged: 10/22/2026
Merged by: @morluto

Base: main ← Head: fix/firmware-link-target-provenance

📝 Commits (1)

d1050af fix(firmware): state that Unblob link targets are extraction-relative

📊 Changes

2 files changed (+21 additions, -0 deletions)

View changed files

📝 src/firmware/FirmwareProvider.ts (+15 -0)
📝 tests/boundary/firmware/firmwareIntegration.test.ts (+6 -0)

📄 Description

Fixes #4175

Problem

extract_firmware reports symlinks in unpublished_entries with a link_target read by readlink from Unblob's extracted tree (src/firmware/FirmwareFiles.ts). Unblob's safe-link handling rewrites absolute targets relative to the extraction root. So an OpenWrt link stored as /sbin/kmodloader comes back as kmodloader, and nothing in the Evidence says the value is derived rather than observed firmware content.

Change

This takes the second option from the issue: keep the published value and label its provenance. When the Unblob engine produced a result whose unpublished_entries include a symlink, the Evidence now carries a limitation. It says link_target comes from Unblob's extracted tree, not the firmware's filesystem metadata, and that a relative value may have been absolute in the image. Results without symlinks, and the Binwalk engine, are unchanged. No schema change.

Verification

npx vitest run tests/boundary/firmware/firmwareIntegration.test.ts: 35 passed. The existing link partial-extraction case now asserts the limitation is present, and the depth/dependency cases assert it is absent. Without the source change the link case fails (1 failed, 34 passed).
npx vitest run tests/boundary/firmware src/firmware src/domain/firmware: 78 passed.
npm run verify:test-discovery: all 1441 test files discovered exactly once.
npm run lint: exit 0. npm run typecheck: exit 0.

Not covered

The original stored targets are not recovered from filesystem-handler metadata. That would need handler-specific parsing and is a larger change.
I didn't re-run the real OpenWrt image or Unblob locally. The fake-producer boundary fixture was used.

This change was prepared with AI assistance.

Author readiness

Human owner: @Ganesh2325

I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
I declare this PR ready for initial maintainer review.

_{🔄 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/4573 **Author:** [@Ganesh2325](https://github.com/Ganesh2325) **Created:** 10/16/2026 **Status:** ✅ Merged **Merged:** 10/22/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/firmware-link-target-provenance` --- ### 📝 Commits (1) - [`d1050af`](https://github.com/morluto/rea/commit/d1050af9336df23dcc5326a7c1648d55ae4a989e) fix(firmware): state that Unblob link targets are extraction-relative ### 📊 Changes **2 files changed** (+21 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `src/firmware/FirmwareProvider.ts` (+15 -0) 📝 `tests/boundary/firmware/firmwareIntegration.test.ts` (+6 -0) </details> ### 📄 Description Fixes #4175 ## Problem `extract_firmware` reports symlinks in `unpublished_entries` with a `link_target` read by `readlink` from Unblob's extracted tree (`src/firmware/FirmwareFiles.ts`). Unblob's safe-link handling rewrites absolute targets relative to the extraction root. So an OpenWrt link stored as `/sbin/kmodloader` comes back as `kmodloader`, and nothing in the Evidence says the value is derived rather than observed firmware content. ## Change This takes the second option from the issue: keep the published value and label its provenance. When the Unblob engine produced a result whose `unpublished_entries` include a symlink, the Evidence now carries a limitation. It says `link_target` comes from Unblob's extracted tree, not the firmware's filesystem metadata, and that a relative value may have been absolute in the image. Results without symlinks, and the Binwalk engine, are unchanged. No schema change. ## Verification - `npx vitest run tests/boundary/firmware/firmwareIntegration.test.ts`: 35 passed. The existing `link` partial-extraction case now asserts the limitation is present, and the `depth`/`dependency` cases assert it is absent. Without the source change the `link` case fails (1 failed, 34 passed). - `npx vitest run tests/boundary/firmware src/firmware src/domain/firmware`: 78 passed. - `npm run verify:test-discovery`: all 1441 test files discovered exactly once. - `npm run lint`: exit 0. `npm run typecheck`: exit 0. ## Not covered - The original stored targets are not recovered from filesystem-handler metadata. That would need handler-specific parsing and is a larger change. - I didn't re-run the real OpenWrt image or Unblob locally. The fake-producer boundary fixture was used. This change was prepared with AI assistance. ## Author readiness Human owner: @Ganesh2325 - [x] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:13:31 +00:00