Choose How to Finish #1634's Lane After the Narrowed Model's Strict Passes #2079

Question

The fix for #1634 (handoff #2072, track auto-1634, branch feature/auto-1634 at 271a763, no pull request yet) applied #2056's answer. The pass after it found 4 findings. Two edit rounds fixed those, and the third pass found 4 more, all introduced. Both edit rounds for this push are spent, so editing stopped here. How should the lane finish?

What the branch holds now

A nested timeout chain is bounded only when every outer one sends signal 0 with no -k of any value and the innermost one is a bound. Any word naming timeout between an outer duration and the wrapper counts as nesting. A -s value holding $, a backtick, {, [, *, or ? is read as no bound. README requirement 7 declares the false denies, and nohup with HUP is listed among the shapes not reached. --selftest passes, and every local gate is clean.

The two edit rounds on this push did the following:

• Round 1 fixed pass 1. A timeout behind a prefix that takes an argument, such as nice -n 5, is now read as nesting, and a false test label is corrected.
• Round 2 fixed pass 2. An outer kill-after is now denied in any spelling (-k .5), and -s {0..0} is read as no bound.

Open findings from the last strict pass

introduced, 4:

1. README requirement 7 says a payload that handles and ignores the signal is "not decidable from the command text at all." That is false for a trap written inline in the payload, as in timeout 900 bash -c 'trap "" TERM; <loop>'. That command is allowed and leaks. The fix is to state the true reason: an inline trap is not read.
2. The false-deny sentence in README requirement 7, repeated in the _timeout_bounds_wrapper docstring, calls every prefix-with-argument nesting a false deny. That only holds behind a signal-0 outer timeout with no -k. timeout -s KILL 10 nice -n 5 timeout 800 ... is a correct deny. The fix is to scope the sentence.
3. timeout -s ~ ... with HOME=0 rewrites to signal 0, but tilde is not in the rewrite character set. This is a contrived gap between the README's wording and the code. The fix is to add ~ to the set.
4. No test pins two of the nesting checks. Two rows would close this gap: an allow row for timeout -s 0 900 nice timeout 800 ... and a deny row for timeout -s 0 900 foo -s 0 5 timeout 800 ....

pre-existing findings are already filed. #2055 covers an inherited bound across bash -c, and #2078 covers --foreground signalling only the direct child.

Options

1. Recommended: fix the four and open the pull request. Apply the four small fixes above. Run the mandatory strict pass and record it. Then open the pull request to develop with Closes on promotion: #1634 and let the PR review loop dispose of whatever that pass raises, rather than parking the lane again on it. None of the four is a leak a real command reaches except the inline trap, and that one is already allowed on develop.
2. Open the pull request as it stands and file the four as follow-up issues. No further edit on this branch. The two false README sentences ship until the follow-ups land.
3. Fix the four and keep the ordinary stop rule. The lane parks again if the next pass finds anything introduced. Each pass on this lane has so far found new findings against the round before it.

Blocks

• Handoff Session Handoff [auto-1634]: Narrow Nested timeout Handling per #2056 #2072 (track auto-1634), branch feature/auto-1634 at 271a763. No pull request is open, so none is blocked.