morluto/rea

Fork 0

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

[GH-ISSUE #4191] [Bug] inspect_go_binary reports dependencies: [] and complete: true for GOPATH-mode builds, with no limitation #1644

New issue

Closed

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

bsakaguchi commented

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

Owner

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

Before submitting

I searched the open and closed issues for a related report (GOPATH, trimpath, inspect_go_binary module/dependencies): none found.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Observed behavior

Debian builds Go packages with dh-golang in GOPATH mode. The embedded build info then has a path line and build settings but no mod and no dep lines (go version -m shows the same). For these binaries inspect_go_binary returns:

"module": { "path": "github.com/cli/cli/v2/cmd/gh", "main": null, "dependencies": [],
            "unparsed_lines": [], "complete": true }

The limitations are only the three generic ones (observed file content; build info only; resource guards). Nothing says the dependency list is unknown.

The binaries do have dependencies. Debian bookworm's gh (2.23.0+dfsg1-1) has 78 distinct third-party package roots in its function table (read with Go's own debug/gosym from .gopclntab, e.g. github.com/AlecAivazis/survey, github.com/alecthomas/chroma, github.com/charmbracelet/glamour, …). An agent or SBOM workflow reading dependencies: [] together with complete: true would conclude there are no third-party modules.

All 8 binaries I checked behave the same way, and the build info REA reports otherwise matches go version -m exactly: Go version, path, every build setting including -trimpath=true and CGO_ENABLED=1.

Package (Debian bookworm, amd64)	Go	`mod`/`dep` lines	REA `dependencies`
`gh` 2.23.0+dfsg1-1	go1.19.6	none	`[]`
`hugo` 0.111.3-1	go1.19.6	none	`[]`
`rclone` 1.60.1+dfsg-2+b5	go1.19.8	none	`[]`
`restic` 0.14.0-1+b5	go1.19.8	none	`[]`
`git-lfs` 3.3.0-1+deb12u1	go1.19.8	none	`[]`
`fzf` 0.38.0-1+b1	go1.19.8	none	`[]`
`age` / `age-keygen` 1.1.1-1+b3	go1.19.8	none	`[]`

Cause

src/go/GoModuleText.ts sets complete from parse success only (unparsed_lines.length + unparsed_line_bytes_base64.length === 0). src/go/GoBinaryProvider.ts (~lines 194-215, main @ c7f6b8bad) adds conditional limitations for non-UTF-8 strings, a missing build-info record and incomplete parsing, but none for build info without a main module.

Reproduction

# Debian bookworm (apt verifies the .deb against the signed InRelease/Packages index)
apt-get download gh && dpkg-deb -x gh_2.23.0+dfsg1-1_amd64.deb x
go version -m x/usr/bin/gh                  # go1.19.6, path …/cmd/gh, build lines only
rea inspect-go-binary x/usr/bin/gh --json   # module.main null, dependencies [], complete true

.deb sha256 prefixes: gh 2d5f52d15924b03f, hugo 6c3508f7b0f0009e, rclone 703722dcab0c4873, restic 9d7e8c210736f3f1, git-lfs 633a69f57a01eb3d, fzf 5dddf8e2bd85956d, age 574664c44f1c69ec.

Expected behavior

When the module text has no mod line (main is null), add a limitation along the lines of: "No main-module record was embedded (for example a GOPATH-mode build); the dependency list is unknown, not empty." Optionally expose that as a field, e.g. module_mode: "absent", so clients don't have to infer it from main === null.

This matches the Rust inspector, which already says "Absence of .dep-v0 does not mean the binary has no dependencies."

Impact and scope

Every Go binary built outside module mode: Debian/Ubuntu dh-golang packages and other GOPATH or GO111MODULE=off builds.
The data is correct; the interpretation is misleading. Deterministic.

REA version

Executed on rea-agents@6.5.0. The limitation logic is unchanged on main @ c7f6b8bad (source-derived).

Runtime and platform

rea Docker image (Linux x64). Reference go version -m from golang:1.27.

Target and artifact context

Public Debian bookworm packages.

Interface

CLI (MCP shares the provider).

