Chave PGP do GitHub CLI expira em 5 de setembro: como atualizar no Linux

Resposta rápida

A chave PGP usada para assinar os pacotes do GitHub CLI nos repositórios oficiais para Linux expira em 5 de setembro de 2026. A primeira versão publicada depois do vencimento terá os pacotes e metadados APT e RPM assinados apenas com a nova chave. Instalações que ainda confiam somente na chave antiga podem receber erros de assinatura ao executar apt, dnf, yum ou zypper.

Isso não significa que o GitHub ou o comando gh caiu. É uma falha local de verificação de confiança do repositório. Se o GitHub CLI foi instalado pelo repositório oficial APT ou RPM antes de 8 de abril de 2026 e o keyring não foi atualizado desde então, verifique e atualize a chave. Instalações mais recentes feitas pelas instruções oficiais já devem conter as duas chaves, mas ambientes antigos e imagens em cache merecem conferência.

Quem será afetado pela troca da chave

O aviso oficial cobre usuários que instalaram o GitHub CLI pelos repositórios oficiais APT ou RPM e ainda mantêm apenas a chave antiga. O risco é maior em servidores pouco atualizados, imagens Docker antigas, runners de CI reutilizados e scripts que copiam um keyring fixo de uma imagem-base.

Windows, macOS, compilações a partir do código-fonte, Homebrew, Conda, arquivos .deb baixados diretamente, pacotes standalone e gerenciadores mantidos pela comunidade não dependem dessa chave específica do repositório oficial. Em ambientes personalizados, confira o método de instalação antes de alterar qualquer configuração.

Como verificar a chave no Ubuntu ou Debian

Execute o comando abaixo para listar as chaves no keyring atual. Se o arquivo não existir nesse caminho, tente o caminho antigo em /usr/share/keyrings. Também confira o campo signed-by do arquivo de origem APT para saber qual keyring o sistema realmente usa.

• Liste as chaves com: gpg --show-keys /etc/apt/keyrings/githubcli-archive-keyring.gpg
• Se necessário, tente: gpg --show-keys /usr/share/keyrings/githubcli-archive-keyring.gpg
• Confira a origem configurada com: cat /etc/apt/sources.list.d/github-cli.list
• Procure a chave antiga 2C6106201985B60E6C7AC87323F3D4EA75716059 e a nova 7F38BBB59D064DBCB3D84D725612B36462313325.
• Se as duas impressões digitais aparecerem, o keyring está preparado para a rotação e nenhuma ação adicional é necessária.

Como atualizar no Ubuntu ou Debian

Se apenas a chave antiga aparecer, baixe o keyring atual diretamente do endereço oficial do GitHub CLI. Os comandos abaixo usam o caminho adotado nas instruções atuais. Antes de executá-los em um sistema personalizado, confirme se o signed-by da origem APT aponta para o mesmo arquivo.

• Crie o diretório: sudo mkdir -p -m 755 /etc/apt/keyrings
• Baixe o keyring: sudo curl -fsSL -o /etc/apt/keyrings/githubcli-archive-keyring.gpg https://cli.github.com/packages/githubcli-archive-keyring.gpg
• Libere a leitura: sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg
• Atualize os metadados: sudo apt update
• Atualize ou instale o CLI: sudo apt install gh
• Repita o comando gpg --show-keys e confirme que as duas impressões digitais aparecem.

Como verificar e corrigir distribuições RPM

Em Fedora, RHEL, CentOS, Amazon Linux e openSUSE, a correção depende do gerenciador e do arquivo de repositório. Primeiro identifique a chave do GitHub CLI instalada. Depois atualize a definição do repositório a partir do endereço oficial e execute a atualização do pacote.

• Liste a chave relacionada ao GitHub CLI: rpm -qa gpg-pubkey | xargs -I{} sh -c 'rpm -qi {} | grep -q "opensource+cli@github.com" && echo {}'
• No DNF5, atualize o repositório com: sudo dnf config-manager addrepo --overwrite --from-repofile=https://cli.github.com/packages/rpm/gh-cli.repo
• No DNF4, use: sudo dnf config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo
• No Amazon Linux 2 com yum, use: sudo yum-config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo
• Conclua com sudo dnf update gh ou sudo yum update gh, conforme o sistema.
• Em openSUSE, remova e adicione novamente o repositório pelo endereço oficial antes de atualizar o gh.

Atenção a Docker, CI e imagens antigas

Um Dockerfile pode continuar copiando a chave antiga mesmo que a máquina do desenvolvedor já esteja atualizada. O mesmo vale para runners autogerenciados, snapshots e imagens-base que ficaram semanas ou meses sem reconstrução. Atualize o keyring antes de apt update ou dnf update e gere a imagem novamente sem reutilizar a camada antiga desse download.

Não basta instalar uma versão recente do executável gh se a origem de pacotes continua apontando para um keyring antigo. A verificação deve ocorrer no ambiente que executa o gerenciador de pacotes, inclusive dentro do contêiner ou runner.

Erros que indicam uma chave antiga

Depois do vencimento, mensagens como EXPKEYSIG, NO_PUBKEY, GPG check FAILED ou falha na verificação de assinatura são sinais compatíveis com um keyring desatualizado. Leia a mensagem completa: problemas de DNS, proxy, relógio incorreto, certificado TLS ou repositório mal configurado podem produzir falhas diferentes.

Não desative a checagem de assinatura para fazer a atualização passar. A assinatura existe para confirmar que o pacote e os metadados vieram do publicador esperado e não foram alterados no caminho.

O que não fazer

Evite atalhos que removem a proteção justamente durante uma troca de chave. A correção deve preservar a validação criptográfica e usar os endereços mantidos pelo projeto oficial.

• Não use --allow-unauthenticated, --nogpgcheck ou opções equivalentes para ignorar a assinatura.
• Não importe uma chave copiada de fórum, arquivo compartilhado ou servidor de chaves sem confirmar a impressão digital oficial.
• Não remova a origem do GitHub CLI sem registrar como o pacote será mantido depois.
• Não trate todo erro do comando gh como incidente do GitHub; se a instalação funciona mas chamadas à API falham, confira a página oficial de status.

Limites deste diagnóstico

Este procedimento se aplica ao repositório oficial do GitHub CLI para Linux e foi conferido em 4 de setembro de 2026. Distribuições e gerenciadores comunitários podem usar outros processos, chaves e calendários de atualização. Siga a documentação do mantenedor do pacote nesses casos.

Ver a nova impressão digital confirma que o keyring contém a chave de substituição, mas não audita todo o sistema. Permissões incorretas, proxies que interceptam tráfego, origens duplicadas e arquivos signed-by divergentes ainda podem impedir a atualização.

Próxima ação útil

Execute hoje a verificação do keyring no mesmo servidor, contêiner ou runner que instala o gh. Se as duas impressões digitais estiverem presentes, registre o resultado e não altere a configuração. Se apenas a antiga aparecer, atualize o arquivo pelo endereço oficial e refaça o teste. Caso o pacote atualize normalmente, mas comandos contra o GitHub continuem falhando, consulte o status oficial e faça um diagnóstico externo do domínio antes de mudar DNS, proxy ou firewall.

Fontes consultadas

Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.

• GitHub CLI Linux package signing key expires September 5GitHub Changelog
• GitHub CLI package repositories: PGP key rotationGitHub CLI
• Official Linux installation instructionsGitHub CLI
• GitHub StatusGitHub