Skip to content

test(security): pin the rm floor force requirement - #21900

Open
devansh1401 wants to merge 1 commit into
kirodotdev:mainfrom
devansh1401:test/rm-force-regression
Open

devansh1401 wants to merge 1 commit into
kirodotdev:mainfrom
devansh1401:test/rm-force-regression

Conversation

@devansh1401

Copy link
Copy Markdown
Contributor

Problem / Motivation

Goal: pin the force-flag requirement in the recursive-force rm floor.

the existing allow cases miss recursive-only commands against root and home, so dropping the force check leaves them green. the error comment also mentions a depth cap that does not exist.

Why it matters

a missing force check would over-refuse commands that the floor intentionally allows.

Not a goal

  • changing runtime behavior or adding a depth cap.
  • changing fail-closed handling or broadening the rm parser.

What changed (motivation → approach → change)

added rm -r / and rm -r ~ to the allow cases in test/test_denied_commands_security.py, removed the stale depth-cap phrase in src/kiro_crew/security/__init__.py, and documented the flag coverage in docs/system-specs/modules/security.md.

Backwards compatibility

no runtime or public api changes.

Tests

full gate run used base 93e27870. after rebasing the identical patch onto 4560da2f, the full changed test file passed again (1,372 passed, 1 skipped) and local gpt review found no issues.

  • full changed test file: 1,372 passed, 1 skipped; rm-floor class: 45 passed.
  • mutation proof: removing and force leaves the original 43 cases green; exactly the two new cases fail.
  • determinism: 20 serial and 10 four-worker runs of the 45-case class, with seeded shuffled collection order; all passed.
  • flake-pattern ratchet: 58 passed.
  • frontend: 11,581 passed across 376 files. electron: 2,757 passed, 4 skipped after installing its separate dependencies.
  • 60/61 repository gate commands passed, including static checks, builds, type checks, documentation and bundle checks. semgrep 1.78 found no introduced findings.
  • broader backend run interrupted after 11,586 passes, 67 skips and two failures, both reproduced on clean 93e27870: the sage task-isolation failure tracked in Flaky: test_the_post_path_never_sends_a_dismissed_finding inherits mock tasks #20857, and TestEndToEndMacOS::test_round_trip failing to build the apple speech helper. the remaining selected backend tests were not run.
  • local gpt review: no findings. the configured local claude reviewer was unavailable; server review is still pending.

Manual verification

the mutation ran in memory through a temporary pytest plugin. no shell payload was executed, and production source was not modified for the proof.

Screenshots / video

n/a — test and comment changes only.

Related Issues

Closes #21759

follow-up to #18415. checked open prs, including #21650 and #21858; neither implements this fix.

Checklist

  • one conventional commit
  • regression coverage added
  • self-review completed
  • owning documentation updated
  • no secrets, credentials, or internal references in the diff

Contribution License Agreement

submitted under the project’s apache-2.0 license.

@devansh1401
devansh1401 requested review from a team and KiroCrewCaptain as code owners October 18, 2026 13:02
@github-actions github-actions Bot added fork Pull request from a fork (external contributor) readiness: action required A blocking check or review needs attention readiness: checking Automated validation is still running and removed readiness: action required A blocking check or review needs attention labels Oct 18, 2026
@github-actions

Copy link
Copy Markdown
Contributor

UX Review (Opus 5.5, fork) — ⏭️ skipped

Revision 53099833c5e3ba8c94bc61b0c5b4faf2f0c998bf touches no user-facing surface (no changes under website/ or committed screenshots), so the UX review was skipped. Advisory — does not block merge.

@github-actions

Copy link
Copy Markdown
Contributor

First Principles Review (Opus 5.5, fork) — 🟡 CONCERNS

Premise-level review of 53099833c5e3ba8c94bc61b0c5b4faf2f0c998bf via the fork AI-review pipeline — why this exists and whether the shipped surface is the smallest honest version. Updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

First-Principles-Verdict: CONCERNS

The added spec paragraph says again what the sentence just above it already says, and it names test cases that will drift out of date. The test and comment fixes are justified.

Not justified as shipped

  • Item 3 — duplicate of docs/system-specs/modules/security.md (same rm-floor paragraph, "the flags hold recursive (r, R, --recursive) AND force (f, --force)"): the added "TestRecursiveForceRmFloor pins both flag requirements: rm -f /, rm -r /, and rm -r ~ stay allowed" restates the existing AND rule. It also copies the test's case list into the spec, so the two have to be kept in sync by hand.
    Subtraction: delete the added two-line paragraph. The existing "AND force" sentence already documents the behaviour, and the test pins it.
    Clears when: the added paragraph is removed.

What this change ships

Inventory (3 items) — 2 justified

