[kevinpchen]

Summary

Add initial gittuf setup using the maintainer’s confirmed SSH key, replacing GT-01.01’s manual remediation. Add generated-repository tests for successful setup and failure cases.

Type of Change

• Bug fix (non-breaking change fixing an issue)
• New feature (non-breaking change adding functionality)
• Breaking change (fix or feature causing existing functionality to change)
• Documentation update
• Refactoring (no functional changes)

Framework Changes Checklist

If this PR modifies the darnit framework (packages/darnit/):

• Updated framework spec (docs/architecture/framework-design.md) if behavior changed
• Ran uv run python scripts/validate_sync.py --verbose and it passes

Control/TOML Changes Checklist

If this PR modifies controls or TOML configuration:

• Control metadata defined in TOML (not Python code)
• SARIF fields (description, severity, help_url) included where appropriate
• Ran validation to confirm TOML schema compliance

Testing

• Tests pass locally (uv run pytest tests/ -v)
• Added tests for new functionality (if applicable)
• Linting passes (uv run ruff check .)

AI assistance

• No AI assistance was used
• AI assistance was used

Additional Notes

[Marc-cn]

Thanks Kevin, this is in good shape. I ran the tests with gittuf 0.17.0 on PATH (RHEL 10 VM): all 7 pass, including the real initialization. The key comes only from confirmed context, .pub and unconfirmed values are refused, existing refs/gittuf/* stop it, and git config stays untouched.

One change before merge. The remediation runs python -I -m darnit_gittuf.setup, which uses whatever python is on the user's PATH. From a dev checkout that is the venv's python, but on a uv tool install or pipx install (the documented route once #623 lands) it is the system interpreter, which cannot import darnit_gittuf; here /usr/bin/python fails with ModuleNotFoundError. The test masks this by putting sys.executable's directory first on PATH. Could the setup be a registered remediation handler instead, a function in handlers.py wired through register_handlers like gittuf_verify_policy_handler? Then it runs in darnit's own interpreter wherever darnit is installed, and initialize() can stay as it is.

Two notes, not blocking: the show-ref --quiet line is the same fix as #615, so one of the two will have a trivial conflict; and how a ref-only change is reported by the executor is the question you raised on Slack, which is Mike's call and separate from this PR.

[Marc-cn]

Good scope: GT-01.01 gets a real remediation with a maintainer-confirmed key path (never contents), refuses when any refs/gittuf/* exists, and the test checks HEAD, .git/config and the working tree are untouched. Four things:

1. command = ["python", "-I", "-m", "darnit_gittuf.setup", ...] runs whatever python is first on PATH, which is often not the interpreter darnit is installed in (venv, python3-only systems), so the import fails in production. The test passes only because it prepends sys.executable's directory to PATH. Either a console-script entry point in the plugin's pyproject, or, better, an in-process remediation handler registered by the plugin like generate_threat_model_handler, which also avoids the subprocess and re-resolving context.
2. The real flow never runs in CI: every test that exercises gittuf skips unless it's on PATH. Install gittuf in the CI job, or say explicitly that this is local-only coverage.
3. A passphrase-protected key fails after the 60 s timeout with an unhelpful error (input=""). Either detect it or document that the key must be unencrypted or in ssh-agent.
4. No CHANGELOG entry under Added, and the darnit-gittuf README / GT-01.01 help don't mention the new remediation.
   Re-review after.

[kevinpchen]

Thanks for the review, Marco! I switched GT-01.01 to a registered handler and updated the test to verify setup works even when a different Python is first on PATH. I also updated the README and control help with the SSH key requirements, documented that the real-gittuf tests run locally, and added a changelog entry. The full suite passed locally. Ready for re-review.

[Marc-cn]

Approved on acf9971. All four points are in: GT-01.01's remediation is now the registered gittuf_initialize handler, so it runs in darnit's own interpreter wherever darnit is installed (the "different Python first on PATH" test proves the point); the non-interactive signing requirement (unencrypted key or ssh-agent) is in the control help and README; local-only coverage for the real gittuf flow is stated; CHANGELOG entry is there. Re-ran the suite with gittuf 0.17.0 on PATH: 46 passed, including the real initialization, with refs/gittuf/* refused when present and HEAD, .git/config and the working tree untouched.

CI hadn't run because the workflow needed approval — I've approved it; merge once it's green. Mike's note still applies separately: how the executor reports a ref-only change is his call, not this PR's.