uv 是 Astral 以 Rust 撰寫的 Python 套件與專案管理工具，GitHub 星標 90,953，於 2026 年 10 月 20 日發布 0.13.4，緊急從內建憑證包中撤除 emSign ECC Root CA - G3。這次發布沒有新功能、沒有效能調校，只有一行安全修補，卻牽動整個開源生態的 TLS 信任鏈，屬於必須當日處理的等級。
uv 0.13.4 於 2026 年 10 月 20 日發布，移除內建憑證包的 emSign ECC Root CA - G3，因其簽出的中繼憑證私鑰已外洩，應立即升級。
專案由 Astral 維護，主儲存庫於 2023 年 10 月 2 日建立，採 Apache-2.0 授權，主要語言為 Rust，累積 3,677 個 Fork 與 467 位貢獻者。該工具在 PyPI 的單月下載量達 1.27 億次（pypistats 統計），已從早期的實驗性加速器，演變為許多 CI 流程與容器映像的預設安裝器。正因為它被大量放進自動化管線，任何憑證層的調整都會沿著建置流程擴散出去。
uv 0.13.4 是什麼？
uv 0.13.4 是 2026 年 10 月 20 日推出的安全修補版，對應 GHSA-hq85-5cpj-mr62，更新內建根憑證並移除 emSign。
版本說明開宗明義指出，這次更新處理的是 GHSA-hq85-5cpj-mr62，涉及一張在公開金鑰基礎建設（Web PKI）體系中，中繼憑證已遭入侵的根憑證。官方同時提醒，這是跨生態的事件，任何透過 certifi 或 webpki-root-certs 之類套件內嵌憑證包的軟體都必須升級，uv 並不是唯一受影響的專案。
實際的程式改動極小：透過 webpki-root-certs 1.0.10 更新內建的 Mozilla 根憑證清單。這個版本由 rustls 維護團隊在 10 月 19 日發布，變更紀錄只有一行「Removed emSign ECC Root CA - G3」。改動小，但意義在於信任邊界的重畫。
emSign 根憑證為什麼被撤除？
因 emSign ECC Root CA - G3 簽出的八張中繼憑證私鑰已洩漏並被撤銷，持有者可簽發任何網域的合法外觀憑證。
根據 uv 安全公告的描述，emSign ECC Root CA - G3 所簽發的中繼憑證，其私鑰被判定為已遭入侵，憑證機構 eMudhra 亦已撤銷這批中繼憑證。持有被洩漏私鑰的攻擊者，可以為任何網域簽發在技術上完全合法外觀的憑證；若攻擊者同時處於網路路徑之中，便能解密或竄改原本受 TLS 保護的流量。
這種攻擊的關鍵在於它不需要破解加密演算法，只需借用一條被信任的簽發鏈。對終端使用者而言，瀏覽器網址列的鎖頭圖示仍會正常顯示，錯誤不會外顯；對開發者而言，套件下載、API 呼叫與容器映像拉取都可能經過被攔截的連線。這也是為什麼公告用語相當直接：所有使用內嵌憑證包的軟體都必須升級，並且要逐一檢查其他相依套件。
這次憑證事件影響哪些工具與套件？
影響所有內嵌 CA 憑證包的軟體，包括 uv、certifi、requests、urllib3 與 pip，涵蓋容器映像與 CI 建置流程。
Python 生態的對應修補由 certifi 承擔。certifi 在 2026.10.18 先把所有 emSign 根憑證一次移除，隨後於 2026.10.19 把未受影響的 emSign 根憑證加回，並在安全公告 GHSA-6q48-6c7w-9gw2 中標示嚴重等級為 critical，影響範圍為 2019.03.09 至 2026.10.19 之前的版本。由於 requests、urllib3、pip 及 Python.org 的 macOS 安裝程式都依賴 certifi，這條路徑的覆蓋面比單一 CLI 工具更廣。
Rust 陣營則由 webpki-roots 1.0.10 對應，rustls 生態下的程式若使用該憑證包，同樣需要更新。這意味著一次事件橫跨 Python 與 Rust 兩套信任鏈，而兩邊的修補節奏僅相差一天，反映維護者之間有即時通報機制。
使用系統憑證是否能避開這次風險？
可以規避內建憑證包的風險，但前提是作業系統信任庫已不再信任該根憑證；使用自訂憑證檔者須自行確認未殘留相關條目。
uv 預設使用內建憑證，但提供兩條替代路徑：以 --system-certs 改用作業系統的憑證庫，或透過 SSL_CERT_FILE、SSL_CERT_DIR 指定自訂憑證。選擇系統憑證的重點，在於作業系統是否已經把該根憑證與其中繼憑證標記為不信任；多數主流發行版會在事件公開後數日內推送更新，因此這個選項並非一勞永逸的解法，而是把更新責任轉移到系統層。
使用自訂憑證檔的團隊則需要自行檢查檔案內容，確認其中不含 emSign ECC Root CA - G3 及其衍生的中繼憑證。企業內部若為了 TLS 檢測而部署中間人代理，往往會把自家根憑證與廠商憑證一併打包，這類檔案最容易在多年之後仍殘留已被撤銷的條目。
uv 0.13 系列還有哪些破壞性變更？
0.13.0 把預設 Python 版本改為 3.15，並收緊雜湊驗證、Windows ARM64 解譯器偏好與限制檔路徑解析。
0.13.0 於 10 月 9 日發布，安全修補之外，這個版本本身改動不小。預設穩定 Python 版本由 3.14 提升至 3.15，影響未指定版本的 uv python install 與 uv venv 等指令；若環境中已存在相容的 3.14，uv 仍會沿用，不會強制重新下載。
其餘變更集中在正確性與相容性。-c 引入的限制檔若帶有 --require-hashes，過去會被忽略，現在會被嚴格執行，缺少雜湊的套件將直接安裝失敗；Windows ARM64 平台改為優先使用原生 aarch64 解譯器，取代先前的模擬 x86_64；限制檔中的可編輯需求（-e）由靜默忽略改為直接報錯，與 pip 行為一致；Python 3.10 以上不再寫入 distutils 啟動修補，可降低直譯器啟動開銷。tar 解壓後端改為 tar-codec，驗證更嚴格，必要時可用 UV_LEGACY_TAR_BACKEND=1 回退。uv build --clear 也不再允許輸出目錄包含建置來源，避免誤刪。
官方明確表示，多數使用者可在不改動專案的情況下升級，但快取格式有變，升級後首次安裝可能重新下載或重建部分相依套件。使用 uv_build 的專案若在 [build-system] 中設定上界，需放寬至 uv_build>=0.13.0,<0.14。
後續三個修補版本各自解決什麼問題？
0.13.1 縮減體積與解析開銷，0.13.2 修正相依標記的指數級運算，0.13.3 修復含 extras 時匯出變慢。
0.13.1 於 10 月 14 日推出，主要工作是效能與邊界條件：uv pip check 與嚴格安裝模式改為忽略 Requires-Python 上界，與解析行為一致；解析錯誤訊息會回報缺少的受信任雜湊；二進位檔體積縮減，Simple API 解析與套件中介資料解析的開銷同步下降。此版同時加入 CPython 3.16.0a1 的下載支援。
0.13.2 於 10 月 19 日推出，處理了兩個實務痛點。其一是在解析、遍歷與匯出複雜相依標記時，避免指數級的工作量，這類問題過去會讓大型專案的 uv export 幾乎停擺；其二是對套件與索引資料的 GET、HEAD 請求加入重試，降低網路抖動造成的建置失敗。0.13.3 在隔日發布，專門修復含 extras 的相依圖在 uv export 時的嚴重變慢。三個版本連續推出，節奏反映出 0.13 的改動確實觸及核心路徑。
uv 與 pip 的效能差距有多大？
官方基準顯示 uv 安裝速度比 pip 快 10 至 100 倍，並以單一工具取代 pip、pipx、poetry、pyenv 等七套工具。
README 的定位陳述相當直接：一個工具取代 pip、pip-tools、pipx、poetry、pyenv、twine、virtualenv 等多套既有工具，速度比 pip 快 10 至 100 倍，並提供相容 pip 的介面，讓既有腳本可以漸進遷移。速度來源並非單點優化，而是全域快取、硬連結與平行下載的組合，加上以 Rust 重寫的解析器。
值得注意的是，專案的價值主張已從「更快」轉向「一致性」。通用鎖定檔（universal lockfile）讓同一份 uv.lock 在 macOS、Linux 與 Windows 上解析出相同結果，工作區（workspace）機制則對多套件倉庫提供類似 Cargo 的管理模型。這也是為什麼 0.13 系列多數破壞性變更都圍繞解析正確性，而非再壓縮幾毫秒。
如何升級並確認自己的環境安全？
以官方安裝腳本或 PyPI 升級至 0.13.4，確認版本後再檢查映像與 CI 快取的 certifi 是否達 2026.10.19。
升級路徑有兩條。使用獨立安裝器者，重跑 curl -LsSf https://astral.sh/uv/install.sh | sh 即可取得最新版；使用 PyPI 者執行 pip install --upgrade uv。完成後以 uv --version 確認輸出為 0.13.4，並在 CI 設定中把版本號固定下來，避免下一次建置又回退到舊版。
憑證層的檢查不應只停在 uv 本身。容器映像若在 Dockerfile 中安裝過 certifi，需要確認映像內的版本已達 2026.10.19；requests 與 urllib3 的相依解析結果亦應一併檢視。企業若使用自訂憑證包，建議直接搜尋檔案中是否仍存在 emSign 相關條目，而不是只依賴版本號判斷。已完成建置的映像不會自動獲得修補，必須重新建置才會換掉內嵌的憑證清單。
uv 的授權與取得方式是什麼？
採 Apache-2.0 授權，可自 GitHub Releases、安裝腳本或 PyPI 取得，支援三大平台，不需預裝 Rust 或 Python。
Apache-2.0 允許商業使用、修改與再散布，只需保留授權聲明與變更說明，對想把 uv 納入企業內部工具鏈的團隊相對友善。取得方式包含官方 shell 與 PowerShell 安裝腳本、PyPI 套件，以及 GitHub Releases 的預先編譯二進位檔；安裝過程不需要預先具備 Rust 或 Python 環境，這也是它能在精簡容器映像中快速普及的原因之一。
出處連結有哪些？
主要出處為 GitHub 的 astral-sh/uv，安全細節見 GHSA-hq85-5cpj-mr62，憑證修補可對照 certifi 的同類公告。
程式碼與版本紀錄集中於 https://github.com/astral-sh/uv，0.13.4 的發布說明載明安全公告編號與憑證更新來源。憑證層的背景可延伸閱讀 rustls 的 webpki-roots 1.0.10 發布紀錄，以及 Python certifi 專案的 GHSA-6q48-6c7w-9gw2 公告，兩者對同一根憑證的處理方式可相互對照。
總結：誰應該立即升級 uv？
所有使用 uv 內建憑證的開發者與 CI 管線都應立即升級至 0.13.4；改用系統憑證者風險較低但仍建議更新。
這次事件的教訓不在 uv 本身，而在憑證包的散播方式。當一個工具把根憑證清單編譯進二進位檔，修補就必須依靠使用者主動升級；而容器映像與 CI 快取的存在，會讓舊版憑證在系統中存活遠比預期更久。對維護者而言，這次發布是一次成本極低但影響明確的正確動作；對使用者而言，真正需要建立的是「憑證清單屬於需要定期盤點的相依項目」這個認知。
至於 0.13 系列的其餘改動，對多數專案的實際影響有限，較值得留意的是雜湊驗證轉嚴與限制檔路徑解析的變化。若團隊的安裝流程依賴寬鬆的限制檔語法，升級前應先在分支上跑一次完整建置，確認沒有因缺少雜湊或路徑含空格而中斷，再合併到主線。
