Activity

1. rmcdaniel

   added

   bugSomething isn't workingSomething isn't working

   on Oct 25, 2026
2. rmcdaniel commented on Oct 25, 2026

   

   rmcdaniel

   on Oct 25, 2026

   MemberAuthor

   More actions

   Security current-state correction

   Read-only verification at 2026-10-25T19:45Z contradicts the issue's opening premise. Do not install another protection baseline from the legacy endpoint result. No setting or source was changed by this review.

   • GET /repos/durable-workflow/ai/branches/main reports protected: true at main fbdc2c98b7b7d3cb1f06b6831fd10278b9b4e380.
   • GET /repos/durable-workflow/ai/rules/branches/main returns two applicable active repository rulesets.
   • Ruleset 20880170 (Public target qualification) applies only to refs/heads/main; it strictly requires Target branch qualification from GitHub Actions App 15368, blocks deletion and non-fast-forward updates, has no bypass actors, and reports current_user_can_bypass: never.
   • Ruleset 25192813 (SonarQube quality gate) also applies only to refs/heads/main; it strictly requires SonarCloud Code Analysis from App 12526, has no bypass actors, and reports current_user_can_bypass: never.
   • The legacy branch-protection endpoint returns 404 even though the branch and applicable-rules APIs prove ruleset protection. That endpoint is therefore not sufficient current-state evidence here.
   • The exact main Sonar workflow runs pull-request analysis only when the PR head repository equals the base repository. There is no historical cross-repository PR in this repository to disprove the resulting fork-path risk. Requiring the separate Sonar context can therefore strand a fork PR when that job is intentionally skipped.
   • Merged PR Select exclusive clean trust for CI dependency requests #26 proves the same-repository happy path: all three supported PHP/Laravel matrix jobs, central action-policy preflight, Target branch qualification, and both Sonar checks succeeded. It does not qualify the fork path, missing/skipped/cancelled dependency cases, or issuer spoof resistance.

   Corrected next action

   Preserve the existing qualified-target ruleset while reconciling it with .github#240. Treat the separately required Sonar context as the current contribution-path defect: record an exact settings delta and rollback, prove the fork/missing-context behavior without weakening the qualified aggregate, then read back the applicable rules after the reviewed change. Do not add another issuer or duplicate target-qualification rule. The issue title/body should be corrected to reflect an existing-protection reconciliation rather than an unprotected branch.
3. rmcdaniel commented on Oct 25, 2026

   

   rmcdaniel

   on Oct 25, 2026

   MemberAuthor

   More actions

   Security acceptance blocker — current aggregate is candidate-spoofable

   The existing ruleset is real enforcement, but its current Target branch qualification requirement does not satisfy the issue's spoof-resistance criterion.

   GitHub's current ruleset documentation states that required status checks do not take workflow, matrix, or event trigger identity into account; the rule binds the check name and selected source App. GitHub also documents that a pull_request workflow runs from the pull request merge commit, which can be controlled by a contributor without base-repository write access. Current AI ci.yml is such a pull_request workflow, and the required job is emitted by the generic GitHub Actions App 15368.

   Consequently, a candidate can replace or alter its workflow and emit a successful job named Target branch qualification from the same expected Actions App without executing the protected-base central policy or the intended dependency matrix. Strict/up-to-date enforcement does not bind workflow identity. This is the exact authority gap addressed by draft .github#240, whose independent issuer is not activated.

   Primary documentation:

   • https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/troubleshooting-rules#troubleshooting-required-status-checks
   • https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target
   • https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-status-checks-to-pass-before-merging

   Safe sequencing

   1. Complete and live-qualify the protected independent issuer in .github#240, including fork, wrong-issuer, stale-base, malformed input, ambiguous-write, and required-rule controls.
   2. Bind AI's required aggregate context to that independent App and read back the applicable rule plus strict behavior.
   3. Only then remove or relax the separately required Sonar context after proving the fork contribution path and rollback.

   Removing the Sonar requirement before the independent issuer is active would remove the current fork-path blockade while leaving the generic Actions aggregate forgeable. Do not make either settings change independently. No live exploit PR, setting, source, or credential change was made for this review.
4. rmcdaniel

   changed the title [-]Protect main with qualified target-branch checks[/-] [+]Bind merge qualification to the independent issuer and verify fork contributions[/+] on Oct 25, 2026
5. rmcdaniel commented on Oct 25, 2026

   

   rmcdaniel

   on Oct 25, 2026

   MemberAuthor

   More actions

   Correction: I incorrectly concluded that main was unprotected from the legacy endpoint 404. Fresh branch, applicable-rules and ruleset-detail reads independently confirm both active rulesets and no bypass actors. I corrected the title/body and retained the existing .github#240-first sequencing from comments 6402160331/6402186237. No protection, source or credential setting was changed.