Originally created by @Rinkia on GitHub (Oct 15, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4191 ### Before submitting - [x] I searched the open and closed issues for a related report (GOPATH, trimpath, inspect_go_binary module/dependencies): none found. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Observed behavior Debian builds Go packages with `dh-golang` in GOPATH mode. The embedded build info then has a `path` line and `build` settings but no `mod` and no `dep` lines (`go version -m` shows the same). For these binaries `inspect_go_binary` returns: ```json "module": { "path": "github.com/cli/cli/v2/cmd/gh", "main": null, "dependencies": [], "unparsed_lines": [], "complete": true } ``` The limitations are only the three generic ones (observed file content; build info only; resource guards). Nothing says the dependency list is unknown. The binaries do have dependencies. Debian bookworm's `gh` (2.23.0+dfsg1-1) has **78** distinct third-party package roots in its function table (read with Go's own `debug/gosym` from `.gopclntab`, e.g. `github.com/AlecAivazis/survey`, `github.com/alecthomas/chroma`, `github.com/charmbracelet/glamour`, …). An agent or SBOM workflow reading `dependencies: []` together with `complete: true` would conclude there are no third-party modules. All 8 binaries I checked behave the same way, and the build info REA reports otherwise matches `go version -m` exactly: Go version, path, every build setting including `-trimpath=true` and `CGO_ENABLED=1`. | Package (Debian bookworm, amd64) | Go | `mod`/`dep` lines | REA `dependencies` | | --- | --- | --- | --- | | `gh` 2.23.0+dfsg1-1 | go1.19.6 | none | `[]` | | `hugo` 0.111.3-1 | go1.19.6 | none | `[]` | | `rclone` 1.60.1+dfsg-2+b5 | go1.19.8 | none | `[]` | | `restic` 0.14.0-1+b5 | go1.19.8 | none | `[]` | | `git-lfs` 3.3.0-1+deb12u1 | go1.19.8 | none | `[]` | | `fzf` 0.38.0-1+b1 | go1.19.8 | none | `[]` | | `age` / `age-keygen` 1.1.1-1+b3 | go1.19.8 | none | `[]` | ### Cause `src/go/GoModuleText.ts` sets `complete` from parse success only (`unparsed_lines.length + unparsed_line_bytes_base64.length === 0`). `src/go/GoBinaryProvider.ts` (~lines 194-215, `main` @ `c7f6b8bad`) adds conditional limitations for non-UTF-8 strings, a missing build-info record and incomplete parsing, but none for build info without a main module. ### Reproduction ```sh # Debian bookworm (apt verifies the .deb against the signed InRelease/Packages index) apt-get download gh && dpkg-deb -x gh_2.23.0+dfsg1-1_amd64.deb x go version -m x/usr/bin/gh # go1.19.6, path …/cmd/gh, build lines only rea inspect-go-binary x/usr/bin/gh --json # module.main null, dependencies [], complete true ``` `.deb` sha256 prefixes: gh `2d5f52d15924b03f`, hugo `6c3508f7b0f0009e`, rclone `703722dcab0c4873`, restic `9d7e8c210736f3f1`, git-lfs `633a69f57a01eb3d`, fzf `5dddf8e2bd85956d`, age `574664c44f1c69ec`. ### Expected behavior When the module text has no `mod` line (`main` is null), add a limitation along the lines of: "No main-module record was embedded (for example a GOPATH-mode build); the dependency list is unknown, not empty." Optionally expose that as a field, e.g. `module_mode: "absent"`, so clients don't have to infer it from `main === null`. This matches the Rust inspector, which already says "Absence of .dep-v0 does not mean the binary has no dependencies." ### Impact and scope - Every Go binary built outside module mode: Debian/Ubuntu `dh-golang` packages and other GOPATH or `GO111MODULE=off` builds. - The data is correct; the interpretation is misleading. Deterministic. ### REA version Executed on `rea-agents@6.5.0`. The limitation logic is unchanged on `main` @ `c7f6b8bad` (source-derived). ### Runtime and platform `rea` Docker image (Linux x64). Reference `go version -m` from `golang:1.27`. ### Target and artifact context Public Debian bookworm packages. ### Interface CLI (MCP shares the provider).

bsakaguchi closed this issue

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

bsakaguchi commented

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

Author

Owner

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

Fixed on main in a05092726. Go inspection distinguishes metadata parsing completeness from dependency inventory coverage and reports the missing main-module limitation rather than implying an observed empty dependency list.

Controls distinguish GOPATH-style omitted main-module metadata from a module-mode observed empty list and preserve decoded dependencies.

Hosted main CI is still pending; this closure is based on the implemented fix and the scoped regression evidence.

@morluto commented on GitHub (Oct 16, 2026): Fixed on `main` in [a05092726](https://github.com/morluto/rea/commit/a05092726f1283d32b2afe761f430abd2de18386). Go inspection distinguishes metadata parsing completeness from dependency inventory coverage and reports the missing main-module limitation rather than implying an observed empty dependency list. Controls distinguish GOPATH-style omitted main-module metadata from a module-mode observed empty list and preserve decoded dependencies. Hosted main CI is still pending; this closure is based on the implemented fix and the scoped regression evidence.

bsakaguchi referenced this issue

2026-10-17 21:01:32 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi commented

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

Author

Owner

@Rinkia commented on GitHub (Oct 18, 2026):

Confirmed on rea-agents@6.7.0 with the Debian bookworm gh 2.23.0 binary from the report. dependencies is still [] and complete is still true. A limitation now says "Dependency coverage is unknown because no main-module record was decoded from the embedded module information, as in GOPATH-mode builds…". Thanks for the fix.

@Rinkia commented on GitHub (Oct 18, 2026): Confirmed on `rea-agents@6.7.0` with the Debian bookworm `gh` 2.23.0 binary from the report. `dependencies` is still `[]` and `complete` is still `true`. A limitation now says "Dependency coverage is unknown because no main-module record was decoded from the embedded module information, as in GOPATH-mode builds…". Thanks for the fix.

bsakaguchi referenced this issue

2026-10-31 00:54:23 +00:00

[PR #1644] [MERGED] test(javascript): retain resource ownership in deep-return fixture #4722

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

No description provided.

Rows
Columns