Allow docker-agent to request reviews on its own PRs

[derekmisler]

Closes: https://github.com/docker/gordon/issues/189

Summary

This PR adds a trust bypass in action.yml for the docker-agent[bot] GitHub App, allowing it to trigger review workflows without passing the standard author_association authorization check. This enables automated flows (e.g., auto-triage posting /review) to work end-to-end without being blocked by the comment-auth guard.

Changes

• action.yml: Exposes github.event.comment.user.login as COMMENT_USER_LOGIN and adds an early-exit check that grants authorized=bot status when the commenter is docker-agent[bot], bypassing the author_association enforcement that applies to human commenters.

How to Test

• Have docker-agent[bot] post a /review comment on a PR and confirm the workflow proceeds past the auth step (output shows authorized=bot and no auth failure).
• Confirm a non-bot user without an allowed author_association is still blocked by the existing auth logic.
• Confirm a human user with a valid author_association (e.g., MEMBER) is still authorized through the normal path.

[derekmisler]

/describe

[docker-agent]

✅ PR description has been generated and updated!

[docker-agent]

🔴 Review Summary: CRITICAL

Assessment

This PR introduces critical security vulnerabilities in the authentication bypass logic. The code allows the docker-agent[bot] user to skip authorization checks, but relies solely on username string matching without verifying the user is actually a legitimate GitHub App bot.

Key Issues

• 🔴 CRITICAL: Authentication bypass can be exploited by any user who creates a GitHub account named docker-agent[bot]
• 🟡 MEDIUM: Authorization status authorized=bot may be trusted downstream without proper verification

Findings

2 CONFIRMED issues in changed code:

• 1 HIGH severity
• 1 MEDIUM severity

Recommendation

Before merging, implement proper GitHub App verification:

1. Check github.event.comment.user.type === 'Bot'
2. Verify the app_id matches the expected GitHub App ID
3. Consider adding cryptographic verification for additional security

---

This is an automated review. The bot provides feedback only and does not block merging.

[derekmisler]

/review

[docker-agent]

Review Summary

Assessment: 🔴 CRITICAL

This PR introduces a security bypass to allow docker-agent[bot] to trigger review workflows. While the intent is legitimate, two critical security vulnerabilities were identified in the implementation:

1. Environment variable override vulnerability (HIGH): Workflow authors can inject COMMENT_USER_LOGIN and COMMENT_USER_TYPE to bypass all authorization checks
2. Authorization hierarchy flaw (HIGH): The bot bypass skips role validation that protects against unauthorized workflow triggers

Findings Summary

• 🔴 2 CRITICAL issues (high severity, confirmed)
• ⚠️ 1 NOTABLE issue (low severity, likely)

---

Details

The bot bypass implementation has significant security implications that should be addressed before merging.

[derekmisler]

/review

[docker-agent]

Review Summary

Assessment: 🔴 CRITICAL

CRITICAL security vulnerability found in the bot authorization bypass logic. The code allows empty app IDs to match, which could incorrectly grant bot-level authorization to non-app commenters.

Additional security concerns identified:

• Bot bypass skips all authorization checks without fallback verification
• Same app ID is used for both reviewer identity and authorization bypass

Findings

3 issues found (1 CRITICAL, 2 MEDIUM)

---

This is an automated review — Always use your judgment. The bot provides feedback only and never blocks or approves merges.

[docker-agent]

⚠️ MEDIUM: Bot bypass skips all authorization checks without fallback verification

When the bot bypass succeeds, the script immediately exits with authorized=bot, skipping the hardcoded ALLOWED_ROLES check that follows.

