Decide whether a Run triggered by a label the App's own Attempt set needs approval

クローズ
  • 何か問題がありますか？
#390 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

関連するプルリクエストがすでにマージされています。

  • #745 @usine-phildl による — マージ済み

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
28/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
github, typescript
領域
backend, security

調査の方向性

Start with ADR 0007 and ADR 0022, then read ADR 0011's amendment and the GraphQL timeline slice mentioned in the issue. Compare the three proposed policies and document a decision; done means the security review concern has a chosen resolution, with any follow-up implementation scope recorded.

索引モデルが issue の本文から書いたものです。

説明

enhancement

Since #386 a Loop can run with permissions: read: its token has contents: read and keeps issues: write and pull_requests: write, so a review Agent still posts reviews and comments and moves labels. Moving labels is how a review Loop hands work on (review-passed to finish-pr), so a read Attempt can start a write Run by design. ADR 0011's 2026-10-19 amendment and the loop file reference say so.

What nothing records today is who set the trigger label. A label the operator set on the Board and a label the App's own Attempt set look the same to polling (ADR 0007: the Event is the Item's content), so a Loop with approval: none opens a Run either way. A misbehaving or prompt-injected review Agent could therefore chain into a write Run without a person in the loop, on a repository that may be public.

Options to weigh, not to build yet:

  1. Keep it as is. The cycle budget (ADR 0022) bounds the chain, and the operator chose approval: none on the write Loop knowing review Loops feed it.
  2. Record the label's actor from the Item's timeline (the GraphQL slice already carries label events with their actor) and expose it to if: expressions, so a Loop author can write approval: required for App-set labels only, or refuse them.
  3. Require approval for any Run whose trigger label was last set by the App's own bot login, as an engine rule.

Option 2 keeps the decision with the Loop author and uses an open mechanism rather than a new per-type rule. Raised by the security review of #386 on 2026-10-19; related to #226, #231, #243.

Decisions (2026-10-28)

Expose the label's actor to if: and let loop authors decide; no engine rule and no new per-type setting.

  • Add, for each current label of an item, the actor and time of its last LabeledEvent to the polling slice and the if: payload (packages/github/src/polling/payload.ts, packages/config/src/payload-slices.ts), for example item.labelEvents["ready-for-agent"].actor.login and .actor.type (Bot or User). Fetch it in the same polling query; measure the extra GraphQL cost in the pull request.
  • Document the fields in the expressions reference, with an example if: that requires approval when the App itself set the label.
  • Keep the cycle budget as the bound it is today.
主要言語
TypeScript
スター
1
フォーク
0
平均マージ
4時間 26分
マージ済み PR（30日）
280

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

basaltbytes/usine のほかの issue

basaltbytes/usine の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。