· kaynak dev.to (home feed)
Apple'ın macOS ile gelen git'i hâlâ anahtar zincirindeki ele geçirilmiş eMudhra sertifikalarına güveniyor
Bir dev.to yazısı, Apple'ın bundled git'inin TLS doğrulamasını macOS anahtar zincirine göre yaptığını gösteriyor; dolayısıyla ele geçirilmiş eMudhra sertifikaları, bulunup silinmedikleri sürece yerel ve CI build'lerinde hâlâ geçerli sayılabiliyor.

Apple'ın git'i güven bilgisini anahtar zincirinden okuyor
macOS, kendi git kopyasını /usr/bin/git yolunda birlikte teslim ediyor ve tipik bir OpenSSL tabanlı build'in aksine OpenSSL'ın varsayılan trust store'una geri düşmüyor. dev.to'da yayımlanan bir yazıya göre Apple'ın git'i TLS sertifikalarını macOS anahtar zincirlerine göre doğruluyor. Bu ayrıntı sorunun kaynağı: başka bir yerde iptal edilmiş bir sertifika, bir kopyası sistem veya login anahtar zincirinde kaldığı sürece bir Mac üzerinde hâlâ doğrulanabiliyor. Söz konusu sertifikalar eMudhra'ya bağlı ele geçirilmiş sertifikalar ve yazar, otomatik build'lerin bu yüzden sessizce iptal edilmiş kimlikleri kabul ediyor olabileceği uyarısında bulunuyor.
Sertifikaları bulmak
Yazıdaki tespit yaklaşımı kısa bir pipeline: security find-certificate ile sistem anahtar zincirindeki tüm sertifikaları dök, çıktıyı her girdinin subject ve issuer bilgisini yazdırmak için openssl x509 üzerinden geçir ve sonucu "emudhra" için grep'le. /Library/Keychains/System.keychain hedeflendiğinde boş bir sonuç store'un temiz olduğu anlamına gelir; herhangi bir çıktı satırı, git'in hâlâ güveneceği ele geçirilmiş bir sertifikanın makinede bulunduğu anlamına gelir.
Bunları silmek
Kaldırma aynı deseni izliyor. Yazıdaki script sistem anahtar zincerinden SHA-256 parmak izlerini topluyor, eMudhra girdilerini filtreliyor, iki nokta üst üste biçimlendirmesini temizliyor ve her parmak izi için security delete-certificate -Z komutunu çağırıyor; izinler gerektirdiğinde sudo ile çalıştırıyor. Temizliğin işe yaradığını doğrulamak için tespit taramasını yeniden çalıştırın ve hiçbir şey döndürmediğini teyit edin. Yazar ayrıca git'i doğrudan da test etmeyi öneriyor: github.com gibi bir remote'a karşı git ls-remote gibi bir komut çalıştırıp hiçbir sertifika hatası çıkmadığını doğrulamak.
Temizliğin yetmediği yerler
Yazı, yalnızca sistem anahtar zincirini hedefleyen bir düzeltmenin gözden kaçırdığı üç başarısızlık modu listeliyor. Birincisi, kaldırma script'i login anahtar zincirine hiç dokunmuyor; dolayısıyla ~/Library/Keychains/login.keychain-db içine aktarılmış aynı sertifika ayakta kalıyor ve kontrolün orada da tekrarlanması gerekiyor. İkincisi, Homebrew üzerinden kurulan git kendi OpenSSL yapılandırmasını getirebilir ve sistem anahtar zincirini tamamen yok sayabilir; git config --get http.sslBackend komutu gerçekte hangi backend'in kullanıldığını gösterir. Üçüncüsü, bazı araçlar TLS oturumlarını önbelleğe alır; bu yüzden terminal yeniden başlatılana veya makine reboot edilene kadar eski bağlantılar varlığını sürdürebilir.
CI runner'ları dürüst tutmak
CI runner'ların kullandığı hazır macOS imajları hâlâ eski sertifikaları içerebilir; bu da bugün temizlenen bir makinenin yarın kötü güven durumu geri yüklenmiş şekilde yeniden provision edilebileceği anlamına gelir. Yazının cevabı bir pipeline guard'ı: macos-latest üzerinde bir GitHub Actions job'ı olarak gösterilen, sistem anahtar zincirindeki eMudhra eşleşmelerini sayan ve sayı sıfırdan büyükse sıfır olmayan bir status ile çıkan bir doğrulama adımı. Build, sertifikalar fark edilmeden geri sızmışken sessizce devam etmek yerine gürültülü biçimde başarısız oluyor.
Neden önemli
İptal (revocation), istemciler iptal edilen şeye gerçekten güvenmeyi bıraktığında anlamlıdır. Burada güven kararı Apple'ın git'inin doğrudan danıştığı makine başına bir store'da yaşıyor; bu yüzden belirli bir Mac'i düzeltmenin tek yolu sertifikayı silmek ve ephemeral CI imajları her temizlikten sonra sorunu sessizce yeniden getirebiliyor. Etki alanı build altyapısı: iptal edilmiş bir kimlik hâlâ doğrulanıyorsa, git'in bir remote'un gerçekliğini onaylamak için güvendiği TLS kontrolü görevini yapmayı bırakır ve build'ler reddetmeleri gereken bir host'tan kod ve dependency çekebilir. Yazının kontrol listesi — her iki anahtar zincirini taramak, git'inizin hangi TLS backend'ini kullandığını bilmek ve CI'yi temiz bir trust store üzerinde kilitlemek — sessiz bir güvenlik başarısızlığını görünür bir hâle getiriyor.
- #macos
- #git
- #security
- #ci-cd
- #tls