While this is by design, the lack of fallback verification creates risk if the app ID check is weak (e.g., Finding #1 shows it can succeed with empty IDs). If the app is compromised or misconfigured, this removes all authorization safeguards.

Recommendation: Add defense-in-depth:

• Log the bypass event more prominently for audit purposes
• Consider adding a secondary check that the bot has appropriate repository permissions
• Or at minimum, add explicit non-empty validation to prevent the empty ID bypass bug

[docker-agent]

⚠️ MEDIUM: Same app ID used for both reviewer identity and authorization bypass

The workflow passes secrets.CAGENT_REVIEWER_APP_ID as the trusted-bot-app-id input. This creates a circular trust model where:

• The app that posts reviews (reviewer identity)
• Is also trusted to bypass authorization checks when it comments /review

While this may be intentional for legitimate automation (e.g., a trusted triage bot triggering reviews), if the app's credentials are compromised or if someone exploits the app's webhook, this bypass would allow unauthorized reviews.

Recommendation: Consider using separate apps for triggering (automation) and posting (identity), or add additional verification that the app is being used in the expected context.

[derekmisler]

/review

[docker-agent]

🤖 Review Summary

Assessment: 🟢 APPROVE

This PR adds a trust bypass mechanism for docker-agent[bot] to trigger review workflows without standard author association checks. The implementation is secure:

✅ Bot identity verification — Checks both user.type='Bot' AND performed_via_github_app.id from GitHub's server-side event payload, which cannot be spoofed by attackers

✅ Defense in depth — The workflow-level condition allows the job to run, but the action-level auth check still enforces security

✅ Proper input validation — Uses jq to parse trusted GitHub event payload fields

The drafter raised concerns about insufficient validation of bot identity, but these were dismissed during verification because GitHub's webhook payload is authoritative and cannot be manipulated by attackers. The combination of checking user type and app ID from the event payload provides adequate security.

No blocking issues found. The changed code works correctly and securely enables the intended automated workflow.

---

Review completed by cagent • Mode: GitHub Actions

[docker-agent]

Review Summary

Assessment: 🟡 NEEDS ATTENTION

This PR adds a trust bypass mechanism for the docker-agent[bot] GitHub App to trigger review workflows without standard authorization checks. The security model is sound (using event payload data and app ID verification), but there are two confirmed issues that should be addressed:

1. Inconsistent output format: The bot bypass sets authorized=bot while standard auth uses authorized=true, creating interface inconsistency
2. Incomplete feature coverage: The bot bypass only applies to manual reviews, not auto-reviews, creating asymmetric behavior

Findings

• 2 MEDIUM severity issues requiring attention
• 1 LOW severity suggestion for defense-in-depth

[derekmisler]

/review

[docker-agent]

Review Summary

Assessment: 🟢 APPROVE

This PR adds a trust bypass mechanism for the docker-agent[bot] GitHub App to trigger review workflows without standard authorization checks. The implementation correctly leverages GitHub's cryptographically signed webhook payloads to verify bot authenticity.

Key Security Review:

• ✅ The bypass reads fields directly from GITHUB_EVENT_PATH (the signed webhook payload), which cannot be manipulated
• ✅ The trusted-bot-app-id input is sourced from repository secrets, not user-controllable inputs
• ✅ In pull_request_target context, workflow files are read from the base branch, preventing PR-based manipulation
• ✅ The logic correctly checks both user.type == 'Bot' AND performed_via_github_app.id matches the trusted ID

Verification Results:
All medium-severity hypotheses were investigated and dismissed:

1. Payload field validation concern - DISMISSED (GitHub's webhook signature verification provides sufficient security)
2. Input validation concern - DISMISSED (actual usage binds input to admin-controlled secrets)

The changed code correctly implements the intended feature without introducing security vulnerabilities. The bypass is appropriately scoped to GitHub App bots only and cannot be exploited through normal attack vectors.

---

Note: Some minor observations about edge cases (string comparison handling, documentation clarity) were identified but do not impact correctness or security. These are informational only and do not require changes.

[derekmisler]

/review

[docker-agent]

Review Summary

Assessment: 🟢 APPROVE

This PR adds a trust bypass for the docker-agent[bot] GitHub App to allow it to trigger review workflows. The security design is sound:

✅ Core Security: Reads comment.performed_via_github_app.id directly from $GITHUB_EVENT_PATH (GitHub's webhook payload), which cannot be spoofed by users or workflow inputs.

✅ Triple verification: Checks user type (Bot), app ID match, and that the app ID field is populated (only happens for genuine GitHub App comments).

Minor Configuration Considerations

All findings are informational (low severity) and relate to edge cases or defense-in-depth improvements:

• Configuration risk: The secret TRUSTED_BOT_APP_ID must be set correctly by admins. Misconfiguration would grant unintended access, though this is mitigated by GitHub's access controls.
• User type check: The code checks for exact string match "Bot" which should work for modern GitHub Apps.
• Whitespace handling: Input trimming would make the check more robust.

These are not bugs in the changed code, just potential hardening opportunities. The implementation correctly prevents spoofing and the authorization bypass is properly scoped.

Verdict

✅ No blocking issues found. The changed code implements the feature securely. The PR can proceed.

[derekmisler]

/review

[docker-agent]

Review Summary

Assessment: 🟢 APPROVE

This PR implements a trust bypass mechanism for the docker-agent[bot] GitHub App to trigger review workflows on its own PRs. The implementation is secure and well-designed.

Analysis

Security Model: The code correctly reads bot identity from the immutable GitHub event payload ($GITHUB_EVENT_PATH) and validates three conditions:

1. User type is 'Bot'
2. App ID is present in the event
3. App ID matches the trusted bot secret

This approach leverages GitHub's webhook authentication system — the performed_via_github_app.id field is set by GitHub and cannot be forged by attackers. The trust anchor is the TRUSTED_BOT_APP_ID secret, which is appropriate for this use case.

Logic Flow: The bypass executes in the correct order:

1. First checks if this is a comment-triggered event
2. Then checks for trusted bot bypass
3. Finally checks standard author_association roles

This ensures the bypass only applies to comment events (as intended) and safely falls back to role-based auth for all other cases.

No High-Priority Issues Found: The drafter identified potential concerns about string comparison and empty string handling, but verification confirmed these are not vulnerabilities:

• App IDs are GitHub-assigned numeric identifiers that cannot be forged
• String comparison is appropriate (no cryptographic validation needed)
• Empty string checks are correctly ordered
• Misconfiguration would result in safe failure (denial), not bypass

Recommendation

✅ Approve — The implementation follows security best practices for GitHub Actions authorization. The code is ready to merge.

[aheritier]

as far as the review isn't validating the merge and bypass rules it should be ok.