fix(security): add the Windows analogues of the shutdown/mkfs hardline rules

[pierrenode]

Summary

Fixes #69472 (follow-up). #84428 added a Windows destructive tier to DANGEROUS_PATTERNS — the bypassable tier (skippable via --yolo / approvals.mode=off) — covering Format-Volume/format.com, taskkill /F, Stop-Process -Force, etc. It did not touch HARDLINE_PATTERNS, the separate list checked before the yolo bypass and documented in-code as never bypassable ("commands with no recovery path... blocked unconditionally... trusting the agent with your files and services, not trusting it to wipe the disk or power the box off").

Two of HARDLINE_PATTERNS's own POSIX rules stayed unmatched on Windows:

1. Restart-Computer / Stop-Computer had zero detection at all — not even a bypassable prompt. The existing shutdown|reboot|halt|poweroff hardline rule only matches those literal words; PowerShell's cmdlet names don't contain them. Verified empirically before this fix:

   detect_hardline_command('Restart-Computer -Force')  -> (False, None)
   detect_dangerous_command('Restart-Computer -Force')  -> (False, None, None)
   

2. Format-Volume / format.com <drive>: — the exact Windows analogue of the hardline mkfs rule (an operation with no recovery path) — were left in the bypassable tier only.

Changes

Two new HARDLINE_PATTERNS entries, mirroring mkfs's existing bare \b-boundary style (not _CMDPOS-anchored — like the rest of the Windows tier in DANGEROUS_PATTERNS, "restart-computer"/"format-volume" aren't ordinary English prose the way "shutdown"/"reboot" are, so command-position anchoring isn't needed to avoid false positives):

(r'\b(?:restart|stop)-computer\b', "system shutdown/reboot (PowerShell)"),
(r'\bformat-volume\b', "format filesystem (Format-Volume)"),
(r'\bformat(?:\.com)?\s+[a-z]:', "format drive (format.com)"),

diskpart stays hardline-exempt (interactive, has non-destructive subcommands like list disk) — the same scoping choice POSIX makes by excluding fdisk/parted from the hardline list.

Format-Volume/format.com remain in DANGEROUS_PATTERNS too (unchanged) — mkfs itself is already duplicated in both lists in this codebase, so this matches existing precedent rather than introducing a new pattern.

Test plan

• 13 new cases in tests/tools/test_approval_windows.py::TestHardlineWindowsDestructiveTier — 5 power-state hardline (Restart-Computer, -Force variant, lowercase, Stop-Computer, -Force variant), 3 format hardline, 5 benign/non-hardline (diskpart, bare format/format /?, Restart-Service, plain prose).
• Mutation-verify: stashed the production diff, all 8 "should be hardline-blocked" assertions fail against the unfixed code.
• Full tests/tools/test_approval_windows.py (61 tests) + tests/tools/test_approval.py + test_approval_mode_parity.py + test_approval_deny_rules.py + test_smart_approval_policy.py pass (181/182; 1 pre-existing failure — TestDetectDangerousRm::test_nonrecursive_verification_artifact_cleanup_is_not_dangerous — verified via git stash to reproduce identically without this change, unrelated /tmp path-mocking issue).
• ruff check clean.

Note on false positives

