Compare commits
1
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
25f76e6e6e |
@@ -2099,5 +2099,93 @@
|
|||||||
"endLine": 322,
|
"endLine": 322,
|
||||||
"problem": "commitAndPushFindings 改成一律透過 pushWithCredential 用 PAT extraheader 推送,且新增 headRef 安全檢查與固定錯誤遮蔽;但目前 gitrepo 測試沒有覆蓋 commitAndPushFindings/pushWithCredential 的推送行為。這讓「token 不進 argv」、「清掉 checkout 既有 extraheader」、「遠端 URL 不符時拒絕」、「push 失敗不洩漏 URL/token」這些失敗與安全邊界都沒有被驗證。",
|
"problem": "commitAndPushFindings 改成一律透過 pushWithCredential 用 PAT extraheader 推送,且新增 headRef 安全檢查與固定錯誤遮蔽;但目前 gitrepo 測試沒有覆蓋 commitAndPushFindings/pushWithCredential 的推送行為。這讓「token 不進 argv」、「清掉 checkout 既有 extraheader」、「遠端 URL 不符時拒絕」、「push 失敗不洩漏 URL/token」這些失敗與安全邊界都沒有被驗證。",
|
||||||
"reason": "Paladin:可排除(重複)。歷史 findings 已涵蓋 commitAndPushFindings 與 pushWithCredential 的推送策略、認證遮蔽、失敗路徑與 token 不外洩等測試缺口。"
|
"reason": "Paladin:可排除(重複)。歷史 findings 已涵蓋 commitAndPushFindings 與 pushWithCredential 的推送策略、認證遮蔽、失敗路徑與 token 不外洩等測試缺口。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 17:25:38",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Assassin",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/diagnostics.js",
|
||||||
|
"startLine": 68,
|
||||||
|
"endLine": 71,
|
||||||
|
"problem": "攻擊者只要讓 AI CLI 失敗,並碰上 runner 開了 `ACTIONS_STEP_DEBUG=true`,就能把 CLI 的 stderr/stdout 片段推進長期保存的 CI log。這裡的遮罩是黑名單式,會漏掉不少常見秘密格式或個資,例如短 token、AWS access key、JWT 片段、email、電話、內部路徑與提示中夾帶的 diff 內容。安全邊界不能寄望「debug log 只有自己看」;repo 協作者或 CI log 讀者都可能取得這些輸出。",
|
||||||
|
"reason": "Paladin:可排除(重複)。既有紀錄已多次涵蓋 debug 模式輸出 AI CLI stderr/stdout、黑名單遮罩可繞過,以及機密或個資外洩風險;本條只是改到 diagnostics.js 後的同型指控。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 17:25:38",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Bard",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "readme.md",
|
||||||
|
"startLine": 41,
|
||||||
|
"endLine": 51,
|
||||||
|
"problem": "Mermaid 流程圖的節點 ID 從 `N3`、`N4` 一路走到 `N8`,中途又接回 `N2`。顯示文字雖然表達「步驟 2 延後」,但原始碼層面的節點命名逆行,讓文件維護者讀圖時節奏斷裂。",
|
||||||
|
"reason": "Paladin:可排除(重複)。歷史 finding 已指出流程步驟編號被當成跨模組識別值、README 流程圖出現 1、3~8、2、9~10 的逆序維護問題;本條屬同一文件編號耦合問題。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 17:25:38",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 162,
|
||||||
|
"endLine": 392,
|
||||||
|
"problem": "`main()` 這次把建問題模式的狀態機、留言緩衝、issue 建立、fallback、舊留言清理、結果 commit 判定都塞進同一個流程函式與多個閉包裡。半年後要改其中一條路徑時,很難確認 `issueModeActive`、`trackingIssue`、`pendingIssueCommentBodies`、`currentRunCommentIds` 在各分支是否仍一致;尤其建 issue 失敗後降級回 PR 留言,後面又要決定清舊留言、發嚴重問題、提交 findings,維護者需要整段流程一起讀才敢動。",
|
||||||
|
"reason": "Paladin:可排除(命中已知排除事項且重複)。已知排除與歷史 findings 已涵蓋 main() 內建問題模式、留言路由、issue 狀態、緩衝佇列與發布職責耦合的問題。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 17:25:38",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/lib/gitea.js",
|
||||||
|
"startLine": 156,
|
||||||
|
"endLine": 160,
|
||||||
|
"problem": "文件註解提到 `main()` 的 `createIssueAndFlushBufferedComments`,但這次新增的實際閉包名稱是 `openTrackingIssue`。這類失準的內部函式名引用會讓未來維護者循線找不到程式碼,久了文件會變成負債。",
|
||||||
|
"reason": "Paladin:可排除(列表內重複)。與 F002 指涉 src/lib/gitea.js 同一段 JSDoc 引用不存在的 createIssueAndFlushBufferedComments 問題。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 17:25:38",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/lib/templates.js",
|
||||||
|
"startLine": 302,
|
||||||
|
"endLine": 305,
|
||||||
|
"problem": "`issueBody()` 的 JSDoc 同樣引用不存在的 `createIssueAndFlushBufferedComments`。模板模組本來應該只說明模板用途;引用外層流程的私有閉包名稱,會讓文件跟主流程重構強耦合。",
|
||||||
|
"reason": "Paladin:可排除(列表內重複)。與 F003 指涉 src/lib/templates.js 的 issueBody JSDoc 引用不存在內部閉包名稱,屬同一問題。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 17:25:38",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 162,
|
||||||
|
"endLine": 239,
|
||||||
|
"problem": "建問題模式新增了 `queueOrPostComment`、`openTrackingIssue`、`fallbackToPrComments` 這組分流行為,但目前測試只覆蓋了部分 `review` helper,沒有驗證主流程在 issue 尚未建立時會暫存留言、建立成功後會依序 flush、建立或寫入失敗時會回退到 PR 留言。這些都是本次新增的失敗路徑,沒測到時很容易出現審查內容被靜默丟掉或留言落錯地方。",
|
||||||
|
"reason": "Paladin:可排除(重複)。歷史 findings 已涵蓋建問題模式暫存留言、建立後依序 flush、建立或 API 失敗時降級,以及無 finding 靜默通過等核心流程缺少測試。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 17:25:38",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 103,
|
||||||
|
"endLine": 158,
|
||||||
|
"problem": "`resolveMergeBase` 新增了多段 fetch 補抓策略、淺層 repo 判斷、每次 fetch 後重試 merge-base,以及全部失敗時附診斷的錯誤;目前測試只驗證不安全 `baseRef` 會在 fetch 前被拒絕,沒有測到這些新增分支。這些邊界正是 shallow checkout 最容易壞的地方。",
|
||||||
|
"reason": "Paladin:可排除(重複)。歷史 findings 已針對 resolveMergeBase 的多階段 fetch、淺層與非淺層分支、停止條件、降級與最終診斷缺少測試提出相同問題。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 17:25:38",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 287,
|
||||||
|
"endLine": 326,
|
||||||
|
"problem": "`pushWithCredential` 是新增的認證推送核心路徑,包含清掉 checkout 既有 extraheader、用 PAT extraheader 推送、遠端 URL origin 檢查,以及失敗時隱藏 URL/token;但目前沒有任何測試驗證這些行為。這裡的失敗路徑沒測到,容易在 runner 上才發現結果 commit 推不上去或錯誤訊息洩漏敏感資訊。",
|
||||||
|
"reason": "Paladin:可排除(重複)。歷史 findings 已涵蓋 pushToken/pushWithCredential、origin 與一般 token 推送策略、認證遮蔽及失敗路徑缺少測試。"
|
||||||
}
|
}
|
||||||
]
|
]
|
||||||
|
|||||||
Reference in New Issue
Block a user