cURL 開發者丹尼爾上週在部落格中發布了一篇文章抨擊蘋果“篡改” cURL 導致的“安全問題”，這個問題最初是2023 年12 月有用戶提交的，跟踪ID 為12604。丹尼爾針對該問題進行調查後發現這並不是cURL 的問題，而是蘋果在部署中進行了一些修改，為此丹尼爾發郵件給蘋果，蘋果安全團隊還表示有意這麼幹的，不需要「修復」。

大概情況是這樣的：

cURL 允許開發者使用參數–cacert 來指定一組CA 證書，如果TLS 伺服器無法對這組證書進行驗證時，那麼應該失敗並傳回錯誤。

這種特殊行為早在2000 年12 月就已經添加到了cURL 中，這讓開發者可以只對特定的CA 證書進行信任，而不是信任所有有效的CA 證書，例如防止某些CA 因為審核不嚴導致簽發錯誤證書進行劫持。

在macOS 中，開發者仍然可以使用這個參數，但蘋果的處理方法是檢查系統的CA 儲存庫，也就是直接驗證蘋果在macOS 中指定的那組CA 證書，而不是開發者指定的一組CA 證書。

因此當開發者使用一組進行編輯的特定CA 憑證時，正常情況下不包含在這組CA 憑證中的憑證應該會失敗，但如果這個/ 這些憑證位於macOS 儲存庫中，那麼cURL 不會回傳失敗。

所以這其實是一個安全缺陷。

針對此問題丹尼爾在2023 年12 月29 日向蘋果安全團隊報告，這不是一個大問題，但確實是個問題。

直到2024 年3 月8 日蘋果才回覆郵件：

Apple 版本的OpenSSL (LibreSSL) 有意使用內建系統信任儲存作為預設信任來源，由於可以使用內建系統儲存成功驗證伺服器證書，因此我們認為不需要在我們的平台中解決。

對於這個說法丹尼爾並不同意，因為實際上這篡改了cURL，這個未記錄的功能使得macOS 用戶使用cURL 時，CA 驗證完全不可靠並且與cURL 的文檔不符，這是蘋果在欺騙用戶。

問題是這並不是cURL 的問題，因此丹尼爾無法發布CVE 或任何內容，於是現在問題陷入了僵局。