Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Bug: audit.sh orchestrator probe catch-all emits a hardcoded 'cannot reach repo' cause it never measured (stderr discarded)

Aperta
  • Qualcosa non va?
#65 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
58/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
bash
Ambito
cli, testing

Direzione di ricerca

Start in audit.sh at the orchestrator-probe invocation and catch-all branch described in the issue; inspect how the probe's stderr is handled and how warn receives evidence. The issue includes a proposed stderr-capture change and an optional FW_ORCH_SCRIPT test seam. Validate that the failure evidence reports captured stderr or says the cause is undetermined, and that the probe's normal output remains suppressed.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Context

  • Framework version: 1.6.258
  • Project: 050-email-archive (shared-tooling mode)
  • Reported: 2026-09-25T00:44:09Z

Description

Summary

audit.sh's orchestrator-probe catch-all branch — the one reached only for exit codes the
author did not anticipate, i.e. the one place where the cause is by definition unknown — emits
a hardcoded Evidence line asserting the TermLink repo is unreachable. The only thing
actually measured on that path is the exit code.

Code (pre-fix)

bash "$ORCH_SCRIPT" >/dev/null 2>&1        # stderr discarded
ORCH_EXIT_CAPTURED=$?
...
else
    warn "Orchestrator-arc MCP scan: probe failed (exit $ORCH_EXIT_CAPTURED)" \
         "Cannot reach /opt/termlink via direct read or termlink interact" \
         "Check FW_TERMLINK_REPO and TermLink session availability"
fi

Two problems, and the first causes the second:

  1. The probe's stderr goes to /dev/null. The branch therefore has nothing to report and
    no way to know it has nothing.
  2. So it reports a guess — phrased with more certainty than any other line in the file.

Measured cost, not hypothetical

On 2026-09-25 this branch fired on our host with exit 126. Every clause of the emitted
evidence was false: the repo was reachable, termlink list --json worked, and the real cause
was E2BIG — the scan exported a 186,907-byte payload past Linux's
MAX_ARG_STRLEN (131,072) and execve failed before Python ran (filed separately as #63).

The consequence is the part worth acting on. This check is the ratchet that notices when a
gated MCP tool loses its check_task_governance. Following the stated mitigation
("Check FW_TERMLINK_REPO and TermLink session availability") leads the reader to two
healthy subsystems — so a dead safety defense read as a false alarm and was left alone. The
parallel framework-mcp leg printed [PASS] in the same section, which removed the last cue
that anything was wrong.

A blank evidence field invites investigation; a confidently wrong one ends it.

Fix applied downstream (please consider upstreaming)

-    bash "$ORCH_SCRIPT" >/dev/null 2>&1
+    ORCH_STDERR_FILE=$(mktemp -t orch-stderr-XXXXXX.log)
+    bash "$ORCH_SCRIPT" >/dev/null 2>"$ORCH_STDERR_FILE"
     ORCH_EXIT_CAPTURED=$?
@@
         else
+            ORCH_STDERR_TAIL=$(tail -3 "$ORCH_STDERR_FILE" 2>/dev/null | tr '\n' ';' | sed 's/;$//')
             warn "Orchestrator-arc MCP scan: probe failed (exit $ORCH_EXIT_CAPTURED)" \
-                 "Cannot reach /opt/termlink via direct read or termlink interact" \
-                 "Check FW_TERMLINK_REPO and TermLink session availability"
+                 "${ORCH_STDERR_TAIL:-cause not determined — probe exited $ORCH_EXIT_CAPTURED and wrote nothing to stderr}" \
+                 "Reproduce and read the failure directly: bash $ORCH_SCRIPT"
         fi
     fi
+    rm -f "$ORCH_STDERR_FILE"

stdout stays discarded (the scan prints a full report there); only the diagnostic channel is
kept. The fallback states that the cause was not determined rather than inventing one.

A scope limit we did NOT take, because it is your call

The obvious anti-recurrence rule — "no warn/fail evidence argument in a catch-all branch may
be a bare literal" — was implemented, run, and withdrawn. It flagged two legitimate
sites (audit.sh:4731 and :4736, whose headlines carry a measured value and whose evidence
explains the checked condition rather than claiming a new fact), and it would not have
caught this bug, whose headline also carried a measured value (exit $ORCH_EXIT_CAPTURED). The
real distinction is semantic — is this evidence asserting an unmeasured cause? — not
syntactic. Deciding which evidence literals are legitimate is a design call for the framework,
so we are reporting it rather than shipping a rule that produces false positives in your tree.

Untestable-by-construction (separate, smaller request)

We could not verify the corrected line renders correctly when the branch fires, because
ORCH_SCRIPT is hardcoded:

ORCH_SCRIPT="$FRAMEWORK_ROOT/agents/audit/orchestrator-mcp-scan.sh"

With #63 fixed, the probe no longer produces a non-0/1/2 exit, so the branch cannot be reached
without swapping the script on disk — not something to do on a shared host. A one-line seam
would make this branch testable:

ORCH_SCRIPT="${FW_ORCH_SCRIPT:-$FRAMEWORK_ROOT/agents/audit/orchestrator-mcp-scan.sh}"

A defensive branch that cannot be exercised is a branch that cannot be verified — which is
precisely the condition that let the false evidence above survive unnoticed.

Downstream references

Pen task T-2190 (finding X-05); companion filings #63 (E2BIG) and #64 (head -1 truncation
of the same check's warnings). All three are the same class: the audit's own output is not
itself audited.

Reported via fw upstream report from field installation

Lingua principale
Shell
Stelle
16
Fork
6
Merge medio
6h 24m
PR unite (30g)
5

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di DimitriGeelen/agentic-engineering-framework

Tutte le issue di DimitriGeelen/agentic-engineering-framework

Issue simili

Altre issue su Shell/Bash

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.