Extensão da validade da chave GPG usada para assinar metadados dos repositórios GitLab

Chave GPG do GitLab: o que foi alterado

A Chave GPG do GitLab que assina os metadados dos repositórios (fingerprint: F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F) estava com expiração prevista para 27 de fevereiro de 2026 e foi estendida até 6 de fevereiro de 2028. Essa extensão aplica-se ao uso da chave para assinar o metadata dos repositórios que distribuem os pacotes omnibus-gitlab e gitlab-runner, além das assinaturas separadas dos próprios pacotes.

Atenção — não confunda as chaves: este artigo trata da chave que assina os metadados dos repositórios (apt/yum; fingerprint F640 3F65 …). A chave que assina os pacotes Omnibus é outra — veja Extensão da chave de assinatura Omnibus do GitLab.

Na prática, essa é a chave que o apt e o yum/dnf usam para validar o Release/InRelease (Debian/Ubuntu) e os metadados repomd.xml (RHEL/derivados) dos repositórios do GitLab. Quando ela expira, o gerenciador de pacotes deixa de confiar nos metadados e seus apt update/dnf makecache começam a falhar com erros de assinatura — mesmo que os pacotes em si estejam intactos. É exatamente esse cenário que a extensão da validade evita, sem exigir troca de par de chaves.

Por que a validade foi estendida

A extensão da validade da chave visa minimizar o risco operacional e seguir as políticas de segurança do GitLab. Manter o mesmo par de chaves e estender a data de expiração é menos disruptivo para usuários corporativos, pois evita a necessidade de substituir a chave confiável em todos os nós. A medida reduz janelas de exposição caso a chave seja comprometida e permite coordenar uma rotação planejada quando necessária.

Do ponto de vista de quem opera frota grande, a diferença entre "estender validade" e "rotacionar chave" é enorme:

Cenário	Extensão de validade (este caso)	Rotação de chave
Fingerprint muda?	Não — continua F640 3F65 …	Sim — novo material de chave
Ação no parque instalado	Atualizar a cópia pública local	Importar e confiar em uma chave nova
Risco de quebra de confiança	Baixo (mesmo trust anchor)	Alto se algum nó ficar para trás
Janela de coordenação	Folgada	Curta e crítica
Automação necessária	Idempotente, sem mudança de trust	Distribuição controlada do novo keyring

Como o fingerprint não muda, quem já confia na chave hoje continua confiando depois da extensão. O que precisa ser corrigido é apenas a cópia local que carrega a data de expiração antiga — caso contrário o seu keyring local pode considerar a chave vencida em 27 de fevereiro de 2026, mesmo que o servidor já tenha a versão estendida.

O que sua equipe de infraestrutura precisa fazer

Se os repositórios do GitLab já estiverem configurados em suas máquinas antes de 27 de fevereiro de 2026, verifique e atualize a cópia pública da chave conforme as instruções oficiais. Novos usuários que seguirem a página de instalação do GitLab ou a documentação do gitlab-runner não precisam de ação específica além do procedimento de instalação padrão.

Para atualizar uma cópia local da chave pública sem alterar a configuração de confiança, você pode obter a chave pública pelos keyservers pesquisando por [email protected] ou pelo ID/fingerprint completo (F6403F6544A38863DAA0B6E03F01618A51312F3F). Também é possível recuperar a chave diretamente do repositório público de pacotes (ex.: packages.gitlab.com/gpg.key) — observe que neste documento esse endereço é apresentado como referência e o link oficial de anúncio está ao final.

Como descobrir se você é afetado

Antes de mexer em qualquer host, identifique quem confia nessa chave hoje. Procure o keyring associado aos repositórios GitLab:

# Debian/Ubuntu — keyrings dedicados (padrão moderno com signed-by)
grep -R "signed-by" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

# Inspeciona o keyring referenciado e mostra a validade da chave
gpg --no-default-keyring \
    --keyring /usr/share/keyrings/gitlab_gitlab-ce-archive-keyring.gpg \
    --list-keys --with-fingerprint

# RHEL/derivados — chaves importadas no RPM
rpm -qa gpg-pubkey* --qf '%{NAME}-%{VERSION}-%{RELEASE} %{SUMMARY}\n'

Confira a linha de expiração (expires:/[expires: ...]) na saída. Se ela ainda apontar para 27 de fevereiro de 2026, esse host carrega a cópia antiga e precisa ser atualizado.

Atualizando a cópia pública

A operação é uma simples atualização do mesmo material de chave — nada de remover e reimportar uma chave diferente:

# Opção A — buscar a versão estendida pelo fingerprint num keyserver
gpg --keyserver hkps://keys.openpgp.org \
    --recv-keys F6403F6544A38863DAA0B6E03F01618A51312F3F

# Opção B — atualizar tudo que já está no keyring local
gpg --refresh-keys --keyserver hkps://keys.openpgp.org

# Reexportar para o keyring usado pelo apt (Debian/Ubuntu)
gpg --export F6403F6544A38863DAA0B6E03F01618A51312F3F \
    | sudo tee /usr/share/keyrings/gitlab_gitlab-ce-archive-keyring.gpg > /dev/null

Em RHEL/derivados, reimporte a chave atualizada e valide o cache:

