Jump to...
redirecting...

Log for Ubuntu 台灣社群

並不會
你刷失敗八九成是你的韌體有問題或者是他根本沒辦法正常啟動
然後他就會回退上一個可以啟動的韌體
我之前已經刷過N遍了
其中一台路由器可能已經被刷了,至少30次以上
Linux 7.3 釋出

Linus Torvalds 在核心郵件列表上宣布釋出 Linux 7.3。新版本包含來自 3,021 名開發者的 18,765 個非合併提交(non-merge commits),其中 807 人首次參與核心開發。主要更新包括:擴充 binfmtmisc 格式註冊功能;旨在提升大型系統效能的群組排程最佳化;讓所有操作一律傳回失敗結果的 failfs 檔案系統;fchroot() 系統呼叫;完善 schedext 子排程器功能;虛擬機器工作集追蹤;ntfs3 檔案系統支援替代資料串流等。更多內容可參閱 KernelNewbies 7.3。

• https://lore.kernel.org/lkml/CAHk-=wgwnBm2zDdRM7u016NVHkv9KqbZW7AZ=8wZrqGyv_V+5A@mail.gmail.com/T/#u
• https://kernelnewbies.org/Linux_7.3
Linux 7.3 核心正式釋出 (★ 203 分)

Linux 7.3 核心正式釋出,創下規模紀錄:共納入 18,765 筆非合併變更,來自 3,021 名開發者,其中 807 人是首度參與核心開發。Linus Torvalds 表示,釋出時程順利,7.4 的合併窗口將於隔日開啟;不過他正值家庭假期,初期合併工作會因潛水行程而較不規律。

新版涵蓋檔案系統、排程、虛擬化與安全隔離等多項改進。`binfmt_misc` 加強後可更彈性辨識與啟動非原生執行檔格式;群組排程調整則鎖定大型機器的效能表現。核心也新增 `failfs`,這種檔案系統會讓所有檔案操作失敗;另有 `fchroot()` 系統呼叫、BPF(Berkeley Packet Filter,可在核心內執行的可程式化封包與追蹤機制)每 CPU 全域資料、`sched_ext` 可擴充排程器框架的完整功能,以及虛擬機器工作集追蹤。NTFS3 新增替代資料串流支援,SMB(Server Message Block,網路檔案共享協定)伺服功能也獲得一長串改良。

討論最集中於 `failfs` 的實際用途。其設計可讓程式在切換根目錄後無法再依路徑開啟新檔案,只能使用事先開啟或繼承的檔案描述元,因此可作為沙箱隔離的一環:若搭配靜態連結程式、預先配置的通訊端與預設拒絕的防火牆規則,遭入侵的程式較難讀取本機檔案、啟動命令列工具或橫向入侵其他部分。不過,動態連結程式通常仍須依絕對路徑載入函式庫,會與 `failfs` 的限制衝突;也有人批評 Linux 既有隔離機制由多個系統呼叫拼湊而成,容易因細節或例外情境被繞過,期望能有更一致的能力導向安全模型。另有意見認為,若能製作會隨機讓讀寫失敗、但不毀損資料的類似工具,將有助於測試資料庫等軟體的錯誤復原能力。

社群亦關注 SMB 改良對 macOS 備份的意義。核心內建的 `ksmbd` SMB 伺服功能新增可選用的 Apple Time Machine 相容性,涵蓋 AAPL 協商、Finder 延伸資料、稀疏檔、變更通知等需求,讓 macOS 的 `backupd` 備份程式可使用 `ksmbd` 備份。一些使用者期待這能改善 Linux 或 NAS(網路附加儲存裝置)作為 Time Machine 目的地的體驗,但也提醒 Apple 的 SMB 相容性長期容易出現問題,且此類支援多半需依逆向工程成果實作。另一方面,Apple Silicon 的 ARM 支援持續擴展,M3 Pro、Max 與 Ultra 也納入裝置樹支援。

針對大量新貢獻者與人工智慧輔助開發,意見呈現分歧。有人猜測新增的變更可能有不少由大型語言模型(LLM, Large Language Model)協助產生,也擔心這會提高錯誤率;反方則強調,程式碼品質取決於審查、測試與提交者是否能為結果負責,而非初稿由人或工具撰寫。討論提及核心維護流程的一項務實原則:安全問題回報若能附上可驗證的修正,遠比冗長敘述更容易審查;無法說明修正必要性與運作方式的變更,仍應遭拒絕。

👥 81 則討論、評論 💬
https://news.ycombinator.com/item?id=50149392
Let's Encrypt 新增兩個網域驗證用的遠端觀測點 (★ 103 分)

Let's Encrypt 將新增兩個用於網域驗證的遠端觀測點,以提高憑證核發時抵禦網路劫持的能力。依憑證機構與瀏覽器論壇(CA/B Forum)的《基準要求》,自 2026 年 12 月 15 日起,憑證機構必須使用至少五個遠端網路來源進行多點核發佐證,且來源須分布於至少兩個區域網際網路註冊管理機構(RIR, Regional Internet Registry)的服務範圍。

調整後,Let's Encrypt 每次驗證網域時,將從主要資料中心及六個遠端觀測點共發出七次驗證請求;先前則是主要資料中心加上四個遠端來源。要成功核發憑證,主要來源與足夠數量的遠端來源都必須取得正確的挑戰回應。此機制可提高邊界閘道協定(BGP, Border Gateway Protocol)路由劫持的難度,因為攻擊者得同時誤導多個獨立網路位置。新地區預定於 2026 年 10 月 27 日先在測試環境啟用,11 月 10 日再推至正式環境。

Hacker News 討論中,有人解釋多點驗證的實際意義:憑證機構會從不同資料中心檢查網域控制權,例如 DNS-01 驗證是在網域名稱系統(DNS)紀錄中放置指定驗證值,HTTP-01 驗證則要求網站伺服器回傳指定內容。若只有單一驗證來源,攻擊者只要竄改該來源到目標網域之間的 DNS 回應或網路路由,就可能偽造驗證回應並取得未授權的 TLS 憑證;多個來源可使這類局部攔截更難成功。

不過,也有意見指出,多點驗證無法完全處理整個目的地遭路由劫持的情況。討論援引一起涉及 Hetzner 網段的案例:攻擊者曾長時間宣告不屬於自己的路由,使部分流量被導向假冒目的地,並藉此取得 virtualizor.com 的有效憑證;即使該路由已被標為無效的 RPKI(Resource Public Key Infrastructure,路由授權驗證機制)紀錄,仍有大量網路接受了它。因此,有人主張憑證機構應強制檢查 RPKI,或以 DNSSEC(DNS Security Extensions,DNS 安全延伸規格)等加密式網域所有權證明補強。然而反方認為 RPKI 採用率仍不足,若立即強制,可能造成部分網域無法核發憑證,且集中式路由授權機制也可能帶來政治性封鎖風險。

👥 29 則討論、評論 💬
https://news.ycombinator.com/item?id=50150809
這要打,通常是打目的地 BGP 路由,把目的憑證出口都導向攻擊者路由