[GH-ISSUE #3014] [Docs] Clarify historical merge-rule and approval evidence for 6.4.0 PR #1399 #1054

New issue

Open

opened 2026-10-15 18:30:42 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:30:42 +00:00

Owner

Originally created by @berdigali on GitHub (Oct 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3014

Before submitting

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

Documentation location

github.com/morluto/rea@a56f7bb668/.github/workflows/release.yml

Problem

Historical release approval/check enforcement is unclear for rea-agents 6.4.0. This is a request for documentation and public evidence, not an allegation of a bypass or a vulnerability.

Expected content and supporting evidence

Hello REA maintainers,

We are doing a source-only evaluation of rea-agents 6.4.0 and would appreciate clarification of the historical merge controls for PR #1399. We have not installed REA or run a pilot.

We verified the package's Sigstore provenance and reconciled its source to merge commit a56f7bb668. The PR merged on 2026-10-11 at 03:57:30 UTC. Its final head was e718a71331, matching release run 38110038943. Public review responses did not supply an APPROVED review, and historical rule-suite records were not accessible to us. The final-head CI required aggregate completed at 04:08:34 UTC, after the npm publish job completed at 04:03:32 UTC. We do not interpret this timing as proof of a bypass or security defect.

Could you provide:

The branch-protection/ruleset configuration effective for main at the merge time: required review count, code-owner approval, required status/check names and app identities, and whether strict/up-to-date branch checks applied. Please distinguish that historical policy from current settings.
A rule-suite result or redacted audit export for the exact main update from ee46323b49 to a56f7bb668, showing evaluated rules and whether the update passed normally or used an authorized bypass. If no such history is retained, please say so.
If a bypass occurred, the rule(s) bypassed, authorization mechanism and rationale, with sensitive actor identifiers redacted if needed. If reviews/checks were not mandatory for this release, please confirm that instead; we are not assuming a bypass.
Any historical approval or required-check evidence that public APIs omitted, including final-head commit, check completion time and whether approval remained valid after release-branch updates. Were the late-finishing checks advisory, superseded by earlier required checks, or governed by a separate publishing gate?
If applicable, the intended release approval model for maintainer-owned Release Please PRs and any planned/documented change since this release.

Public links, signed exports or redacted excerpts tied to the exact commit/time are sufficient. Please do not share credentials, private tokens or unrelated audit records. A clear statement that evidence is unavailable is also useful.

Thank you. Our aim is to distinguish verified release identity from historically enforced review/check policy, without claiming that missing public evidence proves unsafe behaviour.

Originally created by @berdigali on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3014 ### Before submitting - [x] I searched the existing issues for a related documentation report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Documentation location https://github.com/morluto/rea/blob/a56f7bb668ab23fec8d33f7af353ac7ed2fe1895/.github/workflows/release.yml ### Problem Historical release approval/check enforcement is unclear for rea-agents 6.4.0. This is a request for documentation and public evidence, not an allegation of a bypass or a vulnerability. ### Expected content and supporting evidence Hello REA maintainers, We are doing a source-only evaluation of rea-agents 6.4.0 and would appreciate clarification of the historical merge controls for [PR #1399](https://github.com/morluto/rea/pull/1399). We have not installed REA or run a pilot. We verified the package's Sigstore provenance and reconciled its source to merge commit a56f7bb668ab23fec8d33f7af353ac7ed2fe1895. The PR merged on 2026-10-11 at 03:57:30 UTC. Its final head was e718a71331758d4e526116dade9d8f9e44253fd5, matching [release run 38110038943](https://github.com/morluto/rea/actions/runs/38110038943/attempts/1). Public review responses did not supply an APPROVED review, and historical rule-suite records were not accessible to us. The final-head CI required aggregate completed at 04:08:34 UTC, after the npm publish job completed at 04:03:32 UTC. We do not interpret this timing as proof of a bypass or security defect. Could you provide: 1. The branch-protection/ruleset configuration effective for main at the merge time: required review count, code-owner approval, required status/check names and app identities, and whether strict/up-to-date branch checks applied. Please distinguish that historical policy from current settings. 2. A rule-suite result or redacted audit export for the exact main update from ee46323b493994902b04824a7dc8aae2a8117903 to a56f7bb668ab23fec8d33f7af353ac7ed2fe1895, showing evaluated rules and whether the update passed normally or used an authorized bypass. If no such history is retained, please say so. 3. If a bypass occurred, the rule(s) bypassed, authorization mechanism and rationale, with sensitive actor identifiers redacted if needed. If reviews/checks were not mandatory for this release, please confirm that instead; we are not assuming a bypass. 4. Any historical approval or required-check evidence that public APIs omitted, including final-head commit, check completion time and whether approval remained valid after release-branch updates. Were the late-finishing checks advisory, superseded by earlier required checks, or governed by a separate publishing gate? 5. If applicable, the intended release approval model for maintainer-owned Release Please PRs and any planned/documented change since this release. Public links, signed exports or redacted excerpts tied to the exact commit/time are sufficient. Please do not share credentials, private tokens or unrelated audit records. A clear statement that evidence is unavailable is also useful. Thank you. Our aim is to distinguish verified release identity from historically enforced review/check policy, without claiming that missing public evidence proves unsafe behaviour.

bsakaguchi added the

area: evidence

documentation

labels

2026-10-15 18:30:42 +00:00

bsakaguchi referenced this issue

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

[PR #1054] [MERGED] feat(native): inspect recorded crashes through pwntools and pwndbg #2609

bsakaguchi referenced this issue

2026-10-31 00:38:13 +00:00

[GH-ISSUE #5329] [Bug] pwndbg debugger-context output-limit message reads "exceeds64 MiB" #3238

bsakaguchi referenced this issue