本卡屬 FR-114 資安修正（母卡 CM-2019），第 5 批子集 C 卡 5C-5，修 SUMMARY #100（M23-4）／#135（M23-7）。#100 高，#135 中。計畫在 docs/features/FR-114-2609-security-fix-dispatch/batches/plan-b5C.md「卡 5C-5」段。
#100：意見回饋模組連接 GitHub 時，程式碼裡兩處把憑證驗證明確關掉（verify=False），等於明知故犯地用不安全連線傳輸 GitHub 存取憑證——這個模組的憑證先前已經外洩過一次（已處理），現在同一個模組仍在用這種不安全的傳輸方式。複查後確認全站真正「寫死不驗證」的只有三處：GitHub 這兩處（本卡）＋ 主專案快取服務一處（不在本卡，套件那份已修，主專案這份被漏掉）；GitLab 那半沒這個問題；員工目錄已改成可設定且預設開啟驗證；寄信那項不算（是語言內建元件的預設行為，不是我們自己關掉的）。
#135：程式算出了「哪些檔案該被過濾掉」的結果，但接下來刪除時卻用了沒過濾的清單——目前這條路走不到（現有流程一次只會傳一個檔案 ID 進來），但未來若做批次刪除功能，會在不報錯的情況下悄悄刪錯檔案。自動化掃描工具兩次都判斷「目前碰不到就不算」而漏掉這個——「程式邏輯是錯的」跟「現在有沒有人能觸發」是兩個不同的問題。
首腦核對：
/Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/.claude/worktrees/jedi-wt-fix-security/<套件目錄>（branch fix/security-b1）改，只動自己那支套件的子目錄、只 git add 該子目錄下的檔。 本卡對應單一套件 jedi-issue，worktree 建議 wt-fix-b5C-issue。jedi-issue/jedi_issue/infra/github.py:22 return Github(..., verify=False)，#100 落點一
jedi-issue/jedi_issue/infra/issue/adapter/github/github_issue_adapter.py:40 self.gh = Github(..., verify=False)，#100 落點二
jedi-issue/jedi_issue/infra/issue_upload_files/local/local_issue_attachment.py:87 matched_file_uids = file_uids_set & issue_file_uid_set，#135 算出過濾結果
jedi-issue/jedi_issue/infra/issue_upload_files/local/local_issue_attachment.py:91 刪除關聯表項目用 list(matched_file_uids)，這裡是對的
jedi-issue/jedi_issue/infra/issue_upload_files/local/local_issue_attachment.py:98 self.file_upload_service.delete_files(file_uids)，用了未過濾的 file_uids，#135 要修的行
jedi-issue/jedi_issue/infra/issue_upload_files/gitlab/gitlab_issue_attachment.py:78 同層 GitLab 版本的 delete_attachment，需開檔確認是否同樣形狀
jedi-issue/jedi_issue/infra/issue_upload_files/github/github_issue_attachment.py:112 同層 GitHub 版本，用不同機制 _filter_attachment_link，需開檔閱讀不可假設同形狀
verify=False 開關（PyGithub 拿掉這個旗標後預設就會驗證憑證）。⚠️ 功能不能壞注意：若客戶用自架 GitHub Enterprise 搭配自簽憑證，恢復驗證會讓連線失敗——這本來就是正確方向，目標是「讓客戶可以指定信任的憑證」，不是「永遠不驗證」；DEV 環境連的是公開 GitHub，拿掉旗標後應該立即正常運作。delete_attachment 裡把 :98 的 self.file_upload_service.delete_files(file_uids) 改成用已經算好的 matched_file_uids（list(matched_file_uids)，比照 :91 的寫法）。⚠️ 同層姊妹檔要一併檢查：GitLab 版本（gitlab_issue_attachment.py:78）與 GitHub 版本（github_issue_attachment.py:112，用不同機制 _filter_attachment_link）是否有相同形狀的問題——兩者都要親自開檔閱讀，不能假設跟本地版本長一樣，查到同樣問題一併修，查到沒有在回寫寫明「已核對，這兩支沒有同樣問題」。