PyPI 舊 release 過 14 日唔再收檔，Python 發布流程要點改
版本推出兩星期後不可再加 wheel，新平台支援要另開版本
14 日後，舊版本唔可以再加檔案
iThome 報道提到，PyPI 已經開始拒收加入舊 release 嘅新檔案。實際規則好直接：一個版本由首個檔案上傳、正式建立嗰刻起計，過咗 14 日就唔可以再加 wheel、source distribution 或其他發布檔案。舊檔案仍然可以下載，套件亦冇俾人下架；限制針對嘅係事後補檔。以往有團隊先出 source distribution，隔幾星期先補齊 Windows、macOS、ARM 或新版 CPython wheel，而家呢種做法行唔通。
點解補一個 wheel 都可以變成安全缺口
PyPI 官方解釋，假如攻擊者偷到項目嘅發布 token，或者控制咗自動發布流程，佢未必要改動現有檔案。攻擊者本來可以揀一個長期穩定、仍有大量項目鎖住使用嘅舊版本，再加入針對特定 Python、ABI 或平台嘅惡意 wheel。當 pip 見到嗰個 wheel 同安裝環境相容，就有機會揀咗新加入嘅檔案。PyPI 強調暫時冇發現呢種手法俾人實際利用，今次屬預防性改動，唔應寫成已經發生過嘅攻擊。
新版 Python 支援要跟住版本號一齊行
Wheel 係預先砌好嘅安裝檔；含有原生擴充嘅套件，通常要為唔同 Python、作業系統同 CPU 組合各自準備 wheel。Python Packaging User Guide 指出，pip 搵唔到相容 wheel 時，可能會改用 source distribution 喺用家部機即場 build，但部機未必有齊編譯器同系統 library，安裝隨時會失敗。往後如果 1.4.1 推出幾個月後先要支援新版 CPython，維護者要發布 1.4.2 之類嘅新版本，冇得再將新 wheel 掛返落 1.4.1。
CI/CD 最好一次過跑齊發布矩陣
用自動化發布嘅團隊要重新檢查流程：同一個版本嘅 source distribution、Linux、Windows、macOS 同 ARM wheel，最好喺同一輪 release job build 完、測完再上傳。個別 runner 出問題，可以喺 14 日限期內補檔；一旦過期，就要加版本號重發。PyPI 暫時亦冇正式 API 畀工具預先查一個 release 係咪已經停止收檔。至於日後工具可唔可以預先查到 release 狀態，就要睇 Upload 2.0 API 同 staged publishing 最後點實作。所以 pipeline 遇到舊版上傳失敗時，應該停低開新版本，唔好無限重試。
寫死版本號，以前都未完全鎖死檔案集合
呢項改動亦提醒大家一個容易忽略嘅問題：requirements.txt 寫住 foo==1.2.3，只係鎖住版本，未必鎖住嗰個 release 入面所有檔案。以前維護者仍可加入另一個平台 wheel，令相同版本喺另一部機攞到後來先出現嘅檔案。14 日限制收窄咗呢段風險窗口，但 hash lock、Trusted Publisher、短命憑證同保護發布 workflow 仍然要做。PyPI 研究過 15,000 個熱門項目，當中只有 56 個曾喺版本推出超過 14 日後補上 CPython 3.14 wheel；以實際影響換取較清楚嘅安全邊界，呢個取捨合理。延遲補 wheel 嘅少數維護者，就要由下一個 release 開始改流程。
參考來源
- iThome — 【資安日報】7月28日，FIRST發布新版DNS濫用技術矩陣 — original report
- PyPI Blog：Releases now reject new files after 14 days — PyPI 官方公告，確認規則、推出原因、影響數據同暫未見實際濫用。
- PyPI Docs：Upload API — 確認 release 由首個上傳檔案建立，以及現行上傳 API 點運作。
- Python Packaging User Guide：The Packaging Flow — 解釋 wheel、平台組合同搵唔到 wheel 時改用 source distribution 嘅行為。
- PyPI Blog：LiteLLM／Telnyx supply-chain attacks — 官方事故背景同發布 token、Trusted Publisher 等防護建議。
- PEP 694：Upload 2.0 API for Python Package Indexes — 新上傳 API、release 狀態同 staged publishing 嘅標準化背景。
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