sudo rpm --import /etc/pki/rpm-gpg/gitlab-gitlab-ce.gpg   # ou o gpg.key oficial
sudo dnf makecache

Verificação e boas práticas

Confirme o fingerprint após a importação e antes de marcar a chave como confiável em hosts de produção. Mantenha procedimento formal de verificação em sua pipeline de provisionamento de servidores (importação, verificação do fingerprint e aplicação de confiança) para reduzir riscos de supply-chain. A extensão da validade não substitui controles de revogação e monitoramento de integridade dos repositórios.

A regra de ouro é nunca confiar em uma chave só porque ela foi baixada. Sempre compare o fingerprint completo contra o valor publicado oficialmente:

# Mostra o fingerprint da chave recém-importada
gpg --fingerprint [email protected]

# Esperado (sem espaços):
# F6403F6544A38863DAA0B6E03F01618A51312F3F

Se o fingerprint não bater exatamente, pare: não marque a chave como confiável e investigue a origem. Um keyserver é um canal não autenticado — ele entrega o que você pede, mas não garante autenticidade. A garantia vem da comparação do fingerprint contra a fonte oficial.

Checklist de rollout corporativo

Para frotas grandes e ambientes regulados, trate isso como uma mudança controlada, não como um comando solto em produção:

1. Inventário — liste todos os hosts e pipelines que consomem repositórios GitLab (servidores de build/CI, runners, proxies de pacote como Artifactory/Nexus/apt-mirror, scanners de segurança e estações de administração).
2. Baseline — registre a validade atual da chave em cada classe de host antes de mexer (a saída de gpg --list-keys serve de evidência de auditoria).
3. Staging primeiro — aplique a atualização num grupo canário e rode apt update / dnf makecache para confirmar que os metadados validam sem erro de assinatura.
4. Verificação do fingerprint — automatize a checagem do fingerprint F6403F6544A38863DAA0B6E03F01618A51312F3F como gate antes de aplicar confiança.
5. Idempotência — entregue via Ansible/Chef/Puppet/Salt com tarefa que pode rodar N vezes sem efeito colateral; evite scripts que removem e reimportam às cegas.
6. Propagação gradual — vá do grupo canário para produção em ondas, com janela de observação entre elas.
7. Monitoramento — alerte sobre falhas de verificação de assinatura e sobre proximidade de expiração de qualquer chave do parque (não só esta).
8. Rollback documentado — tenha o procedimento de reverter para a cópia anterior pronto, caso algum proxy de pacote interno fique fora de sincronia.

Validação em CI/CD

Quem usa o GitLab Runner em pipelines Docker que instalam pacotes deve incluir um passo explícito de verificação. Um gate simples em GitLab CI:

verify-gitlab-gpg:
  stage: validate
  image: debian:stable-slim
  script:
    - apt-get update && apt-get install -y --no-install-recommends gnupg curl ca-certificates
    - curl -fsSL https://packages.gitlab.com/gpg.key -o /tmp/gitlab.gpg
    - FPR=$(gpg --show-keys --with-colons /tmp/gitlab.gpg | awk -F: '/^fpr:/{print $10; exit}')
    - echo "Fingerprint recebido: $FPR"
    - test "$FPR" = "F6403F6544A38863DAA0B6E03F01618A51312F3F"
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'

Rodar esse job num schedule transforma a verificação em controle contínuo: se a fonte oficial mudar inesperadamente, o pipeline falha e você é avisado antes que algo entre em produção.

Contexto de supply-chain

Assinatura de metadados de repositório é a primeira camada da cadeia de confiança de pacotes: ela garante que a lista de pacotes e seus hashes não foram adulterados em trânsito ou num espelho comprometido. A assinatura separada dos próprios pacotes (a chave Omnibus, tratada no outro artigo) é a segunda camada. Operar com as duas reduz a superfície para ataques de man-in-the-middle, espelhos maliciosos e cache poisoning.

Por isso, extensão de validade não é "marcar caixinha de compliance". Ela mantém viva uma das âncoras de confiança da sua cadeia de distribuição. As práticas que sobrevivem a este evento e ao próximo:

• Pin de fingerprint em vez de confiar em qualquer chave entregue por keyserver.
• signed-by por repositório (Debian/Ubuntu) para que a chave do GitLab só assine os repositórios do GitLab, e não tudo no sistema.
• Inventário de chaves com data de expiração, para que o próximo vencimento seja planejado e não vire incidente às 3 da manhã.
• Verificação contínua em CI, capturando mudanças na fonte antes do deploy.

Suporte e rastreamento de problemas

Se precisar de assistência técnica adicional relacionada à importação da chave ou à verificação das assinaturas do metadata, abra uma issue no issue tracker do omnibus-gitlab conforme indicado pelo projeto GitLab. Para informações oficiais sobre este anúncio e histórico, consulte a nota publicada pelo GitLab.

Referência oficial: Anúncio da extensão da chave GPG do GitLab.

Se sua equipe precisa inventariar onde essa chave é consumida, automatizar a atualização de forma idempotente e adicionar verificação de fingerprint nas pipelines sem arriscar quebra de deploy, fale com a Excelium — integramos verificação, testes em staging e implantação coordenada na sua frota.