PyPI’nin Trusted Publishing özelliği paket güven sinyali olarak görülmemeli
(blog.yossarian.net)- Trusted Publishing içindeki “güven”, insanların pakete güvenebileceği anlamına değil, CI/CD gibi harici makine kimliği ile paket indeksi arasındaki yükleme kimlik doğrulama ilişkisine işaret eder
- PyPI’nin uygulaması OIDC federasyonu üzerinde çalışır ve uzun ömürlü API tokenları yerine kısa ömürlü, dar kapsamlı yayınlama kimlik bilgileri vererek uzun süreli ve aşırı yetkili kimlik bilgileri sızıntısı riskini azaltır
- PyPI bunu 2023’te duyurduktan sonra npm, RubyGems, crates.io, NuGet gibi ekosistemlere de yayıldı; ancak veri modeli karmaşıklığı, OIDC sağlayıcılarına özgü işleme ihtiyaçları ve CI/CD ele geçirilmesi olasılığı devam ediyor
- PyPI, Trusted Publishing durumunu proje sayfasında yeşil onay işareti ile öne çıkarmıyor; bunu yalnızca dosya ayrıntılarında basit bir Yes/No meta verisi olarak göstererek bunun bir güvenlik sinyali sanılma riskini azaltıyor
- Trusted Publishing ve PyPI attestations yalnızca yükleme kimlik doğrulaması ya da makine kimliğine dayalı imza olup olmadığını söyler; o kimliğe ayrıca güvenilmediği sürece paketin güvenliği veya kalitesi hakkında hüküm verdirmez
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’e insanların güvenip güvenemeyeceği açısından bakmak, konuyu yanlış bir kategoriye yerleştirir
- Esas nokta, CI/CD workflow’ları gibi harici makine kimlikleri ile paket indeksindeki proje kimliği arasında yükleme kimlik doğrulaması için bir güven ilişkisi kurmaktır
PyPI’de Trusted Publishing yapısı
- “Trusted Publishing”, PyPI'nin OpenID Connect federasyonu üzerindeki kimlik doğrulama yöntemini tanımlarken kullandığı terimdir
- PyPI bunu 2023’te duyurdu; ardından npm, RubyGems, crates.io, NuGet gibi hizmetler de benimsedi
- Çıkış noktası iki sorundur
- Uzun ömürlü kimlik bilgileri olan indeks API tokenlarını güvenli biçimde yönetmek zordur ve kullanıcıların en az yetki ile son kullanma süresi belirlemesi zor olduğundan bunlar kolayca aşırı yetkili hale gelir
- Pek çok kullanıcı, bunları CI/CD platformlarına koymak için kimlik bilgisi oluşturur; CI/CD platformları da OIDC üzerinden belirli makine kimliklerinin kontrolünü kanıtlayan mekanizmalara sahiptir
- Kullanıcı, paket indeksine CI/CD makine kimliği olan bir Trusted Publisher kaydeder; ardından CI/CD bir kimlik tokenı sunduğunda indeks bunu doğrular ve kısa ömürlü, dar kapsamlı yayınlama kimlik bilgileri verir
Avantajlar ve kalan kısıtlar
- Kısa ömürlü ve kendi kapsamı belirli kimlik bilgileri yaklaşımı, PyPI kullanıcıları için büyük ölçüde başarılı kabul ediliyor
- Kullanıcılar, gerekmediğinde kimlik bilgilerini doğrudan kendilerinin yönetmek zorunda kalmadığı yöntemleri tercih ediyor
- Büyük açık kaynak projeleri ve şirketler, yayınlama yetkisinin bireysel maintainer’lara değil kaynak kimliğine bağlı olmasını tercih ediyor
- Trusted Publishing’de yapısal karmaşıklık yine de sürüyor
- PyPI’nin “pending publishers” özelliği henüz var olmayan proje sorununu çözüyor, ancak veri modelini karmaşıklaştırıyor ve kullanıcılar için genel Trusted Publishing’den daha kafa karıştırıcı olabiliyor
- OIDC sağlayıcıları, ortak claim’lerin yanı sıra claim set içine farklı değerler koyabildiğinden indeksin her sağlayıcının kendine özgü biçimini ayrı ayrı işlemesi gerekiyor
- Bu nedenle makine kimlikleri OIDC IdP’leri arasında birbirinin yerine geçebilir değil; PyPI’nin yeni Trusted Publishing sağlayıcılarını yavaş eklemesinin nedenlerinden biri de bu
- Bir 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 bulunduğundaki duruma benzer; ancak Trusted Publishing kimlik bilgileri aynı kapsam ve ömür risklerini taşımaz
- PyPI,
pull_request_targetgibi kolayca kötüye kullanılabilecek tetikleyicilere karşılık gelen makine kimliklerinde token değişimini reddederek CI/CD ele geçirilmesi riskini azaltır
Neden paket güven sinyali değil
- Trusted Publishing yalnızca bir kimlik doğrulama yöntemidir; paketin güvenli, yüksek kaliteli veya kullanılmaya değer olup olmadığı hakkında bilgi vermez
- PyPI açık bir indeks olduğu için herkes yükleme yapabilir ve herkes Trusted Publisher kullanarak da yükleme yapabilir
- Trusted Publisher üzerinden de zararlı yazılım veya güvenlik açığı içeren kod yüklenebilir
- Bu açıdan PyPI’nin diğer yükleme kimlik doğrulama yöntemi olan API tokenlarından farkı yoktur
- PyPI’de Trusted Publishing zorunlu değildir ve gelecekte de zorunlu hale getirilemez
- Kullanıcılara Trusted Publishing’i dayatmak mühendislik açısından uygulanabilir değildir; teknik ve toplumsal açıdan da arzu edilir değildir
- Trusted Publishing her zaman isteğe bağlıdır
PyPI arayüzünün yanlış anlamayı azaltma biçimi
- PyPI, kullanıcıların Trusted Publishing durumunu bir paket güven sinyali sanmaması için dikkatli davranır
- Proje sayfasında Trusted Publishing durumunu gösteren bir yeşil onay işareti yoktur
- Kullanıcı kontrolündeki durumlara ait yeşil onay işaretleri yalnızca PyPI’nin paketin kendisiyle aynı kaynaktan geldiğini doğrulayabildiği bağlantılar için kullanılır
- Doğrulanmış URL’ler, yalnızca doğrulama anında ilgili URL’nin PyPI paket sahibinin kontrolünde olduğunu gösterir; URL veya proje için ek bir güvenlik anlamı taşımaz
- 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ının güven kararı için önemli bir bilgiymiş gibi render edilmez
- Yükleme istemcisinin user agent’ından gelen JSON blob da özel biçimde render edilmez
Attestations ile farkı
- Bu tartışma, PyPI’nin attestations özelliğinden ayrıdır
- Attestations da şu anda OIDC makine kimliği kullanıyor, ancak bunlar da bir güven sinyali değildir
- Attestation, makine kimliği üzerinde atılmış bir imzaya benzer; fakat PyPI’ye herkes yükleme yapabildiği için herkes kendi kontrol ettiği makine kimliğiyle imza da atabilir
- Trusted Publisher olması, mutlaka bir attestation bulunduğu anlamına gelmez; bir attestation bulunması da son kullanıcının belirli bir kimliğe güvenmesi gerektiği anlamına gelmez
- PyPI’nin attestation güvenilirlik modeli de bu noktayı belgeliyor
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