Extensão da validade da chave de assinatura Omnibus do GitLab

O GitLab prorrogou a data de expiração da chave GPG usada para assinar os pacotes Omnibus, evitando uma rotação imediata e reduzindo impacto operacional. Para quem opera GitLab self-managed em escala, isso significa uma coisa prática: nenhuma quebra de confiança nos próximos dois anos — mas vale conferir se a sua cópia local da chave está atualizada e, sobretudo, se a sua pipeline realmente verifica a assinatura dos pacotes antes de instalá-los. Abaixo, o que mudou, como validar com gpg, e um roteiro de rollout corporativo sem surpresas em produção.

Atenção — não confunda as chaves: este artigo trata da chave que assina os pacotes Omnibus (ID 98BF DB87 FCF1 0076 416C 1E0B AD99 7ACC 82DD 593D). A chave que assina os metadados dos repositórios (apt/yum) é diferente — veja Extensão da chave GPG dos metadados dos repositórios.

Chave de assinatura Omnibus GitLab — o que mudou

O GitLab utiliza uma chave GPG dedicada para assinar todos os pacotes Omnibus gerados nas pipelines de CI; esta chave é distinta da chave que assina metadados de repositório usados por gerenciadores de pacotes (como apt/yum) e também diferente da chave GPG do GitLab Runner. A expiração previamente marcada para 14 de fevereiro de 2026 foi estendida para 16 de fevereiro de 2028. A medida foi tomada para cumprir políticas de segurança e reduzir a superfície de exposição no caso de comprometimento, optando-se por estender a validade em vez de forçar uma rotação que exigiria todos os consumidores substituírem a chave confiável.

Razões técnicas para a extensão:

• Conformidade com políticas internas de segurança, que preveem revisões periódicas de validade de chaves.
• Minimização de interrupção operacional: uma rotação de chave força atualização dos repositórios de confiança em clientes e servidores que validam assinaturas.
• Redução de risco por expor rotação apenas quando necessária e com janelas de planejamento adequadas para ambientes corporativos.

Vale entender o detalhe que muita gente confunde: estender a expiração não gera uma chave nova. O material criptográfico (o par de chaves) é o mesmo — apenas o campo de validade no pacote da chave pública foi reassinado com uma data posterior. O fingerprint, portanto, não muda. Quem já confia em 98BF DB87 FCF1 0076 416C 1E0B AD99 7ACC 82DD 593D continua confiando exatamente na mesma chave; o que pode estar desatualizado na sua máquina é a cópia local que ainda carrega a data de expiração antiga (14 de fevereiro de 2026). É por isso que a ação recomendada é um refresh, não uma reimportação às cegas.

Três chaves diferentes — não misture

Chave	O que assina	Onde aparece
Chave de pacotes Omnibus	os .deb/.rpm Omnibus em si	este artigo — ID 98BF DB87 …
Chave de metadados do repositório	o índice apt/yum (Release, repomd.xml)	post sobre metadados
Chave do GitLab Runner	pacotes do gitlab-runner	repositório/documentação do Runner

Errar a chave é a causa mais comum de "validação passou, mas eu validei a coisa errada". Confirme sempre o fingerprint antes de marcar confiança.

O que sua organização precisa fazer

Se sua organização valida assinaturas dos pacotes Omnibus distribuídos pelo GitLab, a única ação necessária é atualizar a cópia local da chave pública caso você ainda mantenha uma versão antiga. Se sua infraestrutura não verifica explicitamente as assinaturas de pacote (ou se a validação é feita apenas nos metadados do gerenciador de pacotes), então não há necessidade de ação imediata para continuar instalando pacotes Omnibus.

Procedimento recomendado (corporativo):

1. Verifique se seus processos de distribuição internos ou sistemas de build/CI fazem validação das assinaturas dos pacotes Omnibus.
2. Se validar assinaturas, atualize a chave pública nos servidores de build, caches de artefatos e estações de administração com a nova versão da chave fornecida pelo GitLab.
3. Teste a validação em um ambiente de staging antes de propagar para produção para garantir que não haja falhas de confiança que impactem deploys automatizados.

Para localizar a chave pública sem forçar uma rotação manual, busque-a em servidores GPG por [email protected] ou usando o ID da chave: 98BF DB87 FCF1 0076 416C 1E0B AD99 7ACC 82DD 593D. Esta ação permite que equipes de segurança e de infraestrutura atualizem seus repositórios de confiança sem depender de uma troca abrupta de chave.

"Eu valido ou não valido?" — como descobrir

A pergunta operacional mais importante é se a sua instalação realmente confere a assinatura do pacote Omnibus, ou se você apenas confia no canal de download. Um teste rápido é inspecionar a assinatura embutida no pacote antes de instalá-lo:

# Inspecionar a assinatura GPG de um pacote .deb Omnibus
dpkg-sig --verify gitlab-ce_*.deb

# Em ambientes RPM, a assinatura aparece no cabeçalho do pacote
rpm --checksig gitlab-ce-*.rpm

Se esses comandos retornarem NOSIG/no signature ou indicarem uma chave desconhecida, então a sua instalação não está exercendo verificação criptográfica de origem — e é aí que vale a pena fechar essa lacuna.

Verificação prática com gpg

Antes de marcar a chave como confiável em qualquer host de produção, confirme o fingerprint. Nunca confie em uma chave sem comparar o fingerprint completo com o valor publicado pelo GitLab.

# Importar (ou atualizar) a chave a partir de um keyserver
gpg --keyserver hkps://keys.openpgp.org \
    --recv-keys 98BFDB87FCF10076416C1E0BAD997ACC82DD593D

# Conferir o fingerprint completo após a importação
gpg --fingerprint 98BFDB87FCF10076416C1E0BAD997ACC82DD593D

# Inspecionar a data de expiração (deve refletir 2028-02-16)
gpg --list-keys --with-colons 98BFDB87FCF10076416C1E0BAD997ACC82DD593D

Na saída de --with-colons, a linha que começa com pub: traz o timestamp de expiração no campo apropriado; convertendo para data legível, ela deve corresponder a 16 de fevereiro de 2028. Se a sua cópia ainda mostrar 14 de fevereiro de 2026, faça o refresh da chave:

# Atualizar a cópia local sem mexer na relação de confiança
gpg --keyserver hkps://keys.openpgp.org \
    --refresh-keys 98BFDB87FCF10076416C1E0BAD997ACC82DD593D

Em hosts isolados (sem acesso a keyserver), distribua a chave por um canal interno controlado — um repositório de configuração, um secret manager, ou um artefato versionado — e importe via arquivo:

gpg --import gitlab-omnibus-signing-key.asc
gpg --fingerprint 98BFDB87FCF10076416C1E0BAD997ACC82DD593D

O passo do --fingerprint não é opcional: ele é o ponto de controle que impede que uma chave adulterada entre na sua cadeia de confiança. Compare caractere por caractere com 98BF DB87 FCF1 0076 416C 1E0B AD99 7ACC 82DD 593D.

Automatizando o refresh no CI

Em vez de depender de atualização manual em cada host, embuta a verificação na pipeline. Um job idempotente garante que qualquer runner ou imagem base esteja com a chave correta antes de instalar ou validar pacotes Omnibus:

verificar_chave_omnibus:
  stage: prepare
  image: debian:stable-slim
  variables:
    OMNIBUS_FPR: "98BFDB87FCF10076416C1E0BAD997ACC82DD593D"
  before_script:
    - apt-get update && apt-get install -y gnupg
  script:
    - gpg --keyserver hkps://keys.openpgp.org --recv-keys "$OMNIBUS_FPR"
    # Falha a pipeline se o fingerprint importado não bater com o esperado
    - gpg --fingerprint "$OMNIBUS_FPR" | grep -q "98BF DB87 FCF1 0076 416C  1E0B AD99 7ACC 82DD 593D"
    # Confirma que a chave não está expirada
    - 'gpg --list-keys --with-colons "$OMNIBUS_FPR" | grep -q "^pub:[^e]"'
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'

A vantagem de tratar o fingerprint como variável e validá-lo no script é que a confiança fica declarada no código, versionada e revisável em merge request — não dependente da memória de quem provisionou o servidor. Rodar esse job em uma pipeline agendada (schedule) também serve como alerta precoce: se a chave expirar ou rotacionar no futuro, o job quebra e você descobre antes do deploy.

Checklist de rollout corporativo

Para propagar a atualização com risco mínimo, trate-a como qualquer mudança de produção — staging primeiro, observabilidade depois:

1. Inventário. Liste todos os pontos que consomem a chave: servidores CI, runners, proxies/caches de pacotes (Artifactory, Nexus, apt-mirror), scanners de segurança e estações de administração.
2. Baseline. Registre, em cada ponto, o fingerprint e a data de expiração atuais para detectar drift após a atualização.
3. Staging. Aplique o refresh primeiro em um ambiente de homologação e rode um ciclo completo de instalação/validação de um pacote Omnibus.
4. Verificação criptográfica. Confirme o fingerprint (gpg --fingerprint) e a nova expiração (2028-02-16) em cada host.
5. Idempotência. Garanta que o script de atualização possa rodar repetidamente sem efeitos colaterais (importar uma chave já presente não deve falhar o deploy).
6. Rollback documentado. Tenha o procedimento de reverter para a cópia anterior caso surja incompatibilidade — guarde a versão antiga da chave antes de sobrescrever.
7. Produção em ondas. Propague por grupos (canary → resto da frota), monitorando falhas de verificação a cada onda.
8. Monitoramento. Configure alertas para erros de verificação de assinatura nos logs de instalação, para resolver regressões rapidamente.

Trade-offs: estender validade vs. rotacionar

Abordagem	Vantagem	Custo operacional
Estender a expiração (caminho atual)	mesmo fingerprint, nenhuma quebra de confiança nos consumidores	exige refresh da cópia local em quem mantém datas defasadas
Rotacionar a chave	reduz janela de exposição se houver comprometimento	obriga todos os consumidores a redistribuir e reconfirmar a nova chave

A escolha do GitLab pela extensão prioriza estabilidade da frota self-managed. O ponto de atenção é não confundir "menos disruptivo" com "nada a fazer": ambientes que validam assinaturas e mantêm cópias estáticas da chave precisam, sim, fazer o refresh.

Contexto de supply-chain

Verificar a assinatura GPG do pacote Omnibus é uma das poucas defesas concretas contra um cenário de cadeia de suprimentos comprometida — um mirror interno envenenado, um cache de artefatos adulterado ou um ataque MITM em um canal sem TLS. A assinatura prova que o pacote saiu do processo de build do GitLab e não foi alterado no caminho. Por isso, a recomendação de longo prazo vai além deste evento pontual:

• Trate a verificação de assinatura como gate obrigatório na pipeline de provisionamento, não como etapa opcional.
• Mantenha o fingerprint esperado declarado em configuração versionada (Ansible, Terraform, ou o .gitlab-ci.yml acima), nunca como conhecimento tácito.
• Lembre-se de que estender a validade não substitui revogação e monitoramento de integridade: continue acompanhando os canais oficiais do GitLab para anúncios de rotação ou comprometimento.
• Combine a verificação criptográfica com checksums e com um inventário de software (SBOM) quando o seu modelo de ameaça exigir.

Impacto e boas práticas B2B

Em ambientes corporativos, a extensão da validade é uma escolha que prioriza estabilidade operacional enquanto mantém controles de segurança. Recomendamos as seguintes práticas alinhadas ao tratamento deste evento:

• Inventariar onde a chave pública atual é consumida (servidores CI, proxies de pacotes, scanners de segurança) e automatizar a atualização por meio de scripts idempotentes.
• Registrar o procedimento de atualização e testar rollback em caso de incompatibilidade.
• Manter monitoramento e alertas sobre falhas de verificação de assinatura após a atualização, para resolver rapidamente regressões.

Se sua organização precisar de apoio técnico para planejar e executar a atualização da chave com mínimo risco, considere um serviço profissional que integre verificação, testes e implantação coordenada.

Fonte oficial e comunicado do GitLab sobre esta extensão: Anúncio do GitLab.

Referência técnica: mantenha versões atualizadas da chave pública e valide assinaturas quando seus controles de segurança exigirem a garantia criptográfica da origem dos pacotes.