從PG“斷供”看軟件供應鏈中的信任問題

本月發生了一起沸沸揚揚的 “開源斷供”事件—— [1]， 但其實還有另一件略隱蔽的 “卡脖子案例”，老馮在上個月提到過 —— 《[2]》。

這次 “PostgreSQL 斷供” 某種程度上扮演了試金石的角色，倒是很好的試出了各家數據庫廠商和云廠商的成色 —— 全部躺平擺爛，老馮對此感到非常失望。停止將國內的云廠商和大學鏡像站作為供應鏈上游，自建了 PGDG YUM/APT 倉庫的國內最新同步鏡像。

PGDG的“斷供”

PostgreSQL 是數據庫領域的祖師爺級開源項目，也是世界上最流行，最受喜愛，需求量最大的數據庫。 絕大多數的用戶都是通過 PGDG APT / YUM 倉庫，來在 Linux 上安裝 PostgreSQL 數據庫的。

不幸的是，PGDG （全稱：PostgreSQL 全球開發組）的 APT / YUM 軟件制成品倉庫在今年五月中旬對外關閉了 ftp 與 rsync 同步通道， 這導致了幾乎全球的鏡像站點都與上游倉庫失去同步，存放的都是幾個月前的舊版本軟件包。

老馮在 7月7號的 《[3]》一文中詳細介紹過這個問題。 那時候老馮觀察到德國的 XTOM 其實嘗試手工按月手工更新的策略，其他基本上所有鏡像站全軍覆沒，都停留在三四五月的狀態。昨天我重新統計了一下，發現俄羅斯的 YANDEX 也手工跟進了 APT 倉庫，其他的鏡像站依然是老樣子。

鏡像站的“斷更”

比如，17.5 等5月更新版本修復了 CVE-2025-4207[4] GB18030 相關漏洞，而今天剛剛發布的 17.6 系列版本[5] 更是修復了 3 個 CVE 和 55 個 BUG。如果你是鏡像站的用戶，那么就沒法及時更新跟進打補丁了。更別提下個月即將發布的 PostgreSQL 18 新大版本了。現在還屬于問題早期階段，也就落后兩個 PG 小版本，但很快再過一個月就會落后一個大版本。然后各種積累的漏洞補丁，安全修復國內用戶全都用不上，產生的暴露風險會越來越大

從這個角度上來說，上游軟件供應鏈停止對下游提供更新，本質上確實符合 “斷供” 的定義。不過 PGDG “斷供” 的理由也還算充分 —— 他們上 CDN 了嘛。

PGDG為何“斷供”

PostgreSQL 郵件列表里，5月20日有韓國鏡像站的維護者問過這個問題，之前用 rsync 同步 PGDG 官方倉庫怎么突然斷了？

Davaid Page 給出的解釋是，ftp/rsync 從來就不是官方承諾提供的服務方式。PGDG YUM/APT 倉庫也就兩臺物理機，每天卻有 10TB 的訪問流量，很多都是“非法流量”，帶寬要受不了啦！所以他們就把這個倉庫給托管到了 Fastly CDN 上。

他們的想法也很顯然 —— 我都用了 CDN 了，那專業 CDN 的節點和體驗，不比零星的鏡像站好多了？官方可以有能力繞過鏡像站直接對全世界用戶提供服務，那還要啥鏡像站？于是就把 FTP rsync 給關掉了，只能通過 HTTP 訪問。看上去確實也沒毛病，雖然斷了鏡像站同步，但也提供替代解決方案了 —— 直接用官方 CDN 就好了，也算是合情合理。

—— 你可以選擇不用任何鏡像站，直接使用 PGDG 官方倉庫（他們剛搬到 Fastly CDN上）。

中國被卡脖子了？

鏡像同步中斷，對于世界上絕大多數地區的用戶來說，其實影響還相對較小，因為他們總是可以去用 PGDG 新的 CDN 。但唯獨對中國來說，這就等效于制成品斷供了 —— 因為眾所周知的原因，中國訪問不了這些 CDN 節點！如果這些鏡像站不更新，中國用戶就沒的用了！

當然，你要是自己翻墻用什么的還是可以用的。但是你顯然不能指望人人都會這個，而且即使翻了速度也還是很慢的。所以國內的鏡像站對于國內用戶使用 PostgreSQL 來說依然是至關重要。（也別說 Docker ，DockerHub 也被墻了，而且絕大多數 Docker Postgres 鏡像也是從 APT 倉庫里安裝的…）

