GitHub CLI anahtarı değişti; eski Linux kurulumlarında güncelleme kesilebilir

GitHub, 3 Eylül 2026’da GitHub CLI’nin Linux paket depolarındaki imza anahtarı geçişini yeniden duyurdu; eski PGP anahtarı 5 Eylül’de sona erdi. GitHub’ın 3 Eylül uyarısı, bu tarihten sonraki ilk sürümle birlikte APT ve RPM depo meta verilerinin ve yeni RPM paketlerinin yalnızca yeni anahtarla imzalanacağını belirtiyor.

Bu nedenle 8 Nisan 2026’dan önce GitHub’ın resmî APT veya RPM deposuyla hazırlanmış ve daha sonra yenilenmemiş Linux kurulumları, yeni imzalı içerikle karşılaştığında paket güncellemesini durdurabilir. 4 Eylül’de yayımlanan bağımsız teknik değerlendirme, kurulu gh ikilisinin çalışmaya devam edebileceğini; asıl sorunun sonraki depo doğrulaması veya paket işleminde ortaya çıkacağını vurguluyor.

Önce kurulum kanalına göre etkilenme durumunu belirleyin

Belirleyici olan Linux dağıtımının yaşı değil, gh deposunun hangi yöntemle ve hangi güven dosyasıyla yapılandırıldığıdır. Karar ağacı şu şekilde ilerliyor:

• Windows veya macOS kullanıyorsanız bu Linux paket anahtarı değişimi sizi etkilemez.
• gh Homebrew, Conda, bir topluluk paket yöneticisi, kaynak kod, GitHub Releases arşivi ya da doğrudan indirilen DEB dosyasıyla kurulduysa bu geçiş kapsam dışındadır.
• Debian veya Ubuntu’da GitHub’ın resmî APT deposu 8 Nisan 2026’dan önce eklendiyse ve kurulum adımları daha sonra yeniden çalıştırılmadıysa keyring dosyasını denetleyin.
• Fedora, RHEL, CentOS, Amazon Linux 2, openSUSE veya SUSE üzerinde resmî RPM deposu aynı tarihten önce eklendiyse içe aktarılan anahtarları ve depo tanımını kontrol edin.
• Kurulum 8 Nisan’da veya sonrasında güncel resmî adımlarla yapıldıysa keyring yeni anahtarı zaten içermelidir. Tarih bilinmiyorsa yerel yapılandırmayı doğrulamak gerekir.

CI çalıştırıcısı, konteyner ya da hazır makine imajı kullanan ekiplerin denetimi imajın içinde yapması gerekir. Ana makinedeki güncel keyring, eski bir Docker katmanında veya önceden hazırlanmış bir CI görüntüsünde bulunan depo yapılandırmasını değiştirmez.

Tam parmak izini ve gerçek keyring yolunu kontrol edin

GitHub CLI’nin ayrıntılı geçiş duyurusu, 8 Nisan 2026’da yayımlanan güncel keyring’in eski 2C6106201985B60E6C7AC87323F3D4EA75716059 ve yeni 7F38BBB59D064DBCB3D84D725612B36462313325 parmak izlerini birlikte içerdiğini belgeliyor. Karşılaştırmayı kısa anahtar kimliğiyle değil, 40 karakterlik tam yeni parmak iziyle yapın.

Debian veya Ubuntu’da önerilen konumu şu komutla inceleyin: gpg --show-keys /etc/apt/keyrings/githubcli-archive-keyring.gpg. Dosya bulunamazsa eski konum için gpg --show-keys /usr/share/keyrings/githubcli-archive-keyring.gpg komutunu çalıştırın; o da sonuç vermezse cat /etc/apt/sources.list.d/github-cli.list çıktısındaki signed-by= değerinin gösterdiği dosyayı denetleyin.

Çıktıda iki parmak izi de görünüyorsa güncel keyring yerindedir. Yalnızca eski parmak izi görünüyorsa dosyanın değiştirilmesi gerekir; dosyanın doğru dizinde bulunması tek başına yeterli değildir, APT kaynak girdisindeki signed-by= değeri de aynı yolu göstermelidir.