Intent: make sure a regression that drops the force-flag check in the rm floor turns a test red (FIX, test coverage only; closes #21759).

  1. rm -r / and rm -r ~ are now pinned as allowed (mutation proof: on base, removing and force leaves every test green) — justified
  2. The fail-closed comment no longer mentions a depth cap that does not exist (grep of rm_floor.py for depth/cap: 0 hits) — justified
  3. The spec gains a paragraph listing the test's flag-absent cases — duplicate of the existing "AND force" sentence in security.md

[FIRST-PRINCIPLES-REVIEWED] 5309983

Description read

[DESCRIPTION-READ] 7b55d4a9baa729b7cc86a111667dbf481ce5ae861f50ebfb40f3966eb700d769

That sha256 names the PR description this verdict read. Recompute it with .github/scripts/pr-description-capture.sh; if it differs, the description changed after this verdict was formed and any finding drawn from the description is unproven.

@github-actions

Copy link
Copy Markdown
Contributor

Design Review (Opus 5.5, fork) — ✅ PASS

Design-level review of 53099833c5e3ba8c94bc61b0c5b4faf2f0c998bf via the fork AI-review pipeline — updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

Design-Verdict: PASS

Nothing to check.

[DESIGN-REVIEWED] 5309983

Description read

[DESCRIPTION-READ] 60525be6b5aa049199741dbfc438269f9bd8c8bb2dcdc119c894da702eba3736

That sha256 names everything this verdict read: the PR description, plus the 1 evidence file(s) the workflow collected from it and handed this review. It covers that evidence because the media strip replaces every attachment URL with the same placeholder, so an edit swapping one attachment for another would leave the description's captured text identical while what this review judged changed. Recompute it with .github/scripts/pr-description-capture.sh over the same inputs; if it differs, the description or that evidence changed after this verdict was formed and any finding drawn from either is unproven.

@github-actions

Copy link
Copy Markdown
Contributor

Opus 5.5 Review (fork) — ✅ no blocking findings

Reviewed 53099833c5e3ba8c94bc61b0c5b4faf2f0c998bf via the fork AI-review pipeline; updated in place on each push.

Review details

No findings.

[OPUS-REVIEWED] 5309983

@github-actions

Copy link
Copy Markdown
Contributor

GPT 6.1 Review (fork) — ✅ no blocking findings

Reviewed 53099833c5e3ba8c94bc61b0c5b4faf2f0c998bf via the fork AI-review pipeline; updated in place on each push.

Review details

No findings.
[GPT-REVIEWED] 5309983

@github-actions

Copy link
Copy Markdown
Contributor

Security Scope Review (fork) — ✅ PASS

Which legitimate operations does 53099833c5e3ba8c94bc61b0c5b4faf2f0c998bf newly refuse? Model proposes, scripts/deny_diff.py decides — updated in place on each push. A script-confirmed regression blocks PR readiness.

adjudicated, zero confirmed regressions

Scope-Verdict: PASS

TIGHTENING: none -- the patch changes no matcher. The only code hunk edits a comment in src/kiro_crew/security/__init__.py (except Exception as exc: # incl. RecursionError and the depth cap -> # incl. RecursionError). The fail-closed handler around _rm._rm_wipe_targets behaves exactly as before. The other changes are a docs paragraph in docs/system-specs/modules/security.md and two new allow-side test cases ("RM -r /", "RM -r ~") in TestRecursiveForceRmFloor. Those tests pin the floor's existing requirement that both the recursive and the force flag be present; they don't widen what it refuses.

ADJUDICATED: 14 candidates, 0 confirmed newly-refused

PLATFORM COVERAGE: The diff adds no new path, separator, interpreter or executable assumption. The recursive-force rm floor it documents is a POSIX-spelled check (program basename rm, root /, home ~/$HOME). The posix rows probe that floor one token off the threat: recursive without force, force without recursive, descendants of /tmp, $HOME and ~, project-relative operands, a find -exec rm -rf {} + placeholder, chained rm -rf node_modules && npm ci, and rm -rf / as quoted grep data. The windows rows (Remove-Item -Recurse -Force on .\build and $env:TEMP\kc-probe, and cmd rmdir /s /q build) cover the Windows spelling of the same cleanup, so the floor can be shown not to catch it. One any row (git worktree remove --force ...) has no separator-dependent token. Every platform spelling the floor assumes has at least one candidate.

[SCOPE-REVIEWED] 5309983

Security scope review -- adjudicated candidates

  • macos-latest (platform posix): 11 classified, 0 newly refused, 9 still allowed.
  • ubuntu-latest (platform posix): 11 classified, 0 newly refused, 9 still allowed.
  • windows-latest (platform windows): 4 classified, 0 newly refused, 4 still allowed.

No candidate flipped from allowed to refused.

@github-actions github-actions Bot added readiness: passed Eligible automated validation passed for the current revision and removed readiness: checking Automated validation is still running labels Oct 18, 2026
@devansh1401

devansh1401 commented Oct 18, 2026 •

Copy link
Copy Markdown
Contributor Author

@chenmingwei23 could you take a look at this one when you get a chance?

@github-actions github-actions Bot added the merge conflict Branch has merge conflicts with its base — author must resolve before merge label Oct 18, 2026
@devansh1401

Copy link
Copy Markdown
Contributor Author

@bolichen97 could you take a look when you get a chance? this needs a maintainer branch for the sensitive-path check. happy to update the patch for the moved files.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

fork Pull request from a fork (external contributor) merge conflict Branch has merge conflicts with its base — author must resolve before merge readiness: passed Eligible automated validation passed for the current revision

Projects

None yet

Development

Successfully merging this pull request may close these issues.

test(security): pin the force flag in the rm floor and fix its error comment

1 participant