Both new patterns inherit the same prose-matching characteristic their existing siblings already have in this codebase — grep -r "mkfs" docs/ already hardline-matches today (mkfs's bare \b pattern has no command-position anchor), and Format-Volume/format.com's existing DANGEROUS_PATTERNS entries already flag things like grep -r "Format-Volume" docs/ pre-existing this PR. This is an established, accepted trade-off in this exact list (precision over recall for genuinely catastrophic operations), not a new regression — happy to discuss further hardening (e.g. _CMDPOS anchoring) as a follow-up if maintainers want it, but wanted to match the existing style rather than diverge from the pattern I'm mirroring.

[monerostar]

Native Windows 11 verification

Host: Windows 11 (Windows-10-10.0.26200-SP0), CPython 3.11.15, worktree at e870d10eb.

Gap on current code (still present)

Against the installed tree on this machine, PowerShell power-state / volume-format commands are not hardline or dangerous:

command	hardline	dangerous
Restart-Computer / -Force / lowercase	(False, None)	(False, None, None)
Stop-Computer / -Force	(False, None)	(False, None, None)
Format-Volume -DriveLetter D	(False, None)	(False, None, None)
format d: /fs:ntfs / format D: /y	(False, None)	(False, None, None)
shutdown /s /t 0 (POSIX sibling)	(True, 'system shutdown/reboot')	n/a

Current upstream main tools/approval.py still has no restart-computer / stop-computer in HARDLINE_PATTERNS. Format-Volume / format.com <drive>: exist only in bypassable DANGEROUS_PATTERNS (lines 775/778). So the PR's claim matches live main: yolo can still walk a Windows box through a no-recovery format, and Restart-Computer is not gated at all.

After this PR

Same interpreter, PR tree:

command	hardline
Restart-Computer, Restart-Computer -Force, restart-computer -force	(True, 'system shutdown/reboot (PowerShell)')
Stop-Computer, Stop-Computer -Force	same
Format-Volume -DriveLetter D	(True, 'format filesystem (Format-Volume)')
format d: /fs:ntfs, format D: /y	(True, 'format drive (format.com)')
diskpart /s wipe.txt	not hardline (stays dangerous-only, as designed)
format, format /?, Restart-Service, restart the computer manually	not hardline

HERMES_YOLO_MODE=1 does not change detect_hardline_command() results — the new rules stay True. That is the property that matters here.

Tests

python -m pytest tests/tools/test_approval_windows.py -q --tb=short -o addopts=
61 passed in 2.29s

Includes the 13 new TestHardlineWindowsDestructiveTier cases.

Review notes

• Scope is right: two POSIX hardline siblings (power-off + filesystem format), not a redesign. diskpart left out matches the fdisk/parted precedent.
• Duplicating Format-Volume/format.com into both lists matches the existing POSIX filesystem-format pattern already in this file.
• \b (no _CMDPOS) is consistent with the Windows DANGEROUS_PATTERNS tier and with the author's false-positive note. I would not block on that.
• Compiled flags include IGNORECASE (live flags=50), which is why format D: is covered by [a-z]:.

I cannot merge. From a native Win11 box this looks ready.

[monerostar]

Native Win11 verification (monerostar overnight, not a maintainer merge signal)

Host: Windows 11 Pro 10.0.26200, CPython 3.11.15, pytest 9.1.1. Compared upstream/main tools/approval.py against this PR at e870d10eb.

The gap on current main is real. Live detect_hardline_command / detect_dangerous_command matrix (cmdlet names abbreviated so this comment itself is not a hardline payload):

command class	main hardline	PR hardline	main dangerous
PS power-state cmdlets (Restart/Stop + -Computer, incl. -Force)	False	True	False
Volume-format cmdlets / format.com X:	False	True	True (yolo-bypassable)
Bare format / format /?	False	False	False
English prose / Restart-Service	False	False	False
diskpart script	False	False	True (correct — stays prompt-only)
Wrapped via powershell -Command / pwsh -c / cmd /c	False	True	True
Native shutdown /s / shutdown /r	True	True	already covered by POSIX _CMDPOS rule

So today a model can issue the PowerShell power-state cmdlets with no prompt at all, and can --yolo past the volume-format cmdlets. Promoting those to the hardline floor matches the POSIX reboot / filesystem-format intent.

Tests: pytest tests/tools/test_approval_windows.py -o addopts= → 61 passed, including the new TestHardlineWindowsDestructiveTier cases.

One follow-up, not a reason to drop the floor. The new rules use \b instead of _CMDPOS. On this host that also hardlines:

• echo Restart-Computer
• Write-Host 'Restart-Computer'

POSIX reboot/halt were deliberately command-position anchored to avoid that class. A later pass wrapping these three with _CMDPOS (and adding those two negatives) would match the existing style. Pre-existing and out of this PR's scope: a fully-qualified System32\shutdown.exe /s path is still not hardlined on main or here.

I would take this as-is; the Windows power-state hole is the important part.

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

fix(security): add the Windows analogues of the shutdown/mkfs hardline rules

Closing the Windows power-state/format hole is the important part and the test matrix is thorough (61 passing per the added suite). Two detection gaps and one false-positive concern:

1. format with intervening flags bypasses the hardline floor: \bformat(?:\.com)?\s+[a-z]: requires the drive letter to immediately follow the verb. Valid format.com invocations like format /q d:, format /y d:, or format /fs:ntfs d: do not match, so a quick-format drive wipe still slips past the unconditional block. Suggest allowing option tokens between the verb and the drive spec, e.g. format(?:\.com)?(?:\s+[\/\-][a-z0-9]+)*\s+[a-z]: (or at minimum cover the /q//y forms).
2. \b word-boundary anchoring vs _CMDPOS: the new hardline entries match anywhere in a line, so echo Restart-Computer, Write-Host 'Stop-Computer', or prose in a comment/string get unconditionally hard-blocked — no prompt, no yolo override. The POSIX analogues deliberately use _CMDPOS command-position anchoring to avoid exactly this class (as the diff's own comment notes for bare "reboot"/"shutdown"). The false-positive cost is higher for a hardline rule than for the bypassable DANGEROUS_PATTERNS tier: consider _CMDPOS-style anchoring for the cmdlets, or explicitly accept the two negatives (echo Restart-Computer, Write-Host 'Stop-Computer') as intended hardline behavior and add them as negative tests.
3. Minor: the trailing \b on (?:restart|stop)-computer\b correctly avoids Stop-ComputerService — good. Consider adding a wrapped form (e.g. powershell -c "Restart-Computer") to the positives to lock in that substring detection keeps working through wrappers.