2026-07-15 02:38:32 +00:00
1 changed files with 90 additions and 1 deletions
@@ -1 +1,90 @@
-[]
+[
+  {
+    "level": "critical",
+    "role": "Mage",
+    "problem": "這裡在 DELETE 回傳非 204 時只寫錯誤訊息，沒有把失敗往上拋或標記成整體失敗；同樣的寫法在後面的 tag 刪除區塊也出現一次。最小重現：只要某個 release 因權限不足回 403，step 仍會繼續跑完並以成功結束，外層 workflow 會誤判清理已完成。",
+    "suggestion": "把刪除結果納入整體失敗狀態，例如遇到非 204 直接 `throw`，或累積 `hadFailure` 後在流程結束時 `process.exit(1)`，不要讓任何刪除失敗被靜默吞掉。",
+    "location": "src/index.js:302",
+    "is_new": false
+  },
+  {
+    "level": "critical",
+    "role": "Assassin",
+    "location": "src/index.js:299",
+    "problem": "這裡把 `GITEA_SERVER_URL` 直接拼進帶有 `Authorization: token ...` 的 API 請求，只檢查是不是 `https` 並不能防止攻擊者把環境變數指到自己的 HTTPS 主機。只要外部能影響這個值，就能把 runner token 一起送出，等於把這個 action 變成可用來外洩憑證的 SSRF 入口。",
+    "suggestion": "不要只驗證協定，必須把目標主機固定在預期的 Gitea 來源；改成解析 `URL` 後比對 `origin`/host 白名單，拒絕任何非預期網域，並且只在確認是可信任的 Gitea 站台時才附加 `Authorization` header。",
+    "is_new": true
+  },
+  {
+    "level": "warning",
+    "role": "Mage",
+    "problem": "這裡先抓一份 release 快照，再在後面依這份快照去刪 tag；兩個步驟之間不是同一個時間點。最小重現：cleanup 跑到一半時剛好有人新增 release，新 release 的 tag 來不及出現在 `releaseTags`，接下來的 tag 清理就可能把剛發布的 tag 誤刪。",
+    "suggestion": "把 release 與 tag 的判定建立在同一個一致性快照上，或在刪 tag 前重新驗證該 tag 目前是否已被任何 release 使用；如果環境允許，最好加上流程鎖避免與發版同時執行。",
+    "location": "src/index.js:312",
+    "is_new": false
+  },
+  {
+    "level": "warning",
+    "role": "Rogue",
+    "problem": "這裡又對 releases API 做一次完整 `fetchAllPages()`，前面第 267 行已經抓過同一份資料並排序；等於把整個分頁抓取、JSON 解析與記憶體配置再跑一遍，資料量越大越浪費。",
+    "suggestion": "直接沿用前一次抓到的 `releaseJson`，或先從第一次結果算出要保留的 tag 集合，避免第二次全量拉取。",
+    "location": "src/index.js:312",
+    "is_new": false
+  },
+  {
+    "level": "warning",
+    "role": "Rogue",
+    "problem": "tag 刪除同樣是逐筆 `await`，當 tag 數量多時會把每次 API 往返都串成排隊，刪除時間幾乎全卡在網路延遲上。",
+    "suggestion": "用受限並行處理 tag 刪除，或先收集待刪清單再批次送出，減少總等待時間。",
+    "location": "src/index.js:326",
+    "is_new": false
+  },
+  {
+    "level": "warning",
+    "role": "Assassin",
+    "location": "Dockerfile:8",
+    "problem": "這裡仍然使用可浮動的 `node:22-alpine` 標籤，沒有鎖定到不可變的 digest。攻擊者只要污染上游映像或讓標籤漂移，就可能在 action 啟動前先取得執行權，進而竊取後續流程中的 token 與 repo 資料。",
+    "suggestion": "把基底映像改成固定 digest，例如 `node:22-alpine@sha256:...`，並定期以受控流程更新；不要依賴會隨時間變動的映像標籤。",
+    "is_new": true
+  },
+  {
+    "level": "warning",
+    "role": "Leo",
+    "location": "src/index.js:1",
+    "problem": "這個檔案同時承擔 log 格式化、輸入驗證、HTTP 呼叫、分頁抓取、刪除流程與錯誤彙總，責任切得太散。半年後只要想改一個 API 規則，維護者就得在同一個大檔裡來回跳，單元測試也很難把純邏輯跟 I/O 分開。",
+    "suggestion": "把共用基礎能力拆成獨立模組，例如 `logger`、`gitea client`、`cleanup workflow`，並讓主程式只負責組裝依賴與啟動流程。",
+    "is_new": true
+  },
+  {
+    "level": "warning",
+    "role": "Mage",
+    "location": "src/index.js:177",
+    "problem": "這裡直接拒絕 `http:` 連線，導致任何使用 `http://` 的 Gitea 部署都會在第一個 API 請求就失敗。最小重現情境是把 `GITEA_SERVER_URL` 設成內網常見的 `http://gitea.local`，整個清理流程會完全無法執行。",
+    "suggestion": "若這個 action 需要支援常見的自架環境，應移除固定只允許 HTTPS 的限制，或把協定限制做成可配置；若確實只支援 HTTPS，也要在 action 說明中明確標示，避免使用者在 `http` 環境下直接踩雷。",
+    "is_new": true
+  },
+  {
+    "level": "warning",
+    "role": "Mage",
+    "location": "src/index.js:353",
+    "problem": "前面只要有任何 release 刪除失敗，這裡仍然會繼續做 tag 清理，而且 `releaseTags` 是依照刪除前的清單算出來的。最小重現情境是某個待刪 release 因權限不足或暫時性網路錯誤沒刪掉，接著它對應的 tag 仍可能被刪除，最後變成 release 還在、tag 卻被移除的半套狀態。",
+    "suggestion": "在進入 tag 清理前先檢查 release 刪除是否有失敗；只要有失敗就應中止後續 tag 刪除，或改成只把實際成功刪除的 release 對應 tag 納入待刪集合，避免留下不一致狀態。",
+    "is_new": true
+  },
+  {
+    "level": "warning",
+    "role": "Rogue",
+    "location": "src/index.js:25",
+    "problem": "每次輸出一條 log 都要跑 `Intl.DateTimeFormat.formatToParts()`，還額外建立 `lookup` 物件再組字串；這條熱路徑會在每個 release、tag 與錯誤訊息上重複消耗 CPU，訊息一多就很浪費。",
+    "suggestion": "把時間格式改成可快取的字串產生方式，例如同一秒共用結果，或改用較便宜的 formatter，不要每條 log 都做 `formatToParts()` 拆解。",
+    "is_new": true
+  },
+  {
+    "level": "warning",
+    "role": "Rogue",
+    "location": "src/index.js:184",
+    "problem": "這裡先把每一頁資料全部塞進 `all`，等於把整個 API 結果完整具現化；release/tag 數量一大時，記憶體會吃到 O(n)，而且陣列反覆擴容與拷貝也會多耗 CPU。",
+    "suggestion": "改成邊抓邊處理，不要先合併成單一大陣列；如果 API 支援，順便加大每頁筆數，減少往返次數。",
+    "is_new": true
+  }
+]