從這個角度來說， 中國用戶這還真是被卡了一把脖子 —— 雖然本質上屬于搬起石頭砸自己的腳 —— 人家只是把增量的同步給關掉了，然后你用不了人家提供的替代解決方案而已。但這個事情已經是這個樣子，重要的是在這種背景下如何解決用戶的問題。誰來解決這個問題呢？

中國用戶想要 YUM/APT 安裝 PostgreSQL 一般只能通過國內的鏡像站來安裝，最知名的應該是阿里云和清華大學的Tuna鏡像站，當然還有浙大/中科大的源。不幸的是，這些鏡像站無一例外全都躺平了，并沒有體現出擔當來 —— 但你也沒法怪他們，畢竟免費嘛。

供應鏈風險

開源專家 Tison在他的公眾號文章《》和 《》深入解釋過，開源軟件（源代碼）本身是沒有所謂 “斷供” 風險的 —— 開源協議授予的一系列基本權利是不可撤銷的，在這個維度下“開源斷供”從未發生過。對斷供的擔憂往往是對開源軟件過度期待帶來的誤解。

但是用戶對開源的依賴總是發生在具體的軟件供應鏈上，保障開源依賴的供應鏈安全是有成本的 —— 開源制成品，也就是二進制軟件包（RPM/DEB/鏡像），以及開源制成品的交付渠道 —— 軟件倉庫（APT/YUM/Registry）是存在斷供風險的。

原因也很簡單，這都是有成本的，誰來支付這個成本是一個大問題。開源開發者愿意支付大頭的研發成本，很多時候是因為這個事對他們來說是一種有趣的娛樂。然而分發，打包，構建倉庫，提供持續穩定的企業級服務與供給很大程度上是一種純負擔。比如國內一個GB流量賣你8毛錢，那你 PGDG 一天10個TB流量，一天就是幾千塊錢，對吧。所以你看能搞開源鏡像站的基本上要么就是高校要么就是大型互聯網廠商，第一自己也要用，第二加雙筷子沒啥流量成本。

反過來說，這些使用開源軟件的用戶像 PGDG 和開源軟件鏡像站付費了嗎？嘿，沒有，所以老實說，無論是從法律上，道義上，還真沒法苛責什么，因為這就是開源的 STYLE —— 沒有質保 —— 畢竟人家也沒收錢，提供源代碼是本分，但開源協議可沒有規定說要提供開源軟件二進制制成品，開發者和開源軟件鏡像站沒有義務去做這種慈善。

如何解決供應鏈風險？

那么商業服務可以解決這個問題嗎？畢竟，這么多國產數據庫都是基于 PG 換皮，套殼，魔改弄出來的子孫后代，結果上游老祖宗被 Ban 了，確實有些滑稽，就沒有人出來搞個中國的鏡像站嗎？嘿，可能還真沒有 —— 大部份情況下，這些數據庫廠商都是直接白嫖鏡像站（阿里云，清華）倉庫的，或者說，交付方式甚至都不是軟件倉庫，而是丟給你一個 EL7 RPM 包，根本沒有能力維護軟件倉庫。

老馮自己獨立維護了一個 PostgreSQL 擴展倉庫，里面包含了 9 種風味的 PG 內核，以及兩百多款 PG 擴展（加上 PGDG 的總共 423 個可用擴展）。目前是 全世界 PG 生態收錄最多可用擴展制品的倉庫了。不謙虛的說，說起 PostgreSQL 打包構建，我和 Devrim（YUM 倉庫），Christoph（APT 倉庫），álvaro（OCI 倉庫），David Wheeler（PGXN） 是這個賽道的頂級玩家與原始供應者。

但雖然我會打包構建，維護倉庫，但是，在安裝交付 PG 原生內核的時候，我還是會選擇使用 “PG官方” 的 PGDG APT / YUM 倉庫，PIGSTY 自己的倉庫作為擴展補充倉庫， 因為 Devrim 和 Christoph 已經干的足夠好了！我會去做和他們工作有差異互補的事情。

所以對于老馮的 PostgreSQL 發行版 Pigsty 來說，PGDG 倉庫是 PIGSTY 的供應鏈上游，國內區域因為有墻，阿里云鏡像站是老馮的間接上游。現在的問題是這個間接上游，包括阿里云，清華，浙大，各種云在內的所有鏡像站，全都趴窩斷更沒得用了，怎么辦呢？

