Log for Ubuntu 台灣社群
照這篇的說法，snap 更新的邏輯是 client 傳自己的 App list 給 store 然後 store 回傳哪些要更新？這樣 store 要跑動態程式而不只是提供靜態檔案的意思？這樣隱私也相對純靜態不友善？
Store 應該拿不到能識別使用者的相關資訊（只有客戶端 UUID）所以沒有隱私問題
另外就是 Store 有支援漸進式更新(progressive releases)所以客戶端不一定會被推薦最新版本，這部份只能動態做掉
另外就是 Store 有支援漸進式更新(progressive releases)所以客戶端不一定會被推薦最新版本，這部份只能動態做掉
有人可以解釋一下，Cloudflare 到底有沒有勒索 Canonical？ （★ 98 分）
文章指出，2026 年 4 月 30 日 16:33 UTC 起，Canonical 的 blog.ubuntu.com 先被監控系統標為服務中斷，接著 ubuntu.com、canonical.com、開發者入口、訓練平台與 Ubuntu 安全公告 API（應用程式介面）等公開服務在約 10 分鐘內陸續受影響，整體中斷約 20 小時。聲稱犯案的是自稱親伊朗的 Islamic Cyber Resistance in Iraq／313 Team，並表示租用了 Beamed 這類商用 DDoS（分散式阻斷服務攻擊）壓力測試服務。文章特別指出，Beamed 公開宣傳可繞過 Cloudflare 防護，其網站與登入入口本身卻由 Cloudflare 代理；而 Canonical 之後將 security.ubuntu.com 與 archive.ubuntu.com 兩個關鍵 Ubuntu 套件倉庫端點移到 Cloudflare AS13335（Cloudflare 的自治系統編號）後恢復穩定，形成作者所稱「Cloudflare 替攻擊者免費做前端防護，又向受害者收取救援費用」的疑問。
作者進一步整理公開紀錄，包含 Beamed 網域註冊商 Immaterialism Limited、Companies House（英國公司登記機關）資料、RIPE（歐洲網路協調中心的網路資源資料庫）中的 AS39287 轉移，以及 Let’s Encrypt 憑證透明度紀錄。文章稱，2026 年 2 月 27 日同一天出現多個事件：AS39287 轉到羅馬尼亞的 Materialism s.r.l. 名下，Immaterialism Limited 提交公司資料變更，Canonical 的 archive.ubuntu.com、security.ubuntu.com 等 apex 主機名稱也更新了來源端 TLS 憑證；作者認為，這些憑證是日後把端點放到 CDN（內容傳遞網路）後仍維持加密連線的前提。到了攻擊當天，兩個倉庫端點比其他站點晚約 3 小時才被打，之後在狀態頁反覆中斷與恢復，直到 20:50 至 20:51 UTC 左右同時穩定，且解析到 Cloudflare 位址；其他 Canonical 站點則仍留在自家 AS41231 空間。文章因此主張，雖沒有可見的贖金、加密貨幣流向或威脅信，但實際移動的是付費訂閱關係，並把這種結構類比為數位版保護費模式。
Hacker News 討論對這個指控分歧很大。批評者認為文章把「Cloudflare 代理攻擊者的宣傳網站」與「Cloudflare 提供攻擊流量」混為一談，稱「向 Cloudflare 租用攻擊能力」並不準確；攻擊者即使不用 Cloudflare，也能改用其他主機、Telegram 或隱私代理服務宣傳。也有人指出，Cloudflare 免費方案幾乎任何人都能使用，這更像是缺乏審查與濫用回報流程失靈，而不是能證明 Cloudflare 與攻擊者有直接商業合作或共謀。部分留言也補充，若要要求 Cloudflare 提供帳戶身分或下架，通常需要法院傳票等正式法律程序，單靠一般使用者通報未必會有結果。
另一派則認為，即使沒有主觀共謀，Cloudflare 的角色仍有明顯利益衝突：它可以同時保護惡意服務的可用性，又向受害者販售 DDoS 防護，讓攻擊造成的外部成本由受害者承擔。留言中也有人把這與詐騙廣告、釣魚網站長期躲在大型平台或代理服務後方相比，主張大型網路基礎設施公司應承擔更多濫用治理責任。討論最後延伸到網際網路基礎協定的弱點、DDoS 防護必須依靠巨大容量、匿名性與責任歸屬難以兼得等問題；整體看來，多數較審慎的觀點承認此事件揭露了 DDoS 防護市場的結構性誘因問題，但不認為現有公開資料足以證明 Cloudflare 曾蓄意勒索 Canonical。
👥 46 則討論、評論 💬
https://news.ycombinator.com/item?id=48098537
文章指出，2026 年 4 月 30 日 16:33 UTC 起，Canonical 的 blog.ubuntu.com 先被監控系統標為服務中斷，接著 ubuntu.com、canonical.com、開發者入口、訓練平台與 Ubuntu 安全公告 API（應用程式介面）等公開服務在約 10 分鐘內陸續受影響，整體中斷約 20 小時。聲稱犯案的是自稱親伊朗的 Islamic Cyber Resistance in Iraq／313 Team，並表示租用了 Beamed 這類商用 DDoS（分散式阻斷服務攻擊）壓力測試服務。文章特別指出，Beamed 公開宣傳可繞過 Cloudflare 防護，其網站與登入入口本身卻由 Cloudflare 代理；而 Canonical 之後將 security.ubuntu.com 與 archive.ubuntu.com 兩個關鍵 Ubuntu 套件倉庫端點移到 Cloudflare AS13335（Cloudflare 的自治系統編號）後恢復穩定，形成作者所稱「Cloudflare 替攻擊者免費做前端防護，又向受害者收取救援費用」的疑問。
作者進一步整理公開紀錄，包含 Beamed 網域註冊商 Immaterialism Limited、Companies House（英國公司登記機關）資料、RIPE（歐洲網路協調中心的網路資源資料庫）中的 AS39287 轉移，以及 Let’s Encrypt 憑證透明度紀錄。文章稱，2026 年 2 月 27 日同一天出現多個事件：AS39287 轉到羅馬尼亞的 Materialism s.r.l. 名下，Immaterialism Limited 提交公司資料變更，Canonical 的 archive.ubuntu.com、security.ubuntu.com 等 apex 主機名稱也更新了來源端 TLS 憑證；作者認為，這些憑證是日後把端點放到 CDN（內容傳遞網路）後仍維持加密連線的前提。到了攻擊當天，兩個倉庫端點比其他站點晚約 3 小時才被打，之後在狀態頁反覆中斷與恢復，直到 20:50 至 20:51 UTC 左右同時穩定，且解析到 Cloudflare 位址；其他 Canonical 站點則仍留在自家 AS41231 空間。文章因此主張，雖沒有可見的贖金、加密貨幣流向或威脅信，但實際移動的是付費訂閱關係，並把這種結構類比為數位版保護費模式。
Hacker News 討論對這個指控分歧很大。批評者認為文章把「Cloudflare 代理攻擊者的宣傳網站」與「Cloudflare 提供攻擊流量」混為一談，稱「向 Cloudflare 租用攻擊能力」並不準確；攻擊者即使不用 Cloudflare，也能改用其他主機、Telegram 或隱私代理服務宣傳。也有人指出，Cloudflare 免費方案幾乎任何人都能使用，這更像是缺乏審查與濫用回報流程失靈，而不是能證明 Cloudflare 與攻擊者有直接商業合作或共謀。部分留言也補充，若要要求 Cloudflare 提供帳戶身分或下架，通常需要法院傳票等正式法律程序，單靠一般使用者通報未必會有結果。
另一派則認為，即使沒有主觀共謀，Cloudflare 的角色仍有明顯利益衝突：它可以同時保護惡意服務的可用性，又向受害者販售 DDoS 防護，讓攻擊造成的外部成本由受害者承擔。留言中也有人把這與詐騙廣告、釣魚網站長期躲在大型平台或代理服務後方相比，主張大型網路基礎設施公司應承擔更多濫用治理責任。討論最後延伸到網際網路基礎協定的弱點、DDoS 防護必須依靠巨大容量、匿名性與責任歸屬難以兼得等問題；整體看來，多數較審慎的觀點承認此事件揭露了 DDoS 防護市場的結構性誘因問題，但不認為現有公開資料足以證明 Cloudflare 曾蓄意勒索 Canonical。
👥 46 則討論、評論 💬
https://news.ycombinator.com/item?id=48098537
最讓我無法接受的是多年來直至今日用 packages.ubuntu.com 查資料都還是三不五時會遇到 500 Internal Server Error 需要重整，反而在非商業的 Debian 完全沒遇過
QNAP NAS 權限提升漏洞
via 香港網絡安全事故協調中心資安快訊 -- 警報及博錄頻道 https://www.hkcert.org/tc/security-bulletin/qnap-nas-elevation-of-privilege-vulnerability_20260512
via 香港網絡安全事故協調中心資安快訊 -- 警報及博錄頻道 https://www.hkcert.org/tc/security-bulletin/qnap-nas-elevation-of-privilege-vulnerability_20260512
Linux 核心將停止支援 AMD K5 CPU
在 Linux 7.1 逐步停止支援已有 37 年歷史的 Intel i486 CPU 之後，Linux 7.2 將停止支援已有 30 年歷史的 AMD K5 CPU。K5 是 AMD 首款完全自主設計的處理器，於 1996 年 3 月推出，目的是與 Intel 的 Pentium CPU 展開競爭，但實際效能仍有落差。K5 不支援 Time Stamp Counter TSC 指令，這是核心決定移除對其支援的主要原因，因為支援 TSC 指令如今被視為現代 Linux 的啟動需求。核心將逐步移除各種不支援 TSC 指令的 CPU，而支援 TSC 的 Pentium CPU 則仍會持續受到支援。
在 Linux 7.1 逐步停止支援已有 37 年歷史的 Intel i486 CPU 之後，Linux 7.2 將停止支援已有 30 年歷史的 AMD K5 CPU。K5 是 AMD 首款完全自主設計的處理器，於 1996 年 3 月推出，目的是與 Intel 的 Pentium CPU 展開競爭，但實際效能仍有落差。K5 不支援 Time Stamp Counter TSC 指令，這是核心決定移除對其支援的主要原因，因為支援 TSC 指令如今被視為現代 Linux 的啟動需求。核心將逐步移除各種不支援 TSC 指令的 CPU，而支援 TSC 的 Pentium CPU 則仍會持續受到支援。