RPM tabanlı sistemlerde GitHub CLI anahtar girdilerini rpm -qa gpg-pubkey | xargs -I{} sh -c 'rpm -qi {} | grep -q "[email protected]" && echo {}' komutuyla listeleyin. Yalnızca eski anahtar girdisi varsa depo yapılandırmasının yenilenmesi gerekir; ikinci girdinin bulunması yeni anahtarın içe aktarıldığını gösterir.

APT ve RPM yapılandırmasını resmî dosyalarla yenileyin

APT kaydı önerilen yolu kullanıyorsa önce dizini sudo mkdir -p -m 755 /etc/apt/keyrings komutuyla hazırlayın. Ardından güncel keyring’i sudo wget -qO /etc/apt/keyrings/githubcli-archive-keyring.gpg https://cli.github.com/packages/githubcli-archive-keyring.gpg && sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg komutuyla indirin.

Kaynak girdisindeki signed-by= başka bir konumu gösteriyorsa indirme hedefini o konuma uyarlayın veya kaynak girdisini önerilen yolla tutarlı hâle getirin. Paket işleminden önce gpg --show-keys /etc/apt/keyrings/githubcli-archive-keyring.gpg çıktısında yeni tam parmak izini doğrulayın; ardından sudo apt update ve sudo apt install gh komutlarını çalıştırın.

RPM ailesinde yeni anahtarın alınabilmesi için güncel depo dosyası yeniden eklenmelidir. Kullanılan paket yöneticisine uygun resmî komutlar şunlardır:

• DNF5 kullanan Fedora 41 veya daha yeni sürümlerde: sudo dnf config-manager addrepo --overwrite --from-repofile=https://cli.github.com/packages/rpm/gh-cli.repo, ardından sudo dnf update gh.
• DNF4 kullanan RHEL, CentOS ve Fedora 40 veya önceki sürümlerde: sudo dnf config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo, ardından sudo dnf update gh.
• Amazon Linux 2 ve Yum üzerinde: sudo yum-config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo, ardından sudo yum update gh.
• openSUSE veya SUSE üzerinde: sudo zypper removerepo gh-cli, sudo zypper addrepo https://cli.github.com/packages/rpm/gh-cli.repo ve sudo zypper update gh.

DNF ve Yum işlemleri için ilgili config-manager eklentisinin sistemde kurulu olması gerekir. Paket yöneticisi anahtarı içe aktarmayı istediğinde gösterilen parmak izini yeni tam değerle karşılaştırın; imza denetimini kapatmak veya GPG kontrolünü atlamak anahtar geçişini düzeltmez.

Otomasyon görüntülerinde düzeltmeyi kalıcı hâle getirin

Çalışan bir geliştirici makinesini düzeltmek, aynı eski yapılandırmayı taşıyan konteyner veya CI imajını güncellemez. Depoyu ekleyen Dockerfile katmanını, başlangıç betiğini, golden image tarifini ya da yapılandırma yönetimi kaydını güncel keyring veya depo dosyasını alacak şekilde değiştirin.

1. İmajın içinde gh kurulum kanalını; APT kullanılıyorsa gerçek signed-by= yolunu belirleyin.
2. Yeni tam parmak izinin imajın kendi keyring çıktısında bulunduğunu doğrulayın.
3. Eski katmanı yeniden kullanmamak için temiz veya önbelleksiz bir imaj oluşturun.
4. APT için apt update; RPM ailesi için uygun dnf update gh, yum update gh ya da zypper update gh işlemini imajın içinde çalıştırın.

Kesinleşen durum, eski anahtarın süresinin dolduğu ve sonraki yeni imzalı depo içeriğinin yalnızca yedek anahtarla doğrulanabileceğidir. Yeni anahtar yerel keyring’de bulunuyorsa ek işlem gerekmez; bulunmuyorsa hata, sistem yeni anahtarla imzalanmış meta veri veya paketle ilk kez karşılaştığında görünür hâle gelir.

Ayrıca okuyun:

• OpenAI, Cursor’dan çekiliyor: GPT erişimi 12 Kasım’da kesilebilir
• ISS’nin yüksek hızlı bağlantısı geri döndü: Anten uzay yürüyüşünde değişti