morluto/rea

Fork 0

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

[GH-ISSUE #4110] [Design] Record scope for Unblob, FACT Core, and Binwalk-NG #1620

New issue

Open

opened 2026-10-16 21:08:04 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-16 21:08:04 +00:00

Owner

Originally created by @dandgabr on GitHub (Oct 15, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4110

[Design] Record scope for Unblob, FACT Core, and Binwalk-NG

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; unresolved boundaries block integration.
This discussion contains no credentials, private samples, or sensitive target data.

Decision

At the project owner's direction, record approval to pursue three separate, optional firmware integrations, one PR per tool: Unblob, FACT Core, and Binwalk-NG. “Complete support” means a source-backed inventory of each upstream tool’s documented analyst-facing CLI/API capabilities, followed by REA contracts for every compatible operation. It does not mean copying upstream behavior that conflicts with REA’s authority, evidence, local-only, resource, ownership, or output-safety rules. Any excluded upstream operation must be named with its reason; a later scope expansion requires a new decision.

Approved tool boundaries

Unblob: support its documented analyst-facing scan/report and selected recursive extraction behavior, including chunk boundaries, unknown/padding regions, entropy, supported-format/extractor diagnostics, and caller-configurable limits under mandatory REA hard ceilings. Caller-provided external extractors may run only when explicitly configured, path/version checked, owned and bounded by REA, and confined to selected input plus private staging/output. Do not install them automatically, overwrite existing output, or execute recovered files. Runtime-loaded custom plugins are excluded from the initial integration because they execute caller-supplied code; revisit them only through a separate scope decision.
FACT Core: support analyst-facing REST read/query operations and native export against a caller-selected local FACT instance, including metadata/status, comparisons, binary retrieval, search-result retrieval, and statistics where the pinned upstream version exposes them. Classify every endpoint from pinned source as read-only, state-consuming, enqueueing, or mutating; HTTP method names do not establish behavior. Search-result retrieval is a separate state-consuming operation because upstream results may be fetched only once. REST uploads, analysis updates, compare/search submissions, and other plugin-triggering operations are authorized by this decision only when the pinned deployment proves and enforces the approved plugin, scheduler, and network boundary; otherwise those operations remain unsupported. Native export runs only in a fresh REA-owned exclusive staging directory and publishes only verified output to the caller-selected destination. Native import is excluded from the initial integration because upstream can write database rows before storage files and can leave partial state; do not use force/override. Revisit import only with a verified transaction/recovery model. No delete, redo, service administration, or remote/network FACT target is included. Authentication credentials must never enter Evidence or logs. Support caller-supplied native and rootless Podman-existing deployments; no privileged container, host installation, or automatic runtime setup.
Binwalk-NG: treat binwalk-ng/binwalk-ng as a separate integration target by repository and pinned revision. It is a fork of ReFirmLabs Binwalk, whose v3 line is also a Rust rewrite; do not infer feature parity or divergence without the pinned-source matrix. Support its documented analyst-facing scan, signature/offset/entropy results, and caller-selected extraction/output behavior on native and caller-supplied container deployments. Extraction helpers are trusted caller-selected code operating on untrusted input; verify exact executable path/version, own and bound every process, and confine execution to read-only input plus private staging/output. Do not automatically load custom plugins, install tools, mutate host configuration, overwrite pre-existing output, or execute extracted files. Any upstream option that permits those effects must be omitted or constrained and listed in the compatibility matrix.

All three providers remain optional and share the same CLI/MCP workflows, named contracts, Evidence provenance, explicit partial/unknown results, process supervision, cancellation, resource budgets, and fail-closed cleanup. Inputs are read-only: use a read-only handle or private verified snapshot, verify source identity/digest before and after when applicable, and reject a mode that can modify or replace the caller's selected input. Caller-configurable budgets must stay below mandatory aggregate ceilings for expanded bytes, output file count, recursion depth, CPU/time, memory, and output storage. Temporary and final output must be exclusively created; partial output after a failure is reported as partial evidence and cleaned only when ownership is proven. Native executables are trusted caller-supplied code and may otherwise inherit the caller's OS authority; REA must not claim a sandbox unless it proves one. If the configured native execution boundary cannot enforce the approved filesystem/network/device restrictions, reject that mode or operation. Container invocation must use caller-provided container tools; REA does not build, pull, start, stop, remove, or reconfigure containers implicitly. Inspect the selected container's exact identity/image, effective mounts, network mode, namespaces, privilege/capability settings, and devices; reject sensitive host mounts, runtime sockets, device access, or unapproved network egress. Rootless alone is not proof of isolation. Native invocation uses caller-provided tools. The same caller-selected operation must have documented behavior in either mode where the provider supports both.

Context and evidence

Issue #718 and merged PR #741 established the first Binwalk v3 and Unblob milestone, not Binwalk-NG or full Unblob CLI/API parity. Issue #718 described FACT REST as a possible later connector, but did not decide on mutating REST calls, native import/export, or container execution. Searches of open/closed REA issues and PRs found no FACT_core or Binwalk-NG integration decision; existing Unblob discussions cover the initial implementation and follow-up fixes only.

The upstream FACT REST API documentation describes query, upload/update, compare, binary retrieval, binary search, statistics, system status, and authentication endpoints; the API is explicitly unversioned. Binwalk-NG’s upstream README describes identification and optional extraction and directs users to CLI help/wiki for advanced functions. Unblob documents recursive extraction, reports, entropy, depth/worker controls, plugin loading, and external extractors. The implementation plans must pin upstream revisions and maintain a capability-by-capability compatibility matrix instead of relying on these summaries.

References:

Expected target interaction

Read caller-selected local firmware/data; launch caller-selected local tool processes and, where applicable, external extraction helpers; write only caller-selected derived output. The included FACT operations are read-only queries, explicitly state-consuming one-shot result retrieval where documented, and export. One-shot retrieval uses a separate contract and explicit caller request that discloses consumption. Plugin-triggering REST operations may run only when the pinned deployment proves and enforces the approved plugin, scheduler, and network boundary; this decision authorizes them only under that gate. No extracted firmware program is launched. Device flashing/update, booting/emulation, JTAG/UART, glitching, and hardware control are excluded. REA and its child/helper processes contact only explicitly selected local services; helper egress is disabled, and operations requiring uncontrolled egress are rejected. Any different network behavior requires a new scope decision.

Boundary details

Inputs remain caller-selected; a file extension, signature, or FACT-reported label does not prove format or authorization.
Provider outputs distinguish observations, derivations, inferences, and unknowns and retain original source paths, digests, tool/version, operation, offsets, and failures.
Extraction output is created exclusively; symlinks/special files and path traversal are not materialized as regular output files. Existing outputs are never overwritten.
External extractors are not bundled or automatically installed. Any allowed helper must be explicitly configured, exact-path/version/capability checked, bounded, supervised, and restricted from network/device access. If native execution cannot enforce these limits, that helper operation is unsupported. Runtime custom plugins supplied to Unblob or Binwalk-NG are outside this initial approval. FACT plugin-triggering operations are authorized only when the pinned plugin/scheduler/network boundary is constrained and verified; otherwise they remain unsupported under this decision.
Native and container modes are separately verified. For Podman, REA must not manage container lifecycle or configuration; it may use only a caller-selected, inspected container that passes identity, mount, network, namespace, privilege, capability, and device checks. Reject root/home mounts, host/runtime sockets, devices, privileged containers, and network egress.
Hard aggregate ceilings apply regardless of caller settings: expanded bytes, file count, depth, CPU/time, memory, and output storage. If the runtime cannot enforce the required limits, that mode is unsupported.
FACT’s unversioned REST API requires a pinned compatibility profile, producer fixtures, explicit unknown handling, and redaction of transport authentication credentials. Read/write authority is reflected in CLI/MCP contracts.

Options and tradeoffs

Use three independent PRs/branches so each provider’s upstream matrix, runtime behavior, tests, and review can be accepted or deferred independently. Keep tool installation and container provisioning bring-your-own; this costs setup effort but avoids unrelated system changes and makes tool versions/authority explicit.

Verification available so far

A prototype exists on separate branches. Focused simulated tests and source-level checks are available. Real-provider verification is incomplete for current heads and must be reported per provider and per runtime mode; no real FACT database import/export is claimed by this decision record.

Success criteria and open questions

Before each integration PR:

Pin upstream commit/release and publish a complete documented-capability matrix (supported, constrained, or excluded with reason).
Validate exact named CLI/MCP contracts and Evidence/error semantics for each operation.
Verify native and caller-supplied container paths using real CLI/MCP workflows, with disposable fixtures; record selected input identity/digest before and after and prove source bytes remain unchanged. Verify FACT REST in a disposable FACT container, including plugin-triggering endpoints only when the actual plugin/scheduler is tested with enforced network isolation, and native FACT export against a disposable database and destination. Import remains outside initial acceptance.
Exercise malformed inputs, partial output, cancellation, cleanup failure, path/symlink boundaries, permission/capacity limits, and deterministic fuzz/property cases for included operations. Mutation testing must kill every predeclared safety, authority, and ownership mutant and kill at least 85% of applicable non-equivalent mutants; report the score and disposition of every survivor. Excluded FACT import is not part of initial PR acceptance.
Complete three independent review rounds per provider, including QA, reverse-engineering, and hardware-security lenses. Resolve all material findings before opening the PRs for the user’s final manual test.

Originally created by @dandgabr on GitHub (Oct 15, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4110 # [Design] Record scope for Unblob, FACT Core, and Binwalk-NG ## Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [x] I understand the contribution scope must be reviewed before integration; unresolved boundaries block integration. - [x] This discussion contains no credentials, private samples, or sensitive target data. ## Decision At the project owner's direction, record approval to pursue three separate, optional firmware integrations, one PR per tool: Unblob, FACT Core, and Binwalk-NG. “Complete support” means a source-backed inventory of each upstream tool’s documented analyst-facing CLI/API capabilities, followed by REA contracts for every compatible operation. It does not mean copying upstream behavior that conflicts with REA’s authority, evidence, local-only, resource, ownership, or output-safety rules. Any excluded upstream operation must be named with its reason; a later scope expansion requires a new decision. ### Approved tool boundaries - **Unblob:** support its documented analyst-facing scan/report and selected recursive extraction behavior, including chunk boundaries, unknown/padding regions, entropy, supported-format/extractor diagnostics, and caller-configurable limits under mandatory REA hard ceilings. Caller-provided external extractors may run only when explicitly configured, path/version checked, owned and bounded by REA, and confined to selected input plus private staging/output. Do not install them automatically, overwrite existing output, or execute recovered files. Runtime-loaded custom plugins are excluded from the initial integration because they execute caller-supplied code; revisit them only through a separate scope decision. - **FACT Core:** support analyst-facing REST read/query operations and native export against a caller-selected local FACT instance, including metadata/status, comparisons, binary retrieval, search-result retrieval, and statistics where the pinned upstream version exposes them. Classify every endpoint from pinned source as read-only, state-consuming, enqueueing, or mutating; HTTP method names do not establish behavior. Search-result retrieval is a separate state-consuming operation because upstream results may be fetched only once. REST uploads, analysis updates, compare/search submissions, and other plugin-triggering operations are authorized by this decision only when the pinned deployment proves and enforces the approved plugin, scheduler, and network boundary; otherwise those operations remain unsupported. Native export runs only in a fresh REA-owned exclusive staging directory and publishes only verified output to the caller-selected destination. Native import is excluded from the initial integration because upstream can write database rows before storage files and can leave partial state; do not use force/override. Revisit import only with a verified transaction/recovery model. No delete, redo, service administration, or remote/network FACT target is included. Authentication credentials must never enter Evidence or logs. Support caller-supplied native and rootless Podman-existing deployments; no privileged container, host installation, or automatic runtime setup. - **Binwalk-NG:** treat `binwalk-ng/binwalk-ng` as a separate integration target by repository and pinned revision. It is a fork of ReFirmLabs Binwalk, whose v3 line is also a Rust rewrite; do not infer feature parity or divergence without the pinned-source matrix. Support its documented analyst-facing scan, signature/offset/entropy results, and caller-selected extraction/output behavior on native and caller-supplied container deployments. Extraction helpers are trusted caller-selected code operating on untrusted input; verify exact executable path/version, own and bound every process, and confine execution to read-only input plus private staging/output. Do not automatically load custom plugins, install tools, mutate host configuration, overwrite pre-existing output, or execute extracted files. Any upstream option that permits those effects must be omitted or constrained and listed in the compatibility matrix. All three providers remain optional and share the same CLI/MCP workflows, named contracts, Evidence provenance, explicit partial/unknown results, process supervision, cancellation, resource budgets, and fail-closed cleanup. Inputs are read-only: use a read-only handle or private verified snapshot, verify source identity/digest before and after when applicable, and reject a mode that can modify or replace the caller's selected input. Caller-configurable budgets must stay below mandatory aggregate ceilings for expanded bytes, output file count, recursion depth, CPU/time, memory, and output storage. Temporary and final output must be exclusively created; partial output after a failure is reported as partial evidence and cleaned only when ownership is proven. Native executables are trusted caller-supplied code and may otherwise inherit the caller's OS authority; REA must not claim a sandbox unless it proves one. If the configured native execution boundary cannot enforce the approved filesystem/network/device restrictions, reject that mode or operation. Container invocation must use caller-provided container tools; REA does not build, pull, start, stop, remove, or reconfigure containers implicitly. Inspect the selected container's exact identity/image, effective mounts, network mode, namespaces, privilege/capability settings, and devices; reject sensitive host mounts, runtime sockets, device access, or unapproved network egress. Rootless alone is not proof of isolation. Native invocation uses caller-provided tools. The same caller-selected operation must have documented behavior in either mode where the provider supports both. ## Context and evidence Issue #718 and merged PR #741 established the first Binwalk v3 and Unblob milestone, not Binwalk-NG or full Unblob CLI/API parity. Issue #718 described FACT REST as a possible later connector, but did not decide on mutating REST calls, native import/export, or container execution. Searches of open/closed REA issues and PRs found no FACT_core or Binwalk-NG integration decision; existing Unblob discussions cover the initial implementation and follow-up fixes only. The upstream FACT REST API documentation describes query, upload/update, compare, binary retrieval, binary search, statistics, system status, and authentication endpoints; the API is explicitly unversioned. Binwalk-NG’s upstream README describes identification and optional extraction and directs users to CLI help/wiki for advanced functions. Unblob documents recursive extraction, reports, entropy, depth/worker controls, plugin loading, and external extractors. The implementation plans must pin upstream revisions and maintain a capability-by-capability compatibility matrix instead of relying on these summaries. References: - [REA contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#fail-closed-integration) - [Firmware roadmap #718](https://github.com/morluto/rea/issues/718) - [Initial firmware integration #741](https://github.com/morluto/rea/pull/741) - [Unblob upstream](https://github.com/onekey-sec/unblob) - [FACT Core REST API](https://github.com/fkie-cad/FACT_core/wiki/Rest-API) - [FACT Core import/export](https://github.com/fkie-cad/FACT_core/blob/master/src/firmware_import_export.py) - [Binwalk-NG upstream](https://github.com/binwalk-ng/binwalk-ng) ## Expected target interaction Read caller-selected local firmware/data; launch caller-selected local tool processes and, where applicable, external extraction helpers; write only caller-selected derived output. The included FACT operations are read-only queries, explicitly state-consuming one-shot result retrieval where documented, and export. One-shot retrieval uses a separate contract and explicit caller request that discloses consumption. Plugin-triggering REST operations may run only when the pinned deployment proves and enforces the approved plugin, scheduler, and network boundary; this decision authorizes them only under that gate. No extracted firmware program is launched. Device flashing/update, booting/emulation, JTAG/UART, glitching, and hardware control are excluded. REA and its child/helper processes contact only explicitly selected local services; helper egress is disabled, and operations requiring uncontrolled egress are rejected. Any different network behavior requires a new scope decision. ## Boundary details - Inputs remain caller-selected; a file extension, signature, or FACT-reported label does not prove format or authorization. - Provider outputs distinguish observations, derivations, inferences, and unknowns and retain original source paths, digests, tool/version, operation, offsets, and failures. - Extraction output is created exclusively; symlinks/special files and path traversal are not materialized as regular output files. Existing outputs are never overwritten. - External extractors are not bundled or automatically installed. Any allowed helper must be explicitly configured, exact-path/version/capability checked, bounded, supervised, and restricted from network/device access. If native execution cannot enforce these limits, that helper operation is unsupported. Runtime custom plugins supplied to Unblob or Binwalk-NG are outside this initial approval. FACT plugin-triggering operations are authorized only when the pinned plugin/scheduler/network boundary is constrained and verified; otherwise they remain unsupported under this decision. - Native and container modes are separately verified. For Podman, REA must not manage container lifecycle or configuration; it may use only a caller-selected, inspected container that passes identity, mount, network, namespace, privilege, capability, and device checks. Reject root/home mounts, host/runtime sockets, devices, privileged containers, and network egress. - Hard aggregate ceilings apply regardless of caller settings: expanded bytes, file count, depth, CPU/time, memory, and output storage. If the runtime cannot enforce the required limits, that mode is unsupported. - FACT’s unversioned REST API requires a pinned compatibility profile, producer fixtures, explicit unknown handling, and redaction of transport authentication credentials. Read/write authority is reflected in CLI/MCP contracts. ## Options and tradeoffs Use three independent PRs/branches so each provider’s upstream matrix, runtime behavior, tests, and review can be accepted or deferred independently. Keep tool installation and container provisioning bring-your-own; this costs setup effort but avoids unrelated system changes and makes tool versions/authority explicit. ## Verification available so far A prototype exists on separate branches. Focused simulated tests and source-level checks are available. Real-provider verification is incomplete for current heads and must be reported per provider and per runtime mode; no real FACT database import/export is claimed by this decision record. ## Success criteria and open questions Before each integration PR: 1. Pin upstream commit/release and publish a complete documented-capability matrix (supported, constrained, or excluded with reason). 2. Validate exact named CLI/MCP contracts and Evidence/error semantics for each operation. 3. Verify native and caller-supplied container paths using real CLI/MCP workflows, with disposable fixtures; record selected input identity/digest before and after and prove source bytes remain unchanged. Verify FACT REST in a disposable FACT container, including plugin-triggering endpoints only when the actual plugin/scheduler is tested with enforced network isolation, and native FACT export against a disposable database and destination. Import remains outside initial acceptance. 4. Exercise malformed inputs, partial output, cancellation, cleanup failure, path/symlink boundaries, permission/capacity limits, and deterministic fuzz/property cases for included operations. Mutation testing must kill every predeclared safety, authority, and ownership mutant and kill at least 85% of applicable non-equivalent mutants; report the score and disposition of every survivor. Excluded FACT import is not part of initial PR acceptance. 5. Complete three independent review rounds per provider, including QA, reverse-engineering, and hardware-security lenses. Resolve all material findings before opening the PRs for the user’s final manual test.

bsakaguchi commented

2026-10-16 21:08:05 +00:00

Author

Owner

@dandgabr commented on GitHub (Oct 15, 2026):

Phase 2 execution update (2026-10-15)

The approved scope is unchanged. Feasibility testing found that the current execution boundaries do not meet the decision's hard aggregate resource and authority requirements, so affected modes remain unavailable until enforcement is proven.

Unblob: a host bwrap 0.12.0 primitive probe created namespaces and hid a /tmp canary behind a private tmpfs, but a broad read-only root bind still exposed a host-readable canary. No selective runtime root or aggregate CPU, process-family memory, process-count, and output quotas are admitted. No Unblob runtime was enabled.
FACT Core: a local source-tagged test image returned HTTP 500 because its backend was absent. Starting the backend required /var/run/docker.sock for scheduler/plugin authority; that host socket was not mounted. REA CLI and MCP preserved the failed HTTP evidence and redacted a synthetic credential. This verifies failure handling only; functional REST acceptance is blocked/unverified, and the image metadata did not attest the upstream source SHA.
Binwalk-NG: this work remains exclusively against binwalk-ng/binwalk-ng at the pinned revision, separate from ReFirmLabs. Per-process prlimit and polled output budgets do not enforce process-tree memory, task-count, runtime, or write-time aggregate quotas. The branch now refuses provider execution before input access, runtime inspection, or process launch; eight real CLI/MCP acceptance cases remain explicitly blocked.

No PR has been opened. Provider/runtime acceptance and the user's manual testing remain outstanding.

@dandgabr commented on GitHub (Oct 15, 2026): ## Phase 2 execution update (2026-10-15) The approved scope is unchanged. Feasibility testing found that the current execution boundaries do not meet the decision's hard aggregate resource and authority requirements, so affected modes remain unavailable until enforcement is proven. - **Unblob:** a host `bwrap` 0.12.0 primitive probe created namespaces and hid a `/tmp` canary behind a private tmpfs, but a broad read-only root bind still exposed a host-readable canary. No selective runtime root or aggregate CPU, process-family memory, process-count, and output quotas are admitted. No Unblob runtime was enabled. - **FACT Core:** a local source-tagged test image returned HTTP 500 because its backend was absent. Starting the backend required `/var/run/docker.sock` for scheduler/plugin authority; that host socket was not mounted. REA CLI and MCP preserved the failed HTTP evidence and redacted a synthetic credential. This verifies failure handling only; functional REST acceptance is blocked/unverified, and the image metadata did not attest the upstream source SHA. - **Binwalk-NG:** this work remains exclusively against `binwalk-ng/binwalk-ng` at the pinned revision, separate from ReFirmLabs. Per-process `prlimit` and polled output budgets do not enforce process-tree memory, task-count, runtime, or write-time aggregate quotas. The branch now refuses provider execution before input access, runtime inspection, or process launch; eight real CLI/MCP acceptance cases remain explicitly blocked. No PR has been opened. Provider/runtime acceptance and the user's manual testing remain outstanding.

bsakaguchi commented

2026-10-16 21:08:06 +00:00

Author

Owner

@dandgabr commented on GitHub (Oct 16, 2026):

Phase 3 status update (2026-10-16)

The previous Phase 2 note described an earlier checkpoint. New evidence is available, while the remaining integration gaps are still open:

Unblob: native scan/extraction and the combined Binwalk/Unblob CLI+MCP acceptance passed; the dedicated user-systemd lane passed 10/10. Caller-provided container execution remains unavailable. Its unblob_v1 startup hooks/entrypoints also need an admission gate before site.main() so custom code excluded by this scope cannot run.
Binwalk-NG: the pinned binwalk-ng/binwalk-ng native CLI/MCP acceptance passed 11/11, and the live user-systemd boundary passed 10/10. check:pr passed with 10,415 tests and 110 skips. Caller-provided existing-container execution remains unimplemented; helper source/build provenance is still unknown where not independently attested.
FACT Core: frontend-only reads passed for the seeded statistics, firmware search, gaps, object detail and analysis-result fixture through CLI and production stdio MCP. The focused boundary gate passed 88 tests and ten targeted mutants, and deterministic response fuzz covered 256 cases. The backend was not started; backend-dependent REST and native export remain unverified/unavailable.

The three provider branches are being completed separately. The remaining work includes caller-container lanes for all three tools, FACT export, the #4325 backend decision and its conditional acceptance. No integration PR is open. Please ratify the exact final scope in this issue or explicitly narrow any mode that cannot meet the listed authority/resource boundaries. We will keep the issue open until the accepted scope has evidence and the provider PRs are complete.

@dandgabr commented on GitHub (Oct 16, 2026): ## Phase 3 status update (2026-10-16) The previous Phase 2 note described an earlier checkpoint. New evidence is available, while the remaining integration gaps are still open: - **Unblob:** native scan/extraction and the combined Binwalk/Unblob CLI+MCP acceptance passed; the dedicated user-systemd lane passed 10/10. Caller-provided container execution remains unavailable. Its `unblob_v1` startup hooks/entrypoints also need an admission gate before `site.main()` so custom code excluded by this scope cannot run. - **Binwalk-NG:** the pinned `binwalk-ng/binwalk-ng` native CLI/MCP acceptance passed 11/11, and the live user-systemd boundary passed 10/10. `check:pr` passed with 10,415 tests and 110 skips. Caller-provided existing-container execution remains unimplemented; helper source/build provenance is still unknown where not independently attested. - **FACT Core:** frontend-only reads passed for the seeded statistics, firmware search, gaps, object detail and analysis-result fixture through CLI and production stdio MCP. The focused boundary gate passed 88 tests and ten targeted mutants, and deterministic response fuzz covered 256 cases. The backend was not started; backend-dependent REST and native export remain unverified/unavailable. The three provider branches are being completed separately. The remaining work includes caller-container lanes for all three tools, FACT export, the #4325 backend decision and its conditional acceptance. No integration PR is open. Please ratify the exact final scope in this issue or explicitly narrow any mode that cannot meet the listed authority/resource boundaries. We will keep the issue open until the accepted scope has evidence and the provider PRs are complete.

bsakaguchi referenced this issue

2026-10-31 00:56:28 +00:00

[PR #1898] [MERGED] feat(ghidra): admit recordless legacy MIPS32 ELFs with a pinned 32-bit language #4890

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#1620

No description provided.

Rows
Columns