Jump to...
redirecting...

Log for Ubuntu 台灣社群

Ubuntu 預設的 Firefox 已經是 Snap 了吧
certbot: ._.
它是classic
OpenSSL 4.0.0 正式發布 (★ 108 分)

OpenSSL 4.0.0 是一次以功能擴充為主、但也帶來多項不相容調整的大版次更新。這版移除了 SSLv2 Client Hello 與 SSLv3 等早已過時的安全通訊協定支援,也正式拿掉 Engines(舊式外掛加密引擎架構)、c_rehash 工具,以及多個已棄用的加密與錯誤處理函式;原本仰賴舊式腳本的流程,現在改用 openssl rehash。憑證處理方面,4.0.0 強化了嚴格模式下的驗證流程,包括更完整的識別與撤銷清單檢查;同時也調整十六進位輸出格式、全域清理機制,並把部分內部資料型別改成不直接揭露結構。部分過時與明確指定的 EC (Elliptic Curve,橢圓曲線) 曲線也改成編譯時預設停用,代表舊程式若仰賴歷史行為,升級時得一併檢查建置設定與相容性。

新功能裡最受矚目的是新增 Encrypted Client Hello (ECH,將 TLS (Transport Layer Security,傳輸層安全協定) 初始交握中原本可被窺視的網站名稱等資訊加密) 支援,這被視為近年網路隱私的一大進展。這版也加入 SM2 / SM3(中國商用密碼演算法)相關簽章與金鑰交換群組、後量子混合群組 curveSM2MLKEM768、cSHAKE(可自訂的雜湊延伸函式)、ML-DSA-MU(與後量子簽章相關的摘要演算法),以及 SNMP (Simple Network Management Protocol,簡易網路管理協定) 與 SRTP (Secure Real-time Transport Protocol,即時安全傳輸協定) 的 KDF (Key Derivation Function,金鑰衍生函式)。此外,FIPS (Federal Information Processing Standards,美國聯邦資訊處理標準) 模組現在可用 defer_tests 選項延後自我測試,Windows 也新增靜態或動態 Visual C++ 執行階段連結選項,並補上 TLS 1.2 的協商式 FFDHE (Finite Field Diffie-Hellman Ephemeral,有限域暫時性迪菲-赫爾曼) 金鑰交換。

討論裡最熱的焦點同樣是 ECH 是否已能實際啟用。留言指出,Cloudflare 自 2023 年起就已支援,Firefox 自 119 版起預設啟用,Chrome 也已可用,Nginx 1.29.x 主線版同樣跟進;不過 Safari 仍未在正式環境預設開放,iOS / macOS 目前偏向實驗性選項,許多 Linux 發行版則要等較新的套件版本才能直接用上。也有人提醒,ECH 對大型共用雲端託管平台的隱私價值最大,因為單一網站即使隱藏了交握中的網域名稱,外界仍可能從 IP 位址推測服務對象。另一派則指出,企業或管制型網路可能會先封鎖 ECH,因為它削弱 SNI (Server Name Indication,伺服器名稱指示) 過濾能力;反方認為,若大型網站未來改成只提供 ECH,這類封鎖只是延後 SNI 過濾退場的權宜之計。

對升級風險與專案走向的評價則較分歧。部分使用者認為,和 OpenSSL 3 初期相比,從 3 升到 4 的過程其實平順得多,真正麻煩的主要是移除 Engines,像 Fedora 之類的發行版已陸續把相關套件改好。不過更廣泛的觀感仍延續對 OpenSSL 3 的不滿:自 Heartbleed(2014 年重大記憶體外洩漏洞)之後,專案在安全維護、審查與組織化上明顯進步,但 3.x 引入的提供者架構與 OSSL_PARAM 這類以鍵值對陣列傳遞參數的設計,被批評拖慢效能、增加複雜度,也讓程式碼更難讀,甚至連 pyca/cryptography 這類專案都被提到正在評估替代方案。另有留言補充,直到 OpenSSL 3.4.1 之後,外部 QUIC(建構在無連線傳輸上的新式協定,常見於 HTTP/3 網頁傳輸)實作才終於能較乾淨地搭配 OpenSSL 使用,顯示專案近年雖有回應生態系需求,但在易用性與效能上的爭議仍未平息。

