[codeforester]

Summary

• allow GitHub Dependabot update branches through the issue-branch policy
• require the pull request author to be dependabot[bot]
• require the Dependabot head repository to be this repository
• preserve the canonical issue-backed branch policy for all other pull requests

Why

The required base/issue-branch-policy check currently rejects every open Dependabot update because generated dependabot/* branches cannot encode an issue number. This blocks routine dependency and action updates even when all functional checks pass.

This is a narrow prerequisite for the v1.0 security/dependency stabilization work tracked by #490. It does not relax the policy for human branches or fork-owned branches.

Validation

• workflow YAML parses successfully
• git diff --check passes
• the trusted-bot and same-repository checks are evaluated before the canonical branch path

Relates to #490.

[codeforester]

Implemented the review fix in commit e45a2345.

• Dependabot acceptance no longer trusts the pull request's original author.
• The policy now reads the current head commit and requires the commit author to be dependabot[bot] with a GitHub-verified, valid signature, in addition to the same-repository dependabot/* branch checks.
• This closes the collaborator-push-after-open bypass described in review.

[codeforester]

Addressed the remaining review gap in commit c5a597db.

Added a behavioral regression test that executes the workflow policy with a Dependabot-authored PR whose current head commit is an unverified collaborator commit. The policy now fails closed, so a future refactor cannot remove the current-head verification without breaking CI.

[codeforester]

The new regression test (c5a597db, tests/test_issue_branch_policy.py::test_dependabot_policy_rejects_an_unverified_collaborator_head_commit) correctly closes the TOCTOU gap I'd flagged — it mocks gh api to return a PR authored by dependabot[bot] whose head commit is actually from an unverified collaborator, and asserts the policy script rejects it. Good coverage of exactly the bypass scenario.

However, it's currently failing CI on multiple platforms, including the required Validate (windows-latest, Python 3.13) check:

• On Windows (windows-latest, all Python versions), the subprocess.run(["bash", ...]) call itself fails non-zero before the assertions even run — likely a path/quoting mismatch between the Python-generated GITHUB_OUTPUT temp path and how the embedded bash script consumes it under Git Bash.
• On Debian 12 / Fedora / WSL, the test fails because the fake gh shim script is invoked in an environment without jq on PATH, and the policy script's own jq calls fail with jq: command not found. (Not required checks, but still broken.)

Since this script only ever runs on GitHub-hosted ubuntu-latest runners in production (where bash/jq are always present), the bug this test guards against is real and the test's intent is right — it just needs to be made to pass in this repo's own cross-platform validation matrix, e.g. by skipping on non-POSIX/jq-less environments or stubbing jq too.