morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #8715] [Bug] ASAR inventory fails the whole archive on one negative-size entry (Figma .codesign placeholder); record-and-continue does not help #7522

New issue

Closed

opened 2026-11-03 03:17:10 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-11-03 03:17:10 +00:00

Owner

Originally created by @YUI-TIEN on GitHub (Nov 3, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8715

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Evidence, artifacts, or reconstruction

Observed behavior

analyze_javascript_application on Figma Desktop's app.asar fails before any analysis:

{"code":"artifact_operation_failed","category":"execution_failure",
 "details":{"operation":"analyze_javascript_application","reason":"format",
 "detail":"Malformed ASAR during inventory: .../Figma.app/Contents/Resources/app.asar"}}

The ASAR header JSON is valid. Its first entry is a placeholder:

".codesign": {"size": -1000, "offset": "0", "integrity": {"algorithm":"SHA256","hash":"e3b0c442...b855", ...}}

(the integrity hash is the SHA-256 of empty input). Every other entry is well-formed: after skipping only .codesign, all 99 packed files with integrity metadata match their recorded SHA-256 hashes.

Reproduction

Install Figma Desktop 126.7.10 (macOS).
MCP analyze_javascript_application with input_path = /Applications/Figma.app/Contents/Resources/app.asar, detail: "summary".
Observe the format failure above. Reproduced 1/1.
Extracting the archive while skipping the size < 0 entry and analyzing the directory succeeds.

I scanned 7 other local Electron apps (Discord, Notion, Claude, ChatGPT, Canva, and two others); none had negative-size entries, so this is specific to archives carrying this placeholder.

Expected behavior

Record the invalid entry as an integrity contradiction / explicit unknown and continue inventorying the remaining entries (at least under integrity_policy: "record-and-continue", which currently fails identically — see Additional context), instead of failing the whole archive. The current rejection is reasonable as the default if strictness is intended, but then record-and-continue should cover this case.

Impact and scope

Figma Desktop's main application archive cannot be analyzed at all without manual extraction. Unknown how many other apps ship a similar .codesign placeholder.

REA version

rea-agents 6.8.0 (npm, MCP stdio)

Runtime and platform

macOS 26.5, Apple Silicon (arm64), Node.js 24.22.2

Target and artifact context

Figma Desktop 126.7.10, app.asar 9,769,223 bytes, header JSON 28,032 bytes, 106 entries.

Interface

MCP

Earliest failure stage

Artifact inventory

Typed outcome or recovery expected

Partial inventory with an integrity contradiction for .codesign, or a typed failure naming the offending entry path and size so callers know what to skip.

Analysis or suspected cause

Source-only: the ASAR entry range check (metadata.size < 0 || !Number.isSafeInteger(metadata.size) ... → ArtifactReaderFailure("format", "ASAR entry range is outside its container")) appears to reject the archive as a whole. The surfaced message ("Malformed ASAR during inventory") also drops the entry path that the inner error contains.

Additional context

Tested: integrity_policy: "record-and-continue" (with source_paths: ["popout_binding_renderer.js"]) returns the identical Malformed ASAR during inventory failure, so the documented record-and-continue path does not reach this check.

Originally created by @YUI-TIEN on GitHub (Nov 3, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8715 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Observed behavior `analyze_javascript_application` on Figma Desktop's `app.asar` fails before any analysis: ```json {"code":"artifact_operation_failed","category":"execution_failure", "details":{"operation":"analyze_javascript_application","reason":"format", "detail":"Malformed ASAR during inventory: .../Figma.app/Contents/Resources/app.asar"}} ``` The ASAR header JSON is valid. Its first entry is a placeholder: ```json ".codesign": {"size": -1000, "offset": "0", "integrity": {"algorithm":"SHA256","hash":"e3b0c442...b855", ...}} ``` (the integrity hash is the SHA-256 of empty input). Every other entry is well-formed: after skipping only `.codesign`, all 99 packed files with integrity metadata match their recorded SHA-256 hashes. ### Reproduction 1. Install Figma Desktop 126.7.10 (macOS). 2. MCP `analyze_javascript_application` with `input_path` = `/Applications/Figma.app/Contents/Resources/app.asar`, `detail: "summary"`. 3. Observe the format failure above. Reproduced 1/1. 4. Extracting the archive while skipping the `size < 0` entry and analyzing the directory succeeds. I scanned 7 other local Electron apps (Discord, Notion, Claude, ChatGPT, Canva, and two others); none had negative-size entries, so this is specific to archives carrying this placeholder. ### Expected behavior Record the invalid entry as an integrity contradiction / explicit unknown and continue inventorying the remaining entries (at least under `integrity_policy: "record-and-continue"`, which currently fails identically — see Additional context), instead of failing the whole archive. The current rejection is reasonable as the default if strictness is intended, but then `record-and-continue` should cover this case. ### Impact and scope Figma Desktop's main application archive cannot be analyzed at all without manual extraction. Unknown how many other apps ship a similar `.codesign` placeholder. ### REA version rea-agents 6.8.0 (npm, MCP stdio) ### Runtime and platform macOS 26.5, Apple Silicon (arm64), Node.js 24.22.2 ### Target and artifact context Figma Desktop 126.7.10, `app.asar` 9,769,223 bytes, header JSON 28,032 bytes, 106 entries. ### Interface MCP ### Earliest failure stage Artifact inventory ### Typed outcome or recovery expected Partial inventory with an integrity contradiction for `.codesign`, or a typed failure naming the offending entry path and size so callers know what to skip. ### Analysis or suspected cause Source-only: the ASAR entry range check (`metadata.size < 0 || !Number.isSafeInteger(metadata.size) ...` → `ArtifactReaderFailure("format", "ASAR entry range is outside its container")`) appears to reject the archive as a whole. The surfaced message ("Malformed ASAR during inventory") also drops the entry path that the inner error contains. ### Additional context Tested: `integrity_policy: "record-and-continue"` (with `source_paths: ["popout_binding_renderer.js"]`) returns the identical `Malformed ASAR during inventory` failure, so the documented record-and-continue path does not reach this check.

bsakaguchi commented

2026-11-03 03:17:11 +00:00

Author

Owner

@chordpli commented on GitHub (Nov 3, 2026):

I'd like to take this one, if that works for you.

Reproduced on current main (b912ec184) with Figma Desktop 126.10.7 on macOS 26.5.2 (arm64). Its app.asar has the same .codesign entry (size: -1000, offset: "0"), and analyze_javascript_application fails with Malformed ASAR during inventory, both with the default policy and with integrity_policy: "record-and-continue".

The rejection comes from asarNodeSchema.parse(raw) in src/artifacts/AsarListing.ts (size is nonnegative()). asarFailure then wraps the Zod error into a generic format failure, which is why the entry path gets lost.

Plan: list an entry whose declared size is invalid with an explicit limitation and no readable content, so the rest of the archive still inventories, and keep the entry path and declared value in the reported fact. If you'd rather keep the whole-archive failure, I'll scope it down to a typed failure that names the entry path and size instead. I'll verify before and after against the real Figma archive.

@chordpli commented on GitHub (Nov 3, 2026): I'd like to take this one, if that works for you. Reproduced on current `main` (`b912ec184`) with Figma Desktop 126.10.7 on macOS 26.5.2 (arm64). Its `app.asar` has the same `.codesign` entry (`size: -1000`, `offset: "0"`), and `analyze_javascript_application` fails with `Malformed ASAR during inventory`, both with the default policy and with `integrity_policy: "record-and-continue"`. The rejection comes from `asarNodeSchema.parse(raw)` in `src/artifacts/AsarListing.ts` (`size` is `nonnegative()`). `asarFailure` then wraps the Zod error into a generic format failure, which is why the entry path gets lost. Plan: list an entry whose declared size is invalid with an explicit limitation and no readable content, so the rest of the archive still inventories, and keep the entry path and declared value in the reported fact. If you'd rather keep the whole-archive failure, I'll scope it down to a typed failure that names the entry path and size instead. I'll verify before and after against the real Figma archive.

bsakaguchi commented

2026-11-03 04:16:07 +00:00

Author

Owner

@YUI-TIEN commented on GitHub (Nov 3, 2026):

Thank you so much for picking this up, and for the careful reproduction and for tracing it back to the schema. That's really helpful.

Option 1 would be my preference, if that works for you: list the invalid entry with an explicit limitation and keep inventorying the rest of the archive. That matches the expected behavior in the report, and it's essentially what I'm doing locally as a workaround for now (skip the entry, then verify the remaining integrity hashes; all 99 matched for Figma).

Keeping the entry path and declared size in the reported fact sounds great. If it isn't too much trouble, it would also be nice for the entry path to survive into the surfaced error message, which would help with other malformed archives that option 1 might not cover.

Please feel free to ping me once there's a PR. I'd be glad to re-test it against Figma on my side. Thanks again!

@YUI-TIEN commented on GitHub (Nov 3, 2026): Thank you so much for picking this up, and for the careful reproduction and for tracing it back to the schema. That's really helpful. Option 1 would be my preference, if that works for you: list the invalid entry with an explicit limitation and keep inventorying the rest of the archive. That matches the expected behavior in the report, and it's essentially what I'm doing locally as a workaround for now (skip the entry, then verify the remaining integrity hashes; all 99 matched for Figma). Keeping the entry path and declared size in the reported fact sounds great. If it isn't too much trouble, it would also be nice for the entry path to survive into the surfaced error message, which would help with other malformed archives that option 1 might not cover. Please feel free to ping me once there's a PR. I'd be glad to re-test it against Figma on my side. Thanks again!

bsakaguchi referenced this issue

2026-11-03 07:16:59 +00:00

[GH-ISSUE #7522] [Bug] Automatic setup selects Grok Bot even though its connector requires manual registration #4469

bsakaguchi closed this issue

2026-11-04 12:09:26 +00:00