👥 25 則討論、評論 💬
https://news.ycombinator.com/item?id=47768788
看來Line在Linux的問題可以用自用簽章繞過
https://forum.gamer.com.tw/Co.php?bsn=60030&sn=2550747
wayland.fyi minimalist wayland special interest group
https://wayland.fyi/
簡單講就是有簽就好
Android 保持開放 (★ 119 分)

這個名為 Keep Android Open 的倡議頁面指出,Google 已在 2025 年 8 月宣布,從 2026 年 9 月起,未先向 Google 集中登記的開發者,其應用程式將無法在一般 Android 裝置上順利安裝。登記內容包含繳費、同意條款、提供政府核發身分證明、上傳可證明私密簽章金鑰的資料,以及列出目前與未來所有應用程式識別碼。頁面認為,這會把 Android 從原本標榜的開放平台,轉成由 Google 決定哪些軟體能被信任的封閉體系,影響的不只是獨立開發者與小型團隊,也包括一般使用者對自有裝置的控制權,以及各國政府與企業的數位主權。

此外,該站特別質疑 Google 在 2026 年 3 月公布的進階流程。依照官方說法,進階使用者若要繼續安裝未驗證應用程式,必須先連按七次版本號碼開啟開發者模式,再到設定中開啟允許未驗證套件、輸入解鎖密碼、重新開機、等待 24 小時,之後還得通過多個警告畫面,才能暫時或長期放行。倡議者認為,這不只是把正常安裝行為變得繁瑣,且整套機制是由 Play Services(Google Play 服務)下發,不屬於 AOSP(Android Open Source Project,Android 開放原始碼專案)或 Android 作業系統本身,因此 Google 可在不經系統更新與使用者同意的情況下隨時收緊或移除。由於這套機制至今仍未在 beta 測試版或開發預覽版中真正出貨,網站主張外界目前看到的仍只是部落格文章與介面示意圖,而非可被獨立驗證的保障;因此他們呼籲開發者拒絕提早加入驗證方案,也鼓勵使用者改用 F-Droid(開源 Android 應用程式商店)、回覆 Google 問卷、簽署請願書,並向各地競爭監理機關反映,包括台灣公平交易委員會。

在 Hacker News 的高分留言裡,許多人認同這波變更會讓 Android 更像 iPhone 的封閉模式,尤其有人擔心若 Pixel 市占再提高,Google 更有條件收回原本僅存的開放性。不少人把焦點放在語言包裝:從單純的安裝,慢慢被改稱為 sideloading(旁載安裝,指不經官方商店自行安裝應用程式)、未知來源安裝,到如今的未驗證套件,這種命名一路把使用者的正常權利描繪成可疑行為,也讓七次點按、24 小時冷卻與多重警告畫面看起來像是合理的安全代價。另一些留言則提醒,旁載這個術語並非完全由 Google 發明,過去 Android 改機與 homebrew(自製軟體)圈子也長期使用類似說法,因此不能把所有語言轉變都歸咎於 Google 的宣傳策略。

討論區也補上幾個重要補充。多位使用者稱讚 F-Droid 的體驗更尊重使用者,許多遊戲與工具沒有廣告和微交易,因此若 Google 繼續收緊政策,替代應用程式市集可能成為重要緩衝;也有人主張,真正長遠的解法或許是投資非 Google 控制的手機作業系統。不過也有人指出,文章把情況描述得過於絕對,因為限制主要透過 GMS(Google Mobile Services,Google 行動服務)執行,不含 GMS 的 Android 分支理論上仍可運作,只是現實上,多數消費裝置與企業、政府必裝應用程式都深度仰賴 Google 生態,使替代作業系統難以真正進入主流。還有開發者分享自己與 Google 審查流程互動的挫折經驗,有人甚至主張這種購後才被追加的限制可能引發集體訴訟(class action);他們認為若連私密簽章金鑰都要交出證明,再加上模糊且不透明的審查規則,獨立開發者的風險與成本都會顯著升高,這也是整串討論最強烈的共同憂慮。

👥 18 則討論、評論 💬
https://news.ycombinator.com/item?id=47778274
😨
就,其他國家太多誘騙安裝詐騙 app 事件了
下一步:引入Valorant的kernel-level反作弊反竄改系統