morluto/rea

Fork 0

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

[GH-ISSUE #8434] [Design] Should more fixed allowances get a capped, opt-in override? #6606

New issue

Open

opened 2026-11-01 21:12:37 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-11-01 21:12:37 +00:00

Owner

Originally created by @CassieFox23 on GitHub (Nov 1, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8434

TL;DR: Many of REA's input limits are fixed. A file padded just past one of them stops that step, and nothing in REA raises the limit. Should the size and count limits get a capped, opt-in override, like the asar header setting has?

Before submitting

I searched the open and closed issues and pull requests for a related discussion.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

Should REA add a capped, opt-in override for fixed size and count limits that a file can be padded past? Or should they stay fixed on purpose?

Context and evidence

Everything here comes from reading the source at 6e9ee97a69. I ran nothing.

REA already has two ways to raise a limit:

A session setting with a ceiling. asar.max_header_bytes starts at 16 MiB and goes up to 256 MiB (src/domain/analysisResourceLimits.ts:7 and :15). The error names the setting (src/artifacts/AsarHeader.ts:49).
A per-call input with a ceiling. max_chunks for BEAM files starts at 64 and goes up to 256. The error says to raise it (src/erlang/BeamProvider.ts:103-106).

Many other limits are fixed, and the errors say so plainly. One example is "This release has no runtime override" (src/evm/EvmoleFailures.ts:206). The table below lists six fixed limits that a file sets by its own size, count or depth.

Padding a file past a fixed limit is cheap. So a file can be built to make REA refuse it, and the analyst then has no way past that step inside REA.

I did not check whether files from normal builds ever hit these limits.

Six fixed limits a file can push past (source at 6e9ee97a69)

Limit	Value	Where
Go build-info string	1 MiB	`src/go/GoBinaryImage.ts:23`, checked at `:279` and `:330`
TShark JSON output	8 MiB	`src/pcap/PcapOutput.ts:14`, checked at `:173`
WebAssembly interface representation	32 MiB	`src/domain/wasm/wasmInterface.ts:90`
EVM interface input	4 MiB	`src/evm/EvmoleRelease.ts:13`
Electron fuse sentinels per slice	32	`src/electron/ElectronFuseReader.ts:38`, checked at `:369`
GGUF metadata and safetensors JSON nesting	32 levels	`src/model/ModelFormat.ts:52-53`

Expected interaction with targets

Read existing files or captured data
Recover protected code or work around protections

Boundary details (optional)

An override would only raise a limit up to a fixed ceiling, and only when the caller asks. The defaults stay as they are. The nesting limits may need to stay fixed if they protect the parser's stack. I did not trace that.

Options and tradeoffs

Keep them fixed. This is the simplest, and the refusal is already clear. A padded file stops that step for good.
One setting per limit, with a ceiling, like asar.max_header_bytes. It is clear and opt-in, but every setting needs docs and tests.
A per-call input with a ceiling, like max_chunks. This fits tools that already take budget inputs.
Partial results. Stop at the limit and return what fits, marked as cut. This is more work, and some formats may not allow it.

Verification available so far

I can suggest a sample or manual check

Success criteria and open questions

A file padded past a default limit gets analyzed once the caller raises that limit, up to the ceiling.
Past the ceiling, the error stays as clear as it is now.
Open question: do files from normal builds ever hit these limits? I don't know.
A possible check is a small Go test binary with a padded build-info string. I have not built one.

References

src/domain/fixedAllowanceRemediation.ts, which names and explains the fixed limits.
src/domain/analysisSettingDefinitions.ts, which holds the 12 current settings.
#7159 made one native limit a setting. It merged on 25 Oct.

🤖 Written with Claude Code (Opus 5.5), posted with my OK 🦊

Originally created by @CassieFox23 on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8434 **TL;DR:** Many of REA's input limits are fixed. A file padded just past one of them stops that step, and nothing in REA raises the limit. Should the size and count limits get a capped, opt-in override, like the asar header setting has? ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed Should REA add a capped, opt-in override for fixed size and count limits that a file can be padded past? Or should they stay fixed on purpose? ### Context and evidence Everything here comes from reading the source at 6e9ee97a69. I ran nothing. REA already has two ways to raise a limit: - **A session setting with a ceiling.** `asar.max_header_bytes` starts at 16 MiB and goes up to 256 MiB (`src/domain/analysisResourceLimits.ts:7` and `:15`). The error names the setting (`src/artifacts/AsarHeader.ts:49`). - **A per-call input with a ceiling.** `max_chunks` for BEAM files starts at 64 and goes up to 256. The error says to raise it (`src/erlang/BeamProvider.ts:103-106`). Many other limits are fixed, and the errors say so plainly. One example is "This release has no runtime override" (`src/evm/EvmoleFailures.ts:206`). The table below lists six fixed limits that a file sets by its own size, count or depth. Padding a file past a fixed limit is cheap. So a file can be built to make REA refuse it, and the analyst then has no way past that step inside REA. I did not check whether files from normal builds ever hit these limits. <details> <summary>Six fixed limits a file can push past (source at 6e9ee97a69)</summary> | Limit | Value | Where | |---|---|---| | Go build-info string | 1 MiB | `src/go/GoBinaryImage.ts:23`, checked at `:279` and `:330` | | TShark JSON output | 8 MiB | `src/pcap/PcapOutput.ts:14`, checked at `:173` | | WebAssembly interface representation | 32 MiB | `src/domain/wasm/wasmInterface.ts:90` | | EVM interface input | 4 MiB | `src/evm/EvmoleRelease.ts:13` | | Electron fuse sentinels per slice | 32 | `src/electron/ElectronFuseReader.ts:38`, checked at `:369` | | GGUF metadata and safetensors JSON nesting | 32 levels | `src/model/ModelFormat.ts:52-53` | </details> ### Expected interaction with targets Read existing files or captured data Recover protected code or work around protections ### Boundary details (optional) An override would only raise a limit up to a fixed ceiling, and only when the caller asks. The defaults stay as they are. The nesting limits may need to stay fixed if they protect the parser's stack. I did not trace that. ### Options and tradeoffs - **Keep them fixed.** This is the simplest, and the refusal is already clear. A padded file stops that step for good. - **One setting per limit, with a ceiling,** like `asar.max_header_bytes`. It is clear and opt-in, but every setting needs docs and tests. - **A per-call input with a ceiling,** like `max_chunks`. This fits tools that already take budget inputs. - **Partial results.** Stop at the limit and return what fits, marked as cut. This is more work, and some formats may not allow it. ### Verification available so far I can suggest a sample or manual check ### Success criteria and open questions - A file padded past a default limit gets analyzed once the caller raises that limit, up to the ceiling. - Past the ceiling, the error stays as clear as it is now. - Open question: do files from normal builds ever hit these limits? I don't know. - A possible check is a small Go test binary with a padded build-info string. I have not built one. ### References - `src/domain/fixedAllowanceRemediation.ts`, which names and explains the fixed limits. - `src/domain/analysisSettingDefinitions.ts`, which holds the 12 current settings. - #7159 made one native limit a setting. It merged on 25 Oct. 🤖 Written with Claude Code (Opus 5.5), posted with my OK 🦊

bsakaguchi commented

2026-11-01 21:12:38 +00:00

Author

Owner

@morluto commented on GitHub (Nov 1, 2026):

yes! i think so

@morluto commented on GitHub (Nov 1, 2026): yes! i think so

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#6606

No description provided.

Rows
Columns