morluto/rea

Fork 0

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

[GH-ISSUE #7874] [Feature] Inspect Python wheel distributions as structured, read-only Evidence #4652

New issue

Open

opened 2026-10-31 00:51:57 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:51:57 +00:00

Owner

Originally created by @jayykernel on GitHub (Oct 28, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7874

Before submitting

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

Area

Evidence, artifacts, or reconstruction

Current limitation

A Python wheel is a ZIP-based distribution with package-level metadata, compatibility tags, entry points and a RECORD inventory. Generic archive inspection can help enumerate its contents, but I could not find a dedicated read-only workflow that validates these wheel-level facts and returns them together as structured Evidence. Analysts otherwise have to manually connect *.dist-info/METADATA, WHEEL, entry_points.txt, RECORD and the packaged modules.

This is a feature proposal from repository/issue search, not a claim that generic archive inspection is missing.

Use cases

Inspect a third-party wheel before installing it.
Identify declared dependencies, supported Python/ABI/platform tags and console entry points.
See which Python modules and native extensions ship in a distribution, and whether the file inventory matches its RECORD metadata.
Reuse the resulting package evidence when investigating contained bytecode or native extensions.

Desired outcome

Add a read-only wheel inspector (for example, inspect_python_wheel / inspect-python-wheel) that parses the standard wheel ZIP layout without importing or executing package code. It should report distribution name/version, wheel tags, declared requirements, entry points, contained module/extension paths and RECORD validation results, with unknown or unsupported facts left explicit.

Acceptance criteria

Supports representative pure-Python and platform-specific wheels.
Validates archive structure and RECORD-listed paths, sizes and hashes where the algorithm is supported; mismatches are reported rather than silently accepted.
Handles malformed ZIPs, missing or ambiguous *.dist-info metadata, duplicate paths and incomplete RECORD files with typed errors or explicit limitations.
Does not import, execute or install the inspected package and performs no network access.
Produces deterministic CLI and MCP Evidence containing the input identity, coverage and limitations.
Includes fixture-based tests and documentation explaining that metadata claims do not prove runtime behavior or package safety.

This complements the existing Python bytecode and packaged-application directions (including #2296 and #3678) but is limited to distribution-level metadata and integrity, not a Python decompiler or full dependency resolver.

Originally created by @jayykernel on GitHub (Oct 28, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7874 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the contribution scope must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Current limitation A Python wheel is a ZIP-based distribution with package-level metadata, compatibility tags, entry points and a `RECORD` inventory. Generic archive inspection can help enumerate its contents, but I could not find a dedicated read-only workflow that validates these wheel-level facts and returns them together as structured Evidence. Analysts otherwise have to manually connect `*.dist-info/METADATA`, `WHEEL`, `entry_points.txt`, `RECORD` and the packaged modules. This is a feature proposal from repository/issue search, not a claim that generic archive inspection is missing. ### Use cases - Inspect a third-party wheel before installing it. - Identify declared dependencies, supported Python/ABI/platform tags and console entry points. - See which Python modules and native extensions ship in a distribution, and whether the file inventory matches its RECORD metadata. - Reuse the resulting package evidence when investigating contained bytecode or native extensions. ### Desired outcome Add a read-only wheel inspector (for example, `inspect_python_wheel` / `inspect-python-wheel`) that parses the standard wheel ZIP layout without importing or executing package code. It should report distribution name/version, wheel tags, declared requirements, entry points, contained module/extension paths and RECORD validation results, with unknown or unsupported facts left explicit. ### Acceptance criteria - Supports representative pure-Python and platform-specific wheels. - Validates archive structure and RECORD-listed paths, sizes and hashes where the algorithm is supported; mismatches are reported rather than silently accepted. - Handles malformed ZIPs, missing or ambiguous `*.dist-info` metadata, duplicate paths and incomplete RECORD files with typed errors or explicit limitations. - Does not import, execute or install the inspected package and performs no network access. - Produces deterministic CLI and MCP Evidence containing the input identity, coverage and limitations. - Includes fixture-based tests and documentation explaining that metadata claims do not prove runtime behavior or package safety. ### Related work This complements the existing Python bytecode and packaged-application directions (including #2296 and #3678) but is limited to distribution-level metadata and integrity, not a Python decompiler or full dependency resolver.

bsakaguchi commented

2026-10-31 00:51:59 +00:00

Author

Owner

@shaojian0514 commented on GitHub (Oct 29, 2026):

Proposal: offline wheel metadata and RECORD inspection (#7874)

This requests a maintainer scope decision before production integration. The proposed inspector never installs, imports or executes the package, resolves dependencies, or accesses the network.

A local exploratory prototype reads metadata, compatibility tags, entry points and RECORD paths/sizes/SHA-256/384/512. Gaps and unsupported hashes remain unverified. The combined wheel/trace synthetic suite has 30 passing tests on Windows / Node 24.22.1. This is not public CLI/MCP or real-provider qualification.

The production design would reuse existing ZIP/stable-file ownership, add exact domain contracts and one shared Evidence workflow, then expose CLI/MCP with boundary coverage. Metadata claims do not prove safety or runtime behavior.

Requested decisions: Is a dedicated inspect_python_wheel operation within scope? Is metadata plus RECORD appropriate for a first PR? Which algorithms, coverage semantics and resource settings are required?

Remaining gaps: complete wheel conformance, real-package corpus, canonical schemas, cancellation/cleanup, public delivery and CI. No human readiness attestation has been made.

@shaojian0514 commented on GitHub (Oct 29, 2026): # Proposal: offline wheel metadata and RECORD inspection (#7874) This requests a maintainer scope decision before production integration. The proposed inspector never installs, imports or executes the package, resolves dependencies, or accesses the network. A local exploratory prototype reads metadata, compatibility tags, entry points and RECORD paths/sizes/SHA-256/384/512. Gaps and unsupported hashes remain unverified. The combined wheel/trace synthetic suite has 30 passing tests on Windows / Node 24.22.1. This is not public CLI/MCP or real-provider qualification. The production design would reuse existing ZIP/stable-file ownership, add exact domain contracts and one shared Evidence workflow, then expose CLI/MCP with boundary coverage. Metadata claims do not prove safety or runtime behavior. Requested decisions: Is a dedicated inspect_python_wheel operation within scope? Is metadata plus RECORD appropriate for a first PR? Which algorithms, coverage semantics and resource settings are required? Remaining gaps: complete wheel conformance, real-package corpus, canonical schemas, cancellation/cleanup, public delivery and CI. No human readiness attestation has been made.

bsakaguchi referenced this issue

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

[PR #4652] [CLOSED] fix: forward abort signal through cli finalizer #6345

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

No description provided.

Rows
Columns