老馮在發現這個問題的時候，第一時間就給阿里云和清華TUNA的郵件列表上報了這個問題，也跟德哥聊過說過。不幸的是，幾十天過去了，依然毫無波瀾，沒有絲毫動靜。就是沒人有這個擔當，能站出來解決這個問題。老馮對國內這些云廠商和數據庫廠商和高校鏡像站的維護團隊真的非常失望。但你也沒法說人家 —— 對吧，人家畢竟是免費給你用的，你能說什么呢？

我行我上

所以老馮也懶得再啰嗦，直接自己動手就上了。其實動手了我才知道，這才多大點屁事和工作量？ —— 人家不給你開放 ftp rsync 同步，那你就用 apt-mirror 和 reposync 直接從 HTTP 通道去同步不就行了？老馮昨天用 Claude Code 花了兩個小時，寫了個同步流程，把 PGDG 的 YUM / APT 倉庫給拉了下來，丟到 Pigsty 的倉庫里，然后測試了一遍，非常順滑。我干完之后的感想就是 —— 就這？這么屁大點兒活，就給國內卡成這樣？草臺班子理論誠不欺我。

當然PG倉庫總量大幾百個 GB，如果全部弄下來就太大了，我就只要了 Linux x86 / aarch64 架構的包，同步了 Debian 11/12/13 ，Ubuntu 22/24 ，EL 7/8/9/10 這幾個主要 Linux 操作系統發行版大版本下的 PG 13 - 17 的包，然后只保留最新的版本，這樣總大小就只有幾十個GB 了。拉了兩個小時，同步回來，丟到國內 CDN 上，然后目前在 pig 0.6.1 和 pigsty 3.6.1 中，我已經把阿里云和清華源換掉了，昨天剛發布，徹底擺脫躺平擺爛的中間商依賴，實現真正的自主可控。

例子：使用 pig 添加倉庫，或者直接添加 APT 倉庫（YUM 同理）

目前這個倉庫和 Pigsty 本身一樣，都是開源免費的。直接使用 Pigsty 肯定是自建 PostgreSQL 服務的更佳選擇，但你確實也完全可以直接使用這里的 APT / YUM 鏡像倉庫。直接對公眾用戶開放會有不少流量成本，不過老馮應該還是兜得住的 —— 雖然開源的本質就是無質保，但好在老馮向客戶們承諾長期持續維護這個鏡像倉庫，所以免費用戶也可以搭搭便車。如果有人想要贊助（服務器，CDN，打錢），老馮也非常歡迎。

這讓老馮回想起一些往事，兩年前老馮想要把 PG 擴展搞進來，但是想要偷懶借力，我看到有個叫 Tembo 還有 pgxman 的公司嘗試在做 PG 擴展包管理器，我就等啊等啊等了幾個月，等到最后發現他們純粹是光吹牛不干活，老馮就不等直接自己上了，做了 pig 包管理器，pg 擴展目錄和擴展倉庫，現在成為了 PG 生態最大的擴展倉庫。就好比像 Omnigres 和 Autobase 這樣的開源 PG 發行版/項目，也都使用 老馮維護的 Pigsty 擴展倉庫，向他們的客戶去交付。老馮的軟件倉庫也開始成為別人的供應鏈的上游了，開始參與國際軟件供應鏈并積累信任。

“開源” 確實并不要求你向用戶提供可靠穩定的二進制制成品，但真正重要的不是開源，而是信任，開源只是構建信任一種形式，持續的投入，交付的承諾，專注的熱情，承擔責任的勇氣。想要成為值得信賴，受人尊敬的社區參與者，有許多東西比丟一份源代碼到倉庫要重要的多。

References

[1] KubeSphere 刪除鏡像跑路: /cloud/kubesphere-rugpull
[2] 卡脖子：PGDG切斷鏡像站同步通道: /pg/pg-mirror-break
[3] 卡脖子：PGDG切斷鏡像站同步通道: /pg/pg-mirror-break
[4] CVE-2025-4207: https://www.postgresql.org/support/security/CVE-2025-4207/
[5] 17.6 系列版本: https://www.postgresql.org/about/news/postgresql-176-1610-1514-1419-1322-and-18-beta-3-released-3118/