npm, PyPI ve crates.io terk edilmiş bağımlılıklar için güvenilir bir sinyal sunmuyor

Karara dönüşemeyen bir "eskime" sütunu

npm, PyPI ve crates.io metaverisini her bağımlılık için tek bir satırda birleştiren bir aracı sürdüren bir geliştirici, yakın zamanda basit bir soruya yanıt vermeye çalıştı: bu package terk edilmiş mi? dev.to'da yazdığı yazıda bu girişimin başarısız olduğunu, ama bunun verinin eksik olmasından kaynaklanmadığını belirtiyor. Her registry terk edilmeyle ilgili bir ipucu taşıyor ve her ipucu kendi içinde güvenilmez.

Araç zaten bir package'in en son ne zaman güncellendiğini gösteriyordu. Bunu ölü-canlı bayrağına dönüştürmek bambaşka bir sorun olduğu ortaya çıktı, çünkü üç registry terk edilmenin neye benzeyeceği konusunda bile hemfikir değil.

npm: yalnızca elle ayarlandığında işleyen bir deprecation bayrağı

dev.to gönderisine göre npm'de deprecated adında, belirli bir sürüme bağlı ve maintainer'ın açıkça ayarlaması gereken bir string alan var. Ayarlandığında npm install anında bir uyarı gösteriyor. Yazar, alanın amaçlandığı gibi çalıştığı örnekler olarak kullanıcıları nyc'ye yönlendiren istanbul ile jade (pug olarak yeniden adlandırıldı) ve gulp-util'a işaret ediyor; hepsinin son yayını 2015 ve 2016'da yapılmıştı.

Başarısızlık modu sessizlik. Bower'ın son yayını Mart 2022'deydi ve kendi README'si projeyi bakımsız ilan etmişti, ancak deprecated alanı hiç ayarlanmadı. Yayın yetkisi olan biri harekete geçmeyi hatırlamadığı sürece gerçekten ölü bir package sağlıklı olandan ayırt edilemiyor.

Gönderi daha ince bir vakayı da vurguluyor: colors, 2022'deki bir supply-chain olayının merkezindeki package. Sabote edilmiş 1.4.1 ve 1.4.2 sürümleri registry'de duruyor ve tam pin ile hâlâ yüklenebiliyor, ancak en son dist-tag 2019'daki 1.4.0'a geri alındı. Varsayılan yükleme olay öncesi sürümü alıyor; yani hikayeyi anlatan herhangi bir status alanı değil, registry'nin tag geçmişi.

PyPI: bir kez yazılıp bir daha gözden geçirilmeyen sınıflandırıcı

PyPI, '1 - Planning'den '7 - Inactive'a kadar uzanan bir Development Status sınıflandırıcısıyla geliyor; bu tam da ihtiyaç duyulan sinyal gibi kulağa geliyor. Ama pratikte, yazarın bulduğu gibi, bu maintainer'ın seçtiği bir sürümde bir kez yazdığı serbest metin ve registry'nin bunu hiçbir zaman yeniden inceleyen bir mekanizması yok.

Verilen örnek nose: son sürümünü Haziran 2015'te çıkardı ve aradan geçen on yılın büyük bölümünde pytest'in gölgesinde kaldı, ama hâlâ '5 - Production/Stable' taşıyor. Yazar sağduyu testi olarak bu yıl yeni bir sürüm çıkaran requests'e baktı ve birebir aynı sınıflandırıcıyı buldu. Bu alanda aktif olarak sürdürülen bir kütüphane ile on bir yıldır dokunulmamış biri ayırt edilemiyor.

crates.io: en temiz timestamp ve hiçbir görüş yok

cargo'nun her çözümlemede okuduğu sparse index'de hiçbir status kavramı yok: deprecation bayrağı yok, sınıflandırıcı yok, elle kontrol edilecek bir homepage bile yok. Olan ise pubtime alanı ve yazar bunu neredeyse yanlış okuyordu. rustc-serialize 0.3.25'in yayım zamanı Aralık 2023 gösteriyor; bu, alan tanıtıldığında uygulanan bir göç damgası gibi görünüyordu. Ama crates.io'nun kendi dokümantasyonu pubtime'ın boşluklar olmadan geriye doldurulduğunu ve her zaman özgün yayım tarihini içerdiğini belirtiyor; bu sürüm gerçekten de crate'in parlak döneminden yaklaşık sekiz yıl sonra çıkarılmış bir hata düzeltmesiydi.

Gönderiye göre net sonuç şu: veri daha temiz ama karar tamamen size kalmış; crates.io kesin ve doğrulanabilir bir timestamp sunuyor ve o timestamp'in sizi endişelendirmesi gerekip gerekmediği hakkında hiçbir şey söylemiyor.

Yazarın özenle belirttiği uyarılar

Gönderi sınırları hakkında açık sözlü. Durumunu zaten bildiği package'lardan seçilmiş dokuz elden seçilmiş örnek, bir araştırmadan çok anekdot niteliğinde bir örneklem oluşturuyor ve PyPI'nın donmuş sınıflandırıcılarıyla ilgili iddia yalnızca iki package'a dayanıyor. Yazar, normalize edilmiş 'son dokunulma' artı 'açıkça işaretlenmiş' sütununu Package Registry Scraper projesine eklemeyi planlıyor ve alan alan bir kopya kâğıdı noble-ronin/package-staleness-data adıyla yayımladı.

Neden önemli

Terk edilmiş bağımlılıklar gerçek bir supply-chain açığıdır: bakımsız package'lar yamanmamış güvenlik açıkları biriktirir ve uykuya dalmış maintainer hesaplarının ele geçirilmesi durumunda birincil hedef olurlar. Registry'lerin kendileri uyuyan bir package ile ölü olanı ayırt edemiyorsa, her tüketici kendi sezgisel yöntemlerini çalıştırmak ya da gönderinin çoğu geliştiricinin yaptığı tahminine göre indirme sayılarına ve sezgiye geri dönmek zorunda kalır. Bir registry bakımlı ve düzenli olarak yeniden incelenen bir status sinyali sunana kadar, 'sizin yorumladığınız son yayım tarihi' elimizdeki en güvenilir kontrol olmaya devam eder ve tam da maintainer'lar not bırakmadan sessizce ayrıldıkları yerde en zayıf olanıdır.