Trusted Publishing paket güven sinyali olarak görülmemeli
(blog.yossarian.net)- Trusted Publishing’deki “güven”, pakete insanların güvenebileceği anlamına gelmez; CI/CD gibi harici makine kimlikleri ile paket dizini arasındaki yükleme kimlik doğrulama ilişkisini ifade eder
- PyPI’nin uygulaması OIDC federasyonu üzerinde çalışır; uzun ömürlü API token’ları yerine kısa süreli ve dar kapsamlı yayınlama kimlik bilgileri vererek uzun ömürlü ve aşırı yetkili kimlik bilgilerinin açığa çıkmasını azaltır
- PyPI bunu 2023’te duyurduktan sonra npm, RubyGems, crates.io, NuGet gibi ekosistemlere yayıldı; ancak veri modeli karmaşıklığı, OIDC sağlayıcılarına özel işleme ve CI/CD’nin ele geçirilmesi olasılığı hâlâ sürüyor
- PyPI, Trusted Publishing durumunu proje sayfasında yeşil onay işaretiyle vurgulamaz; yalnızca dosya ayrıntılarında basit bir Yes/No meta verisi olarak göstererek bunun güvenlik sinyali sanılma ihtimalini azaltır
- Trusted Publishing ve PyPI attestations yalnızca yükleme kimlik doğrulamasını ya da makine kimliği tabanlı imza olup olmadığını belirtir; bu kimliğe ayrıca güvenilmeden paket güvenliği veya kalitesi hakkında hüküm verilemez
Trusted Publishing’in ele aldığı güvenin kapsamı
- Trusted Publishing, insanlara bir pakete güvenmelerini söyleyen bir özellik değil, makineler arası güveni ele alan bir kimlik doğrulama yöntemidir
- Trusted Publishing’i insanların güvenip güvenemeyeceği meselesi olarak görmek kategori hatasıdır
- Esas nokta, CI/CD workflow’u gibi harici bir makine kimliği ile paket dizinindeki proje kimliği arasında yükleme kimlik doğrulaması için bir güven ilişkisi kurmaktır
PyPI’nin Trusted Publishing yapısı
- “Trusted Publishing”, PyPI’nin OpenID Connect federasyonu üzerindeki kimlik doğrulama yöntemini açıklamak için kullandığı terimdir
- PyPI bunu 2023’te duyurdu; ardından npm, RubyGems, crates.io, NuGet gibi ekosistemler de benimsedi
- Çıkış noktası iki sorundur
- Uzun ömürlü kimlik bilgileri olan dizin API token’larını güvenli biçimde yönetmek zordur; kullanıcıların minimum yetki ve sona erme süresi belirlemesi zor olduğundan bunlar kolayca aşırı yetkili şekilde ayarlanır
- Birçok kullanıcı kimlik bilgilerini CI/CD platformlarına koymak için oluşturur; CI/CD platformları da OIDC aracılığıyla belirli bir makine kimliği üzerindeki kontrolü kanıtlayan mekanizmalara sahiptir
- Kullanıcı, paket dizinine CI/CD makine kimliği olan Trusted Publisher’ı bir kez kaydeder; CI/CD bir kimlik token’ı sunduğunda dizin bunu doğrular ve kısa süreli, dar kapsamlı yayınlama kimlik bilgileri verir
Avantajlar ve süren kısıtlar
- Kısa süreli ve kendi kapsamı belirlenmiş kimlik bilgileri yaklaşımı, PyPI kullanıcıları için büyük başarı elde etmiş bir yöntem olarak değerlendirilir
- Kullanıcılar, gerekmediğinde kimlik bilgilerini doğrudan yönetmemeyi tercih eder
- Büyük açık kaynak projeleri ve şirketler, yayınlama yetkisinin bireysel maintainer’a değil kaynak kimliğine bağlanması özelliğini tercih eder
- Trusted Publishing’de de yapısal karmaşıklıklar devam eder
- PyPI’nin “pending publishers” özelliği, var olmayan proje sorununu çözer; ancak veri modelini karmaşıklaştırır ve kullanıcılar için genel Trusted Publishing’den daha kafa karıştırıcıdır
- OIDC sağlayıcıları, ortak claim’lerin bir kısmı dışında claim set’ine çeşitli değerler koyabilir; bu nedenle dizinlerin her sağlayıcının kendine özgü biçimini ayrı ayrı işlemesi gerekir
- Bu yüzden makine kimlikleri OIDC IdP’leri arasında birbirinin yerine geçebilir değildir; PyPI’nin yeni Trusted Publishing sağlayıcılarını yavaş eklemesinin nedenlerinden biri de budur
- CI/CD workflow’u ele geçirilirse saldırgan, Trusted Publishing kimlik bilgilerini veya bunların tohumu olan OIDC ID token’ını sızdırabilir
- Bu, workflow içinde uzun ömürlü kimlik bilgileri bulunmasına benzer; ancak Trusted Publishing kimlik bilgileri aynı kapsam ve ömür riskini taşımaz
- PyPI,
pull_request_targetgibi kolayca kötüye kullanılabilecek tetikleyicilere karşılık gelen makine kimlikleri için token takasını reddederek CI/CD ele geçirilmesi riskini azaltır
Neden paket güven sinyali değildir?
- Trusted Publishing yalnızca bir kimlik doğrulama yöntemidir; paketin güvenli, kaliteli veya kullanılmaya değer olup olmadığına dair bilgi vermez
- PyPI herkese açık bir dizindir; herkes yükleme yapabilir ve herkes Trusted Publisher kullanarak yükleme yapabilir
- Trusted Publisher ile de kötü amaçlı kod veya zafiyetli kod yüklenebilir
- Bu açıdan PyPI’nin diğer yükleme kimlik doğrulama yöntemi olan API token’larıyla aynıdır
- PyPI’de Trusted Publishing zorunlu değildir ve gelecekte de zorunlu hâle gelemez
- Kullanıcıları Trusted Publishing’e zorlamak mühendislik açısından uygulanabilir değildir; teknik ve sosyal açıdan da arzu edilir değildir
- Trusted Publishing her zaman isteğe bağlıdır
PyPI arayüzü yanlış anlamayı nasıl azaltıyor?
- PyPI, kullanıcıların Trusted Publishing durumunu paket güven sinyali sanmaması için dikkatli davranır
- Proje sayfasında Trusted Publishing durumunu gösteren yeşil onay işareti yoktur
- Kullanıcı kontrolündeki durumlara yönelik yeşil onay işaretleri yalnızca PyPI’nin, paketin kendisiyle aynı kaynaktan geldiğini kanıtlayabildiği bağlantılar için kullanılır
- Doğrulanmış URL, doğrulama anında ilgili URL’nin PyPI paket sahibinin kontrolü altında olduğunu kanıtlar; URL veya proje için ek bir güvenlik anlamına gelmez
- Belirli bir dosyanın Trusted Publishing durumu, dosya ayrıntılarında basit bir Yes/No değeri olarak gösterilir
- Dosya meta verisi alanı, kullanıcıların güven kararında önemli bir bilgiymiş gibi render edilmez
- Yükleme istemcisinin user agent’ından gelen JSON blob’u da düzgün biçimde render etmez
attestations ile ayrımı
- Bu tartışma PyPI’nin attestations özelliğinden ayrıdır
- attestations şu anda OIDC makine kimliğini kullansa da güven sinyali değildir
- attestation, makine kimliği üzerinde imzaya benzer; ancak PyPI’ye herkes yükleme yapabildiği için herkes kendi kontrol ettiği makine kimliğiyle imzalayabilir
- Trusted Publisher olması attestation’ın mutlaka var olduğu anlamına gelmez; attestation olması da son kullanıcıların belirli bir kimliğe güvenebileceği anlamına gelmez
- PyPI’nin attestation güvenilirlik modeli de bu noktayı belgelendirir
1 yorum
Lobste.rs yorumları
İyi bir yazı. Trusted Publishing ile kanıtlama (attestation) farklı arıza modları için farklı güvenceler sağlar ve ikisi de çoğu kullanıcının kastettiği güven kavramından ayrıdır
Trusted Publishing’in mümkün hâle gelmesi, son 15 yılda birçok açık kaynak projesinin posta listeleri, Git depoları, hata takip sistemleri, derleme sunucuları gibi kendi barındırdığı yapılardan merkezî forge’lara taşınması sayesinde oldu
Şimdi merkezî forge’ların dezavantajları daha belirgin hâle geldikçe projeler yeniden kendi kendine barındırmayı değerlendirmeye başlıyor
2010’larda kolaylık ve sosyal ağ etkileri projeleri merkezî forge’lara iterken, artık Trusted Publishing de dahil olmak üzere projeleri orada tutan çok daha fazla etken var
Otoriteye güvenme — merkeziyetsizliği teşvik et
— "The Hacker Ethics", Hackers: Heroes of the Computer Revolution (Steven Levy, 1984)
Federatif kimlik doğrulama yöntemini bir tür kilitlenme olarak adlandırmakta biraz ironi var
Yaklaşık aynı dönem, 25 yıl kadar önce ASF de vardı; ancak ASF’nin ayrıca ciddi bir yönetişim yükü vardı. Ondan önce GNU projesi vardı; özgür yazılım ideolojisini daha çok vurguluyor ve sistematik proje barındırma hizmetlerine daha az odaklanıyordu. Çünkü GNU, özgür yazılım projelerinin hangi hizmetlere ihtiyaç duyduğuna dair net bir kavram oluşmadan önce vardı
1990’lardaki özgür yazılım projeleri genellikle bir üniversitenin zaman paylaşımlı hizmetinde ya da bir arkadaşın colocation sunucusunda barındırılırdı. Örneğin PuTTY veya ASF öncesi Apache httpd’nin bulunduğu Hyperreal.org gibi
Kendi altyapısını haklı çıkaracak kadar büyüyen projeler nadirdi; ucuz hosting de nispeten yakın zamanda mümkün hâle geldi