CI'da npm publish 404 hataları, eksik OIDC trusted publishing desteğini gizleyebilir

npm, 2FA'yı atlayan granular token'lara son veriyor

dev.to'da yayımlanan bir geliştirici yazısına göre npm'in granular access token'ları, iki aşamalı kimlik doğrulamayı (2FA) atlama yeteneğini aşamalar halinde kaybediyor. 31 Temmuz 2026'dan itibaren bu token'lar artık hesap, organizasyon veya paket yönetimi işlemlerini gerçekleştiremeyecek; bu, trusted publishing yapılandırmasını düzenlemeyi de kapsıyor. Ocak 2027'de ise doğrudan publish haklarını da kaybedecekler ve geriye yalnızca private paketleri okuyabilme ve bir maintainer'ın 2FA ile onaylaması gereken bir release'i hazırlayabilme yetkileri kalacak.

Bunun yerine önerilen çözüm OIDC Trusted Publishing: uzun ömürlü bir token'ı CI secret olarak saklamak yerine, maintainer bir GitHub repository'sini ve workflow'unu npmjs.com üzerinde kaydeder; workflow da kısa ömürlü bir OIDC token'ı registry erişimiyle takas eder.

Yalan söyleyen bir 404

Yazının yazarı bir paketi taşımış ve release workflow'unun üst üste dört kez, paketin registry'de bulunmadığını iddia eden bir hatayla başarısız olduğunu izlemiş — oysa paket mevcuttu, yayımlanmış sürümleri vardı ve aynı hesaba aitti.

Yazıya göre kök neden şu: workflow Node 20'ye sabitlenmişti ve Node 20, npm 10.8.2 ile geliyor; oysa OIDC Trusted Publishing yalnızca npm 11.5.1 ile geldi. npm 10'daki destek bozuk değil; tamamen yok. İstemci token takasını hiç denemiyor, üretilen .npmrc içinde duran hangi token varsa ona geri düşüyor ve fiilen kimlik doğrulamasız bir publish denemesi yapıyor.

Bunun 403 yerine 404 olarak ortaya çıkmasının nedeni, yazının açıkladığına göre bilinçli bir registry davranışı. Yazamadığınız bir paket için 403 döndürmek, paketin var olduğunu doğrulamak olur ve private paketlerin varlığını adını tahmin edebilen herkese sızdırırdı. Bu yüzden npm hem var olmayan paketler hem de dokunmanıza izin verilmeyen paketler için 404 yanıtı veriyor. Size ait bir pakette bu mesaj, bir isimlendirme sorunu değil, bir kimlik doğrulama sorunu olarak okunmalı.

İki yanlış iz

Yazı, hata ayıklama zamanı harcatan iki yanıltıcı sinyali ayrıntılarıyla anlatıyor.

Birincisi, provenance imzalama başarılıydı. Workflow bir provenance ifadesini imzalayıp sigstore transparency log'una göndermişti; bu, OIDC token'ın çalıştığının kanıtı gibi görünüyor. Ancak provenance imzalama, bir attestation'ı imzalamak için OIDC id-token'ını kullanır; Trusted Publishing ise aynı id-token'ı bir registry auth token'ıyla takas eder — farklı npm sürümlerinde gelen, ayrı kod yollarındaki ayrı mekanizmalar. Biri kusursuz çalışırken diğeri hiç var olmayabilir.

İkincisi, adım ortamında NODE_AUTH_TOKEN değeri XXXXX-XXXXX-XXXXX-XXXXX olarak görünüyordu; bu, maskelenmiş bir secret'a benziyor. Öyle değil: yazı, actions/setup-node v4'ün kaynak koduna atıf yapıyor; bu aksiyon, hiçbir token verilmediğinde npm'in eksik değişken uyarısı vermemesi için tamamen bu sahte değeri export ediyor. Aksiyonun main dalı artık değişkeni yalnızca kullanıcı bir token sağladığında export edecek şekilde değişti; yani etki sürüme özgü. Önceden ayarlanmış bir token zaten OIDC'yi engellemezdi, çünkü npm'in publish komutu kimlik bilgilerini okumadan önce OIDC yardımcısını çalıştırıyor ve auth token'ını doğrudan üzerine yazıyor.

Çözüm

İki değişiklik sorunu çözdü. Workflow, npm 11.19.0 ile gelen Node 24'e taşındı ve bir önlem olarak npm 11.5.1 veya daha yeni bir sürümün açık bir global kurulumu eklendi. Bu önlem önemli, çünkü Node 24.0.0, eşiğin altında olan npm 11.3.0 ile yayımlanmıştı; yani yalnızca major sürümü sabitlemek bir garanti değil. npm --version çıktısını log'a yazdırmak, bir sonraki kişinin sürümü bir bakışta elemesini sağlıyor.

Kimlik doğrulama çalışır hale geldiğinde hata 422'ye dönüştü: sigstore provenance yalnızca public kaynak repository'lerini destekliyor ve yayımlayan repo private'dı. Doğru çözüm --provenance flag'ini tamamen kaldırmaktı, --no-provenance geçmek değil; çünkü npm, provenance'ı yalnızca flag varsayılanında bırakıldığında ve repository görünürlüğü public olduğunda otomatik etkinleştiriyor.

Neden önemli

CI üzerinden npm paketi yayımlayan herkes bu kombinasyonla yakında karşılaşacak. Ocak 2027 sınırı, granular token'lardan doğrudan publish hakkını kaldırıp maintainer'ları OIDC Trusted Publishing'e itiyor; Node 20'ye veya daha eski bir npm'e sabitlenmiş workflow'lar ise gerçek sorundan uzağı işaret eden biçimlerde başarısız olacak. 404 bir registry ya da isimlendirme sorunu gibi okunuyor, sahte token sızdırılmış bir credential gibi görünüyor ve başarılı bir provenance adımı OIDC'yi yanlışlıkla aklıyor. Göç penceresi kapanmadan önce npm --version kontrolü — ve en az 11.5.1 şartı — en ucuz savunma.