Log for Ubuntu 台灣社群
LLM 產生的資安回報，促使 Linux 核心刪減舊有程式碼 （★ 73 分）
Linux 核心近期出現一波刪減舊有網路程式碼的提案，主因不是大型語言模型 (LLM) 直接幫忙精簡架構，而是人工智慧 (AI) 產生的資安瑕疵回報暴增後，維護成本已經高到難以承受。提案涵蓋 ISA (舊式擴充匯流排標準) 與 PCMCIA (舊式筆電擴充卡規格) 乙太網路驅動程式、兩個 PCI (Peripheral Component Interconnect，周邊元件互連) 驅動程式、AX.25 (業餘無線電封包通訊協定) 與相關業餘無線電子系統，以及 ATM (Asynchronous Transfer Mode，非同步傳輸模式) 和 ISDN (Integrated Services Digital Network，整合服務數位網路) 子系統。維護者以業餘無線電為例直言，這些程式多年來一直是 syzbot (Linux 核心自動模糊測試與錯誤回報機器人) 的高頻目標，如今又沒有人願意協助處理 AI 產生的大量回報，只能考慮把功能移出主線樹 (out of tree，改由核心外維護) 來保住維護團隊的理智。
不少人認為，LLM 只是把早該面對的現實照得更清楚：大型專案裡有些程式碼幾乎沒人熟悉、近年的修補多半來自靜態分析工具，甚至連是否還有真實使用者都說不準，繼續留在主線只是讓它看起來像「有人維護」。在這種觀點下，刪除或外移這些功能並不是向 AI 投降，而是承認技術債已經大到不值得再由整個 Linux 生態系共同承擔。不過反方也提醒，老舊不代表無用，尤其在工業設備或特殊擴充情境中，PCMCIA、ISA 這類介面可能仍以轉接卡或既有系統形式存在，一旦主線撤掉支援，現場就可能被迫停留在舊版核心。
討論因此延伸到誰該付維護成本這個更現實的問題。有人主張，服役數十年、價格高昂的工業設備，本來就應該由製造商、整合商、現有持有者或其委外廠商出資維護，而不是持續依賴上游志工無償照顧；也有人反駁，現實常是設備仍在用、原廠卻早已消失，等到使用者升級到新的長期支援版時，才發現關鍵功能已被拿掉。另有意見建議，發行版可以依模組的維護程度與實際用途分級，不常用的功能改成額外安裝，並限制自動載入，以縮小攻擊面；但也有人指出，Linux 長期沒有穩定的驅動程式應用程式介面 (API, Application Programming Interface)，要在核心外維護這些驅動程式，本身就是一項不小的負擔。
業餘無線電相關功能最引發情緒反彈，因為不少人認為它不只是懷舊興趣，對偏遠地區通訊、實驗文化與某些網狀網路應用仍有價值。但贊成移除的人則強調，問題不是功能有沒有趣，而是沒人維護的核心程式是否還該繼續存在；若 AX.25 等協定能用使用者空間 (user space，非核心特權層) 工具實作，就沒有必要繼續把高權限、少人照看的協定堆疊放在核心裡。也有人補充，真正的風險不一定來自真的插了相關硬體的機器，而可能來自模組自動載入，讓本來不需要這些功能的系統也暴露在額外攻擊面前。
對 LLM 在資安研究上的實際價值，意見仍然分裂。質疑者認為，這類工具雖然現在比幾個月前有進步，仍會吐出大量誤報，若沒有熟悉核心程式的人逐一驗證，只會讓真正危險的問題被噪音淹沒；贊成者則說，最近的品質已跨過可用門檻，尤其在老舊 C 語言程式碼的記憶體安全問題上，已經能大幅降低找漏洞的人力成本。至於有人提出以 Rust 程式語言重寫這些驅動程式，回應多半認為語言只能降低部分風險，卻不能取代長期維護；若沒有人願意持續照顧，重寫只是把舊技術債換成新技術債。整體風向偏向務實收縮：把長期乏人照料、可由外部模組或使用者空間承接的功能移出主線，把有限人力留給真正有人維護、也確實仍被廣泛使用的部分。
👥 52 則討論、評論 💬
https://news.ycombinator.com/item?id=47862230
Linux 核心近期出現一波刪減舊有網路程式碼的提案，主因不是大型語言模型 (LLM) 直接幫忙精簡架構，而是人工智慧 (AI) 產生的資安瑕疵回報暴增後，維護成本已經高到難以承受。提案涵蓋 ISA (舊式擴充匯流排標準) 與 PCMCIA (舊式筆電擴充卡規格) 乙太網路驅動程式、兩個 PCI (Peripheral Component Interconnect，周邊元件互連) 驅動程式、AX.25 (業餘無線電封包通訊協定) 與相關業餘無線電子系統，以及 ATM (Asynchronous Transfer Mode，非同步傳輸模式) 和 ISDN (Integrated Services Digital Network，整合服務數位網路) 子系統。維護者以業餘無線電為例直言，這些程式多年來一直是 syzbot (Linux 核心自動模糊測試與錯誤回報機器人) 的高頻目標，如今又沒有人願意協助處理 AI 產生的大量回報，只能考慮把功能移出主線樹 (out of tree，改由核心外維護) 來保住維護團隊的理智。
不少人認為，LLM 只是把早該面對的現實照得更清楚：大型專案裡有些程式碼幾乎沒人熟悉、近年的修補多半來自靜態分析工具，甚至連是否還有真實使用者都說不準，繼續留在主線只是讓它看起來像「有人維護」。在這種觀點下，刪除或外移這些功能並不是向 AI 投降，而是承認技術債已經大到不值得再由整個 Linux 生態系共同承擔。不過反方也提醒，老舊不代表無用，尤其在工業設備或特殊擴充情境中，PCMCIA、ISA 這類介面可能仍以轉接卡或既有系統形式存在，一旦主線撤掉支援，現場就可能被迫停留在舊版核心。
討論因此延伸到誰該付維護成本這個更現實的問題。有人主張，服役數十年、價格高昂的工業設備，本來就應該由製造商、整合商、現有持有者或其委外廠商出資維護，而不是持續依賴上游志工無償照顧；也有人反駁，現實常是設備仍在用、原廠卻早已消失，等到使用者升級到新的長期支援版時，才發現關鍵功能已被拿掉。另有意見建議，發行版可以依模組的維護程度與實際用途分級，不常用的功能改成額外安裝，並限制自動載入，以縮小攻擊面；但也有人指出，Linux 長期沒有穩定的驅動程式應用程式介面 (API, Application Programming Interface)，要在核心外維護這些驅動程式，本身就是一項不小的負擔。
業餘無線電相關功能最引發情緒反彈，因為不少人認為它不只是懷舊興趣，對偏遠地區通訊、實驗文化與某些網狀網路應用仍有價值。但贊成移除的人則強調，問題不是功能有沒有趣，而是沒人維護的核心程式是否還該繼續存在；若 AX.25 等協定能用使用者空間 (user space，非核心特權層) 工具實作，就沒有必要繼續把高權限、少人照看的協定堆疊放在核心裡。也有人補充，真正的風險不一定來自真的插了相關硬體的機器，而可能來自模組自動載入，讓本來不需要這些功能的系統也暴露在額外攻擊面前。
對 LLM 在資安研究上的實際價值，意見仍然分裂。質疑者認為，這類工具雖然現在比幾個月前有進步，仍會吐出大量誤報，若沒有熟悉核心程式的人逐一驗證，只會讓真正危險的問題被噪音淹沒；贊成者則說，最近的品質已跨過可用門檻，尤其在老舊 C 語言程式碼的記憶體安全問題上，已經能大幅降低找漏洞的人力成本。至於有人提出以 Rust 程式語言重寫這些驅動程式，回應多半認為語言只能降低部分風險，卻不能取代長期維護；若沒有人願意持續照顧，重寫只是把舊技術債換成新技術債。整體風向偏向務實收縮：把長期乏人照料、可由外部模組或使用者空間承接的功能移出主線，把有限人力留給真正有人維護、也確實仍被廣泛使用的部分。
👥 52 則討論、評論 💬
https://news.ycombinator.com/item?id=47862230
我們發現一個穩定的 Firefox 識別碼，可把你在 Tor 中所有私密身分串聯起來 （★ 131 分）
一項新揭露的隱私漏洞顯示，所有採用 Gecko (Firefox 的瀏覽器引擎) 的瀏覽器，都可能讓網站從 IndexedDB (瀏覽器端結構化資料庫 API) 的回傳順序中，推導出一個在瀏覽器行程存活期間固定不變的識別碼。網站只要先建立一組固定名稱的資料庫，再呼叫 indexedDB.databases() 觀察列出順序，就能在彼此無關的網站來源 (origin) 之間辨認出同一個 Firefox 或 Tor Browser (Tor 匿名瀏覽器) 執行個體。這不需要 cookie (網站儲存在瀏覽器的小型識別資料)、localStorage (瀏覽器本機儲存機制) 或任何明確的跨站管道，卻足以把不同網站的活動串在一起；在 Firefox 私密瀏覽模式中，甚至在所有私密視窗都關閉後，只要主程式仍未結束，這個識別碼就會持續存在。在 Tor Browser 裡，它還能穿透 New Identity 功能原本承諾的重設效果，削弱使用者期待的不可串聯性。
問題根源在於 Firefox 私密瀏覽時，會把網站自行命名的資料庫名稱對應到 UUID (通用唯一識別碼) 為基礎的檔名，並把這層對照放在以整個瀏覽器行程為範圍的雜湊表中，而不是限制在單一網站來源。之後 indexedDB.databases() 蒐集資料庫中繼資料時，又沒有先做固定排序，而是直接依照內部雜湊結構的迭代順序回傳結果；於是這個看似無害的 API，反而洩漏了穩定且高容量的指紋特徵。若網站控制 16 個資料庫名稱，理論上就可形成約 44 位元的熵 (entropy，代表可區分程度)，足以在實務上強力辨識同時存在的瀏覽器個體。Mozilla 已在 Firefox 150 與 Firefox ESR 140.10.0 (Extended Support Release，延長支援版本) 修正此問題，做法也相對直接，就是在回傳前先用固定規則排序，移除來自內部儲存排列的識別特徵。
討論焦點之一是 Tor Browser 的修補速度。有人起初擔心文章只提到已通報 Mozilla，卻沒交代 Tor Project 何時處理；隨後就有讀者補充，Tor Browser 平常就會緊跟 Firefox ESR，且隔天已發布修正版。另一條熱烈討論則圍繞在揭露者 Fingerprint.com 的角色：有人肯定研究品質，也好奇一家販售瀏覽器指紋產品的公司，為何會主動通報這種漏洞。贊成這種作法的人認為，這次屬於明顯的實作缺陷，與一般利用瀏覽器既有差異做辨識的作法仍有界線；質疑者則反問，幾乎所有指紋技術都建立在軟硬體未預期的行為上，兩者的道德差別沒有那麼清楚。也有人直言，這個識別碼只在單一瀏覽器行程內穩定，對數月等級的長期追蹤價值較低，或許正因如此才更容易被公開。
其餘回應則補上實務面的限制與緩解方式。多名讀者指出，若關閉 JavaScript (網頁腳本語言)，網站通常就無法輕易執行這類利用程式，但也有人提醒，在一般網站環境裡停用 JavaScript 可能讓自己落入更小的辨識群體；不過在 Tor Browser 的族群中，關閉 JavaScript 也許比外界想像更常見。另有人釐清，跨來源共享的不是 IndexedDB 內容本身，而是資料庫名稱與 UUID 的內部對照及其排列，因此網站看不到別站資料，只能藉由同一組順序取得相同指紋。還有人提到，雖然瀏覽器完整重啟後識別碼會改變，但許多人其實長時間不關瀏覽器，追蹤者也可能把這種短期指紋與 cookie 串接，延續辨識效果；相較之下，像 Qubes OS 這類把不同工作拆到獨立虛擬機器的作法，因每個 VM (Virtual Machine，虛擬機器) 都有不同瀏覽器行程，較能降低這類風險。也有少數人把問題延伸到整個 Web 標準設計，認為像 IndexedDB、Canvas (網頁繪圖 API) 這類功能若暴露過多內部差異，就會不斷成為指紋追蹤素材，瀏覽器應更嚴格收斂可被網站觀察的細節。
👥 46 則討論、評論 💬
https://news.ycombinator.com/item?id=47866697
一項新揭露的隱私漏洞顯示，所有採用 Gecko (Firefox 的瀏覽器引擎) 的瀏覽器，都可能讓網站從 IndexedDB (瀏覽器端結構化資料庫 API) 的回傳順序中，推導出一個在瀏覽器行程存活期間固定不變的識別碼。網站只要先建立一組固定名稱的資料庫，再呼叫 indexedDB.databases() 觀察列出順序，就能在彼此無關的網站來源 (origin) 之間辨認出同一個 Firefox 或 Tor Browser (Tor 匿名瀏覽器) 執行個體。這不需要 cookie (網站儲存在瀏覽器的小型識別資料)、localStorage (瀏覽器本機儲存機制) 或任何明確的跨站管道，卻足以把不同網站的活動串在一起；在 Firefox 私密瀏覽模式中，甚至在所有私密視窗都關閉後，只要主程式仍未結束，這個識別碼就會持續存在。在 Tor Browser 裡，它還能穿透 New Identity 功能原本承諾的重設效果，削弱使用者期待的不可串聯性。
問題根源在於 Firefox 私密瀏覽時，會把網站自行命名的資料庫名稱對應到 UUID (通用唯一識別碼) 為基礎的檔名，並把這層對照放在以整個瀏覽器行程為範圍的雜湊表中，而不是限制在單一網站來源。之後 indexedDB.databases() 蒐集資料庫中繼資料時，又沒有先做固定排序，而是直接依照內部雜湊結構的迭代順序回傳結果；於是這個看似無害的 API，反而洩漏了穩定且高容量的指紋特徵。若網站控制 16 個資料庫名稱，理論上就可形成約 44 位元的熵 (entropy，代表可區分程度)，足以在實務上強力辨識同時存在的瀏覽器個體。Mozilla 已在 Firefox 150 與 Firefox ESR 140.10.0 (Extended Support Release，延長支援版本) 修正此問題，做法也相對直接，就是在回傳前先用固定規則排序，移除來自內部儲存排列的識別特徵。
討論焦點之一是 Tor Browser 的修補速度。有人起初擔心文章只提到已通報 Mozilla，卻沒交代 Tor Project 何時處理；隨後就有讀者補充，Tor Browser 平常就會緊跟 Firefox ESR，且隔天已發布修正版。另一條熱烈討論則圍繞在揭露者 Fingerprint.com 的角色：有人肯定研究品質，也好奇一家販售瀏覽器指紋產品的公司，為何會主動通報這種漏洞。贊成這種作法的人認為，這次屬於明顯的實作缺陷，與一般利用瀏覽器既有差異做辨識的作法仍有界線；質疑者則反問，幾乎所有指紋技術都建立在軟硬體未預期的行為上，兩者的道德差別沒有那麼清楚。也有人直言，這個識別碼只在單一瀏覽器行程內穩定，對數月等級的長期追蹤價值較低，或許正因如此才更容易被公開。
其餘回應則補上實務面的限制與緩解方式。多名讀者指出，若關閉 JavaScript (網頁腳本語言)，網站通常就無法輕易執行這類利用程式，但也有人提醒，在一般網站環境裡停用 JavaScript 可能讓自己落入更小的辨識群體；不過在 Tor Browser 的族群中，關閉 JavaScript 也許比外界想像更常見。另有人釐清，跨來源共享的不是 IndexedDB 內容本身，而是資料庫名稱與 UUID 的內部對照及其排列，因此網站看不到別站資料，只能藉由同一組順序取得相同指紋。還有人提到，雖然瀏覽器完整重啟後識別碼會改變，但許多人其實長時間不關瀏覽器，追蹤者也可能把這種短期指紋與 cookie 串接，延續辨識效果；相較之下，像 Qubes OS 這類把不同工作拆到獨立虛擬機器的作法，因每個 VM (Virtual Machine，虛擬機器) 都有不同瀏覽器行程，較能降低這類風險。也有少數人把問題延伸到整個 Web 標準設計，認為像 IndexedDB、Canvas (網頁繪圖 API) 這類功能若暴露過多內部差異，就會不斷成為指紋追蹤素材，瀏覽器應更嚴格收斂可被網站觀察的細節。
👥 46 則討論、評論 💬
https://news.ycombinator.com/item?id=47866697
Arch Linux 現已推出可逐位元完全重現的 Docker 映像 （★ 104 分）
Arch Linux 已推出可逐位元完全重現的 Docker 映像，延續幾個月前其 WSL (Windows Subsystem for Linux，Windows 的 Linux 子系統) 映像達成相同目標的成果。新映像目前以 repro 標籤發行，核心意義是同一份來源與流程反覆建置後，產物可以維持完全一致，讓映像驗證、追溯與供應鏈安全更有根據。不過為了確保可重現性，映像內的 pacman 套件簽章金鑰被移除，因此 pacman 不是開箱即用；使用者需先在容器內重新初始化 pacman-key 並載入 Arch Linux 的金鑰圈，之後才能安裝或更新套件，Distrobox 使用者也能把這一步放進前置初始化指令。
作者指出，最大難題在於把 Docker 映像的基礎 rootFS (root filesystem，根檔案系統) 做成具決定性的建置流程，這部分沿用了 WSL 映像的方法，再針對 Docker 補上幾項關鍵調整：設定 SOURCE_DATE_EPOCH 這個可重現建置常用的時間基準，並讓 OCI (Open Container Initiative，開放容器倡議) 映像的建立時間標籤遵守它；移除會引入非決定性差異的 ldconfig 輔助快取檔；以及在 docker build 或 podman build 時重寫時間戳，統一檔案時間。Arch Linux 團隊再以多次建置後的映像雜湊摘要相同，以及使用 diffoci 這個容器差異比對工具檢查結果一致，來確認映像確實可重現。作者也提到，未來可能在自己的伺服器上架設 rebuilder (自動重建驗證節點)，定期重建最新映像並公開建置紀錄與驗證結果。
討論延伸到這類成果的實際價值。有人形容，可重現映像平常像是「不起眼但必要」的工程工作，真正發生事件時才知道它多重要；有團隊就曾因兩個理應相同的映像只差 3 個位元組的時間戳，而花了一整個下午從錯誤方向追查問題。也有人從韌體與安全關鍵領域出發，認為可重現建置不只是為了理想化的純淨產物，而是認證、稽核、安全與可靠度的基礎，而套件管理器金鑰往往正是最後最難處理的障礙。
另一波意見則聚焦在「可重現」與「持續更新」之間的拉扯。有人提到 Debian 的可重現建置計畫，以及 Debian、Ubuntu 提供的 snapshot mirror (快照鏡像站)，可把套件清單固定在特定日期，讓映像內容更容易追溯與稽核；但也有人提醒，固定舊快照並不等於安全，因為舊映像仍會累積已知漏洞，所以定期重建與更新依然必要。對此，有人批評在 Dockerfile 內直接執行 apt-get update 是反模式，主張應明確固定版本或快照；也有人認為 Nix 這類宣告式建置工具、lockfile (鎖定檔) 與 binary cache (二進位快取) 早已提供更完整的路線，但反方則指出 Nix 套件的新鮮度、相依複雜度與近期安全議題也未必總是理想。整體來看，多數人肯定 Arch Linux 這一步對容器供應鏈透明度的提升，也認為它讓日後的驗證、除錯與稽核工作更扎實。
👥 35 則討論、評論 💬
https://news.ycombinator.com/item?id=47871519
Arch Linux 已推出可逐位元完全重現的 Docker 映像，延續幾個月前其 WSL (Windows Subsystem for Linux，Windows 的 Linux 子系統) 映像達成相同目標的成果。新映像目前以 repro 標籤發行，核心意義是同一份來源與流程反覆建置後，產物可以維持完全一致，讓映像驗證、追溯與供應鏈安全更有根據。不過為了確保可重現性，映像內的 pacman 套件簽章金鑰被移除，因此 pacman 不是開箱即用；使用者需先在容器內重新初始化 pacman-key 並載入 Arch Linux 的金鑰圈，之後才能安裝或更新套件，Distrobox 使用者也能把這一步放進前置初始化指令。
作者指出，最大難題在於把 Docker 映像的基礎 rootFS (root filesystem，根檔案系統) 做成具決定性的建置流程，這部分沿用了 WSL 映像的方法，再針對 Docker 補上幾項關鍵調整：設定 SOURCE_DATE_EPOCH 這個可重現建置常用的時間基準，並讓 OCI (Open Container Initiative，開放容器倡議) 映像的建立時間標籤遵守它；移除會引入非決定性差異的 ldconfig 輔助快取檔；以及在 docker build 或 podman build 時重寫時間戳，統一檔案時間。Arch Linux 團隊再以多次建置後的映像雜湊摘要相同，以及使用 diffoci 這個容器差異比對工具檢查結果一致，來確認映像確實可重現。作者也提到，未來可能在自己的伺服器上架設 rebuilder (自動重建驗證節點)，定期重建最新映像並公開建置紀錄與驗證結果。
討論延伸到這類成果的實際價值。有人形容，可重現映像平常像是「不起眼但必要」的工程工作，真正發生事件時才知道它多重要；有團隊就曾因兩個理應相同的映像只差 3 個位元組的時間戳，而花了一整個下午從錯誤方向追查問題。也有人從韌體與安全關鍵領域出發，認為可重現建置不只是為了理想化的純淨產物，而是認證、稽核、安全與可靠度的基礎，而套件管理器金鑰往往正是最後最難處理的障礙。
另一波意見則聚焦在「可重現」與「持續更新」之間的拉扯。有人提到 Debian 的可重現建置計畫，以及 Debian、Ubuntu 提供的 snapshot mirror (快照鏡像站)，可把套件清單固定在特定日期，讓映像內容更容易追溯與稽核；但也有人提醒，固定舊快照並不等於安全，因為舊映像仍會累積已知漏洞，所以定期重建與更新依然必要。對此，有人批評在 Dockerfile 內直接執行 apt-get update 是反模式，主張應明確固定版本或快照；也有人認為 Nix 這類宣告式建置工具、lockfile (鎖定檔) 與 binary cache (二進位快取) 早已提供更完整的路線，但反方則指出 Nix 套件的新鮮度、相依複雜度與近期安全議題也未必總是理想。整體來看，多數人肯定 Arch Linux 這一步對容器供應鏈透明度的提升，也認為它讓日後的驗證、除錯與稽核工作更扎實。
👥 35 則討論、評論 💬
https://news.ycombinator.com/item?id=47871519