Python 社區被蘋果坑！只因一個字符串審核被拒，核心開發者們想了 8 天辦法

整理 | 褚杏娟、核子可樂

“這不是傳統意義上的錯誤。我最近經歷了一次‘磨難’，在我將 Python 從 3.11 更新到 3.12 後，蘋果拒絕了我 App Store（具體來說是 Mac App Store）上的應用程序更新。” Eric Froemling 在 GitHub 的 issue 中說道。

當然，蘋果方面並沒有直接向 Froemling 闡述拒絕 Python 應用的理由。在向蘋果提起申訴並要求停止審查時，蘋果最終告知他，parse.py 和 parse.pyc 屬於有問題的文件。

在 Froemling 多方檢查後才發現，是因爲 Python 3.12 中添加了一個“itms-services”字符串，並且蘋果似乎正在掃描此字符串並自動拒絕包含它的任何內容。在從 Python 捆綁副本中刪除該字符串後，他才終於通過了審覈。

實際上，受 Python 3.11 至 3.12 版本升級的影響，蘋果應用商店已經將部分 Python 應用下架。

“現在回想起來我感到很沮喪，沒能想到早一點對 Python 本身的 itms-services 進行全文檢查，也沒能偶然發現其他人遇到過這個問題。”雖然 Froemling 隨後表示，但他的遭遇還是引起了社區的強烈反應。

CPython 核心開發者 Russell Keith-Magee 於 6 月 17 日在 Python Core Deveopment 論壇上發起了一項討論：我們到底願意爲適應 App Store 的審覈流程付出多少？

對該字符串進行一些輕微混淆似乎可以避免這個問題。然而，這並不能保證衝突得到永久解決，而且可能會引發混淆軍備競賽；另外，後續我們可能還會遇到更多類似的應用程序驗證問題。

雖然目前的問題來自 macOS 應用程序，但 iOS、Android 和微軟等應用平臺也存在類似的 App Store 自動審覈流程。蘋果的審覈絕對是其中最……偏執且陰晴不定的一種——但這並不代表其他平臺做得更好，目前各平臺的驗證和接收流程均完全不透明。

Russell Keith-Magee 提出了 CPython 解決這類問題的幾種思路：

第一種思路是將“被應用商店所接納”設定爲 CPython 的設計目標，並納入可滿足該要求的相關補丁。

也就是說，用戶不需要進行任何額外修復即可保證 CPython“與應用商店相兼容”，但這必然會將某些比較醜陋的混淆代碼合併進軟件產品。而如果後續規則再次發生變化，可能還需要添加更多補丁；另外哪些舊規則被移除，核心開發團隊也不敢斷言原本的特定混淆可以同步去掉。

如果選擇這種方式，則意味着各 Python 發行版將不再是“官方”Python，因爲其經過了修改以適應分發要求。

“我不知道到底應不應該將此視爲安全或者品牌形象意義上的風險。但參考之前已經爲不同 Linux 發行版專門推出了 Python 補丁，所以這可能也不是什麼大問題。”Russell Keith-Magee 說道。

另外一種思路是將這個問題劃交給分發環節處理。

CPython 的項目現狀就是，生成捆綁應用程序的工具（包括 Briefcase、Py2app、Biuildozer 等）負責修復 CPython，確保其能夠被應用商店所接受。以 Briefcase 和 Buildozer 爲例，這些工具還會修復並構建自定義 CPython 庫。

從歷史角度講，這是因爲 CPython 本身就無法對 iOS 和 Android 提供開箱即用支持；3.13 源代碼現在無需修復即可工作……但如果將其視爲一個分發問題，則修復在本質上將成爲一項持續性要求。

這個思路還有另一個問題，即 CPython 是否應該將已知的一切應用商店限制納入開發考量。

開發人員很快達成共識，並提出了一項有望在 Python 3.13 中儘快實現的解決方案。

Russell Keith-Magee 拋出問題後，社區衆多開發者紛紛參與討論並提出了自己的建議。

另一位 CPython 核心開發者 Alex Gaynor 建議，該項目可以嘗試一種 Keith-Magee 沒有提到的方法，這主要是受到 Gaynor 在處理加密庫方面的經驗啓發。

該加密庫經常收到投訴，稱其拒絕解析技術上並未生效、但卻被廣泛使用的證書。他表示目前的做法是接納解決這類問題的 PR 請求，不過“前提是其必須體量小巧、本地化，而且質量要有一定保證”。

他隨後又補充稱，這些補丁只在有人向第三方（也就是本次糾紛中的蘋果）申訴，並得到承諾會採取措施的情況下才會被接受。他建議爲解決方案設定時間限制，以便在爲用戶提供良好體驗的“同時，也不致讓大企業習慣於將種種奇怪的問題外化到自由開源項目身上。”

同爲 CPython 核心開發者的 Brandt Bucher 則首先好奇所謂混淆方案能不能行得通，或者說是否會被蘋果視爲規避審覈過程。這個問題似乎沒人能夠回答，Keith-Magee 用“暫時無解”加表情符號予以回覆。

在 Bucher 看來，Gaynor 的方法似乎很有吸引力，但也有點文不對題。畢竟蘋果幾乎沒有申訴程序，而 Python 項目也沒有可用的渠道來“提出在原則上有助於修改政策的意見”。

曾參與編寫 Python 最佳實踐文檔的 Alyssa Coghlan 則提出了另一建議，就是使用 JSON 配置文件——urllib 會讀取該文件來設置模塊級屬性，“而非對所有與 schema 相關的知識進行硬編碼。”也就是說，這樣能讓應用程序生成器直接從配置文件中刪除“itms-services”，而不必直接修改 urllib.py。

Keith-Magee 也認可這種方案的可行性，但提醒稱“我還是覺得可以用混淆或者分發階段的修復來處理，沒必要搞得太矯枉過正。”

6 月 20 日，Keith-Magee 在論壇上寫道，他想到了另外一種方法：添加一個名爲“-with-app-store-patch 的構建時選項，藉此刪除已知存在問題的代碼。他表示在默認情況下，iOS 平臺會啓用該選項，而其他平臺則會禁用該選項。如果開發人員打算通過 macOS App Store 分發應用程序，則可以在爲 macOS 構建應用時使用這種方法。

他還建議，此選項可以接受帶有補丁的文件路徑，這樣當 Python 新版本發佈、問題消失且應用商店在維護窗口後做出相應調整時，分發者也能繼續提供補丁更新。”

Coghlan 則詢問大家要不要儘快“把這類隱患管起來”。她認爲，目前議案中的選項名稱既過於寬泛、又過於狹窄。名稱中的“app-store”部分太寬泛，會涵蓋一切應用商店，而不只是是蘋果應用商店；“補丁”部分又太狹窄，因爲補丁既可以指代遵守蘋果政策，又可以代表想個辦法逃避審覈。也就是說，應用商店的合規性檢查問題仍然沒得到解決。

Keith-Magee 支持從選項名稱中刪除“補丁”的建議，轉而將其更名爲“-with-app-store-compliance”形式，以便與平臺標識交互以確定內容範圍。

最終在 6 月 25 日，Keith-Magee 給出了用於實現 -with-app-store-compliance 配置選項的 PR 請求。在請求中，他表示可以將該選項用於 iOS 或 macOS 以外的平臺，但目前尚無實際用例。如果一切順利，此請求有望在 Python 3.13 中生效。

縱觀整個事件，像 Python 這樣的免費軟件項目不得不浪費時間以尋求繞過不透明審覈流程的狀況着實令人沮喪，否則開發人員就無法爲非免費平臺繼續編寫軟件。而 Keith-Magee 和其他 CPython 開發者採取的方法，似乎已經是當下最不壞的選擇，在保證應用上架的同時也儘可能維護了 Python 應用程序開發者的良好體驗。

但可以肯定的是，這絕對不會是該項目最後一次遇到這種“天降橫禍”。

參考鏈接：

https://discuss.python.org/t/handling-incompatibilities-with-app-store-review-processes/56011/3

https://lwn.net/SubscriberLink/979671/4fb7c1827536d1ae/