Linux’ta GitHub CLI güncellemesi imza hatası veriyorsa depo anahtarını kontrol etme zamanı. GitHub’ın 3 Eylül 2026 tarihli duyurusunda belirttiği eski Linux paket deposu PGP anahtarının süresi 5 Eylül’de doldu. Duyuruya göre bu tarihten sonraki ilk sürümden itibaren APT ve RPM depo üst verileri ile yeni RPM paketleri yalnızca yenileme anahtarıyla imzalanacak. 8 Eylül itibarıyla önemli olan, sisteminizin bu anahtara güvendiğini doğrulamak.

Bu değişiklik GitHub hesabınızın parolasını veya SSH anahtarınızı etkilemiyor. Konu, gh komutunu Linux’a hangi kanaldan kurduğunuz ve sisteminizin yeni paket imza anahtarına güvenip güvenmediği. Özellikle uzun süredir güncellenmeyen geliştirici bilgisayarları, CI kalıpları ve şirket içi container imajları kontrol edilmeli.

Kim etkileniyor, kim etkilenmiyor?

GitHub’ın açıklamasına göre gh aracını resmi APT veya RPM depolarından 8 Nisan 2026’dan önce kuran ve depo kurulumunu o tarihten sonra güncellemeyen kullanıcılar işlem yapmalı. Ne zaman kurduğunuzu bilmiyorsanız ya da otomasyon için özel bir imaj kullanıyorsanız, güven deposunu doğrulamak en güvenli yaklaşım.

Windows ve macOS kullanıcıları bu değişiklikten etkilenmiyor. Homebrew, Conda veya topluluk paket yöneticisi kullananlar; kaynaktan derleyenler; GitHub Releases üzerinden doğrudan .deb veya bağımsız arşiv indirenler de duyurunun kapsamı dışında. Yine de kuruluş içinde farklı kurulum yöntemleri karışık olabilir; yalnız kendi dizüstü bilgisayarınıza bakmak yeterli olmayabilir.

Bu bir güvenlik açığı mı?

Hayır. GitHub duyurusu bir CVE veya sızıntı bildirmiyor; planlı bir anahtar sona ermesi ve geçişi anlatıyor. Paket yöneticileri, indirdikleri depo bilgilerinin ve paketlerin beklenen yayıncı tarafından imzalandığını doğrular. Süresi dolmuş anahtar güven zincirinde bulunursa güncelleme sırasında imza doğrulama hatası görebilirsiniz. Anahtarı rastgele bir forumdan yenilemek ise sorunu çözmek yerine tedarik zinciri riskini büyütür.

APT kullanan sistem nasıl kontrol edilir?

Önce kurulum kaynağını görün. Dağıtıma göre dosya yolları değişebilse de aşağıdaki ilk üç komut kurulum bilgisini okur; son komut ise paket listesini yeniler, paket kurmaz:

command -v gh
gh --version
grep -R "cli.github.com/packages" /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null
sudo apt update

apt update sırasında GitHub CLI deposu için “NO_PUBKEY”, “EXPKEYSIG” veya doğrulanamayan imza uyarısı görürseniz hatayı atlayan seçenekler kullanmayın. GitHub’ın resmi tam duyurusundaki güncel keyring kurulum adımlarını izleyin. İndirdiğiniz anahtar dosyasının adresinin github.com veya GitHub’ın resmi cli.github.com altyapısına ait olduğunu ayrıca kontrol edin.

RPM tabanlı sistem nasıl kontrol edilir?

Fedora, RHEL, Rocky Linux veya benzerlerinde amaç yine kaynağı ve imza güvenini doğrulamaktır:

command -v gh
gh --version
grep -R "cli.github.com/packages" /etc/yum.repos.d 2>/dev/null
sudo dnf makecache

Önbellek yenilenirken anahtar içe aktarma sorusu çıkarsa parmak izini GitHub’ın resmi geçiş belgesiyle karşılaştırmadan onaylamayın. “GPG check” özelliğini kapatmak veya imzasız paketi zorlamak, paketin kaynağını doğrulayan ana korumayı devre dışı bırakır.

CI ve container imajlarında asıl risk

Geliştirici bilgisayarı düzenli güncellenirken aylar önce oluşturulmuş bir CI taban imajı unutulabilir. Dockerfile içinde eski keyring indiriliyor, şirket içi önbellek eski dosyayı sunuyor veya imaj katmanı yeniden oluşturulmuyor olabilir. Türkiye’de hafta sonu veya gece çalışan dağıtımlar için 5 Eylül sonrasında ansızın paket kurulumunun durması, iş akışını doğrudan etkileyebilir.

Bir deneme dalında imajı önbelleksiz yeniden oluşturun. Ardından gh --version, depo güncellemesi ve basit bir kimlik doğrulamasız komutla çalışmayı kontrol edin. Paketi ayrıca elle indirdiyseniz, dosyanın bütünlüğünü SHA-256 dosya doğrulama rehberindeki yöntemlerle denetleyebilirsiniz; ancak hash doğrulaması ile yayıncı imzasının aynı şey olmadığını unutmayın.

Beş dakikalık ekip kontrol listesi

  • gh kullanan Linux bilgisayar ve imajları envanterden bulun.
  • Kurulum kanalını APT, RPM, Homebrew, arşiv veya diğer olarak sınıflandırın.
  • APT/RPM kurulumunun 8 Nisan 2026’dan önce olup olmadığını kontrol edin.
  • GitHub’ın resmi duyurusundan yenileme keyring’ini doğrulayın.
  • CI imajını önbelleksiz üretip depo güncellemesini test edin.
  • İmza denetimini kapatan geçici çözümü kabul etmeyin.

Geçişten sonra ne doğrulanmalı?

Yeni anahtarın sisteme eklenmesi tek başına son kontrol değildir. Paket yöneticisinin hatasız depo üst verisi indirdiğini, yeni bir gh sürümünü doğrulayabildiğini ve eski anahtarın neden tutulduğunun bilindiğini kayda geçirin. Kuruluş içinde keyring dağıtımını yapılandırma yönetimiyle yapıyorsanız, değişikliğin hangi imaj sürümüne girdiğini not edin.

Geçiş kaydına tarih, uygulanan resmi talimatın bağlantısı, test edilen işletim sistemi ve imaj etiketi ekleyin. Böylece aylar sonra aynı hata başka bir makinede görüldüğünde ekip, güvenli çözümü yeniden araştırmak zorunda kalmaz. Kurumsal vekil sunucu veya paket aynası kullanılıyorsa yeni keyring dosyasının aynaya ulaştığını da denetleyin; dış depoda düzeltilmiş bir yapı, içerideki eski önbellek yüzünden hâlâ başarısız olabilir.

Bir hata mesajının ekran görüntüsünü paylaşırken erişim belirteci, iç depo adresi veya kullanıcı adı görünmediğinden emin olun. Sorunu çözmek için kişisel GitHub token’ını komut satırına yapıştırmanız gerekmez; burada doğrulanan şey hesap oturumu değil paket yayıncısının imzasıdır.

En doğru hareket aceleyle anahtar aramak değil, kurulum kanalını saptayıp GitHub’ın resmi geçiş belgesini izlemektir. Çoğu kullanıcı etkilenmeyecek; fakat etkilenen tek eski CI imajı bile kritik dağıtımı durdurabilir.

Kaynaklar