本卡屬 FR-195(Agent 資安修正),第 4 批 G2。首腦實質驗收 F9(CM-3832)F 項時發現的副作用,從那張卡拆出來補。依賴:CM-3832 已合進工作坊 branch(
0670dae)。
Agent 會自動下載新的漏洞庫資料。下載前要先確認「新的比本機現有的新」,免得被人把漏洞庫退回舊版。本機現有資料的日期是從資料目錄裡的清單檔(manifest.json)讀的。
F9(CM-3832)修了一個洞:以前清單檔讀不到時,程式當成「本機沒有資料」直接放行,等於跳過新舊比較。修法是改成「清單讀不到就停止同步」。洞是補上了,但帶來一個副作用:清單檔只要壞掉或遺失一次,這台 Agent 的漏洞庫就永遠不再更新。每一輪都卡在同一個檢查,主控台的「立即檢查更新」按鈕也救不回來,客戶的弱點比對會一直用舊資料,畫面上只有一句錯誤訊息。
這張卡讓兩邊都顧到:清單檔讀不到時,改從現行資料所在的目錄名稱讀日期。每份漏洞庫資料都放在以日期命名的目錄裡(例如 20261105),這個目錄是 Agent 在驗過原廠簽章之後自己建的,比目錄裡那個可能被改掉的清單檔更可信。這樣新舊比較照樣有效,清單壞了也不會卡死。
6cf52eb 開檔核過)guidant_agent/sync/app/vulndb_sync.py:199-212 installed_date()::206 current 不存在回 None(首次安裝,正確);:208-209 讀清單取 bundle_date;:210-211 讀不到就 raise BundleRejected("本機弱點資料清單讀不到或格式不對,無法確認版本,已停止同步")。:108-112 apply() 接住這個例外、記進 _last_error 後 return——每一輪心跳都走到這裡就回頭,永遠排不到下載。:267 _check() 裡 vulndb_bundle.assert_newer(bundle_date, installed_date())——就算排到了下載,驗新包時也會在這裡被同一個例外擋下。:123 request_check()(主控台「立即檢查更新」)只是清掉失敗冷卻、請設定通道重給一次,最後還是走 apply()。guidant_agent/scan/adapters/connectors/sbom_tools.py:230-236 read_manifest 在檔不存在、JSON 壞掉、內容不是物件時都回空 dict。磁碟異常或升級中斷後檔案損毀都會走到。:3-7):<base>/<YYYYMMDD>/ 一份完整資料,<base>/current 是相對連結指向現行那一份。:272-285 _switch() 在三道檢查(原廠簽章、日期不倒退、逐檔雜湊)都過之後,才以簽章內的日期建目錄 f"{bundle_date:%Y%m%d}" 並把 current 指過去。guidant_agent/sync/app/vulndb_sync.py
test/test_vulndb_sync.py
installed_date()(:199-212)改成三段:①current 不存在 → 回 None(不變);②清單讀得到日期 → 回那個日期(不變);③清單讀不到 → 改從 current 連結指向的目錄名讀日期:os.path.islink(link) 為真時取 os.path.basename(os.path.realpath(link)),交給既有的 vulndb_bundle.parse_bundle_date()(它本來就收 YYYYMMDD);讀得出日期就回它,並 logger.warning 一行(只講「清單讀不到,改用目錄名 X 當現行日期」)。current 是手放的實體目錄而不是連結、或連結指到非日期命名的目錄)→ 維持現在的行為 raise BundleRejected(...)。這種情況無從判斷新舊,停下來比亂收安全;錯誤訊息補一句怎麼處理:「請刪除弱點資料目錄後由 Agent 重新下載,或聯繫原廠」。None(降版檢查會放行)。兩三行,不要寫成沿革。apply()(:108-112)與 _check()(:267)不用改:它們本來就會處理 installed_date() 的回傳值與例外。vulndb_bundle.py、不要改 assert_newer 的規則(相等也拒是刻意的)。