GitHub CLI Linux İmzalama Anahtarı 5 Eylül’de Doluyor: Kesintisiz Güncelleme Rehberi
GitHub CLI kullanan Linux sistemlerinde APT ve RPM imza doğrulamasını korumak için anahtarlık, konteyner ve otomasyon kontrolleri.
Hangi değişiklik yaklaşıyor?
GitHub, 3 Eylül 2026 tarihli duyurusunda Linux paket depolarının mevcut PGP imzalama anahtarının 5 Eylül 2026’da dolacağını hatırlattı. Bu tarihten sonraki ilk sürümden itibaren APT ve RPM depo metaverileri ile yeni RPM paketleri yalnızca yeni anahtarla imzalanacak.
Bu bir parola değişikliği veya GitHub hesabının ele geçirildiğine ilişkin duyuru değildir. Paket yöneticisinin indirdiği yazılımın kaynağını doğrulamak için kullandığı güven zincirinin planlı yenilenmesidir.
Kimlerin kontrol yapması gerekiyor?
Resmî APT veya RPM deposunu 8 Nisan 2026’dan önce kuran ve depo yapılandırmasını yenilemeyen Linux kullanıcıları öncelikli gruptadır. Windows, macOS, Homebrew, Conda, kaynak koddan kurulum ve doğrudan indirilen bağımsız paketler bu özel geçişten etkilenmiyor.
Kurulum tarihini bilmiyorsanız etkilenmediğinizi varsaymayın. Özellikle uzun ömürlü sunucular, kurum içi temel imajlar ve otomatik kurulum betikleri eski anahtarlığı yeni makinelere taşımaya devam edebilir.
- Resmî GitHub CLI deposunu kullanan Linux makinelerini bulun.
- APT ve RPM kurulum yollarını ayrı değerlendirin.
- Konteyner imajlarını ve self-hosted runner makinelerini listeye ekleyin.
- Her sistem için sorumlu kişi ve doğrulama tarihi belirleyin.
Anahtarlık doğrulaması
GitHub’ın ayrıntılı geçiş kaydı, yeni anahtarın tam parmak izini 7F38BBB59D064DBCB3D84D725612B36462313325 olarak veriyor. Debian ve Ubuntu sistemlerinde APT kaynağının işaret ettiği anahtarlık dosyası incelenmeli; yalnızca dosyanın bulunması yeterli sayılmamalıdır.
RPM tabanlı sistemlerde güvenilen anahtarlar paket yöneticisinin anahtarlığında tutulur. Dağıtımınıza uygun resmî adımları izleyin ve içe aktarma isteminde gösterilen tam parmak izini üreticinin duyurusuyla karşılaştırın.
İmza doğrulamasını kapatmak çözüm değildir. Bir güncellemenin çalışması için güvenlik kontrolünü atlamak, paketin gerçekten beklenen kaynaktan geldiğine ilişkin önemli bir korumayı ortadan kaldırır.
Otomasyonlarda kesintiyi önleyin
Bir geliştirici bilgisayarının düzeltilmesi, CI işlerinin de hazır olduğu anlamına gelmez. Runner, konteyner ve zamanlanmış işlerin kullandığı temel imajlarda anahtarlık ayrı ayrı kontrol edilmelidir.
Önbellekten gelen eski bir imaj sorunu yeniden üretebilir. Önce test ortamında depo metaverisini yenileyin, ardından kurulum veya yükseltme akışının imza hatası olmadan tamamlandığını doğrulayın.
- Mevcut depo yapılandırmasını ve anahtarlık yolunu kaydedin.
- Resmî yönergeyle güncel anahtarlığı uygulayın.
- Metaveri yenileme ve GitHub CLI yükseltmesini pilot ortamda sınayın.
- Temel imajları yeniden oluşturup gerçek otomasyon işini çalıştırın.
Başarılı geçiş nasıl kanıtlanır?
Kapanış kaydı yeni anahtarın güvenilir olduğunu, paket doğrulamasının açık kaldığını ve test işinin başarıyla tamamlandığını göstermelidir. Uygulama sürümünün görüntülenmesi tek başına gelecekteki paket güncellemelerinin çalışacağını kanıtlamaz.
5 Eylül sonrasında ilk paket güncellemesini ayrıca izleyin. İmza hatası görülürse geniş kapsamlı anahtar silme işlemleri yapmak yerine doğru depo, anahtarlık yolu ve paket yöneticisi yapılandırmasını yeniden karşılaştırın.