Você pode assinar commits e tags localmente para dar a outras pessoas confiança sobre a origem de uma alteração que você fez. Se uma confirmação ou uma tag tiver uma assinatura GPG, SSH ou S/MIME que possa ser verificada criptograficamente, o marcará o commit ou a tag como "Verified."
Se um commit ou uma tag tiver uma assinatura que não possa ser verificada, o marcará a confirmação ou a marca como "Unverified".
Para a maioria dos usuários individuais, a melhor opção para assinar commits é GPG ou SSH. As assinaturas S/MIME geralmente são necessárias no contexto de uma organização maior. As assinaturas SSH são as mais simples de serem geradas. Você pode até mesmo carregar sua chave de autenticação existente no para também usar como uma chave de assinatura. A geração de uma chave de assinatura GPG está mais envolvida do que a geração de uma chave SSH, mas a GPG conta com recursos que a SSH não tem. Uma chave GPG pode expirar ou ser revogada quando não for mais usada. A assinatura do GPG pode incluir informações sobre ele ter expirado ou ter sido revogado.
Independentemente da opção de assinatura – GPG, SSH ou S/MIME –, uma vez que uma assinatura de commit é verificada, ela permanece verificada na rede de seu repositório. Confira Entender conexões entre repositórios.
Quando uma assinatura de confirmação é verificada ao ser enviada por push para o , um registro de verificação é armazenado junto com o commit. Esse registro não pode ser editado e persistirá para que as assinaturas permaneçam verificadas ao longo do tempo, mesmo se as chaves de assinatura forem giradas, revogadas ou se os colaboradores deixarem a organização.
O registro de verificação inclui uma marcação de carimbo de data/hora de quando a verificação foi concluída. Esse registro persistente garante um estado verificado consistente, fornecendo um histórico estável de contribuições dentro do repositório. Você pode exibir esse carimbo de data/hora passando o mouse sobre o selo "Verified" no ou acessando o commit por meio da API REST, que inclui um campo verified_at. Confira Pontos de extremidade da API REST para commits.
A verificação de assinatura de commit persistente aplica-se a novos commits enviados por push para o . Para quaisquer commits que antecedem esse recurso, um registro persistente será criado na próxima vez que a assinatura do commit for verificada no , ajudando a garantir que os status verificados permaneçam estáveis e confiáveis no histórico do repositório.
Para obter informações sobre como desabilitar a verificação de assinatura de commit persistente, consulte Desabilitando a verificação de commit persistente.
A verificação de assinatura de commit persistente reflete o estado verificado de uma confirmação no momento da verificação. Isso significa que, se uma chave de assinatura for revogada, expirada ou alterada de outra forma, os commits verificados anteriormente manterão seu status verificado com base no registro criado durante a verificação inicial. O não verificará novamente commits assinados anteriormente nem ajustará retroativamente seu status de verificação em resposta a alterações no estado da chave. As organizações podem precisar gerenciar estados de chaves diretamente para se alinharem às suas políticas de segurança, especialmente se a rotação ou revogação de chaves frequentes for planejada.
O registro de verificação é persistente na rede do repositório, o que significa que, se o mesmo commit for enviado novamente para o mesmo repositório ou para qualquer uma de suas bifurcações, o registro de verificação existente será reutilizado. Isso permite que o mantenha um status verificado consistente entre repositórios relacionados sem verificar novamente o commit sempre que ele aparece na rede. Essa persistência reforça uma exibição unificada e confiável da autenticidade do commit em todas as instâncias do commit dentro da rede do repositório.
Ao usar a opção Trocar base e Mesclar em uma solicitação de pull, é importante observar que os commits no branch principal são adicionados ao branch base sem verificação de assinatura de commit. Quando você usa essa opção, o cria um commit modificado usando os dados e o conteúdo do commit original. Isso significa que o não criou de fato esse commit e, portanto, não pode assiná-lo como um usuário genérico do sistema. O não tem acesso às chaves de assinatura privadas do responsável pelo commit, portanto, não pode assinar o commit em nome do usuário.
Uma solução alternativa é trocar a base e fazer a mesclagem localmente e depois enviar as alterações por push ao branch base da solicitação de pull.
Para saber mais, confira Sobre métodos de merge no .
Os administradores do repositório podem impor a assinatura de commit obrigatória em um branch para bloquear todos os commits que não estejam assinados e verificados. Para saber mais, confira Sobre branches protegidos.
Você pode conferir o status de verificação de seus commits ou tags assinados no e ver por que as assinaturas de commit podem não ter sido verificadas. Para saber mais, confira Confirmar o status de verificação da assinatura do commit e da tag.
Se um administrador do site tiver habilitado a assinatura de commit da Web, o usará automaticamente o GPG para assinar os commits que você fizer usando a interface da Web. Os commits assinados pelo terão um status verificado. Você pode verificar a assinatura localmente usando a chave pública disponível em https://HOSTNAME/web-flow.gpg. Para saber mais, confira Configurar a assinatura de commit da Web.
É possível usar GPG para assinar commits com uma chave GPG que você mesmo gera.
O usa bibliotecas OpenPGP para confirmar que seus commits e suas marcas assinados localmente são criptograficamente verificáveis em relação a uma chave pública que você adicionou à sua conta em sua instância do Enterprise Server.
Para assinar commits usando GPG e para que esses commits sejam verificados no , siga estas etapas:
- Verificar se há chaves GPG existentes
- Gerar uma nova chave GPG
- Adicionar uma chave GPG à conta do
- Informar o Git sobre a chave de assinatura
- Assinar commits
- Assinar tags
É possível usar SSH para assinar commits com uma chave SSH que você mesmo gerou. Para saber mais, confira a documentação de referência do Git com relação a user.Signingkey. Se você já usa uma chave SSH para autenticar com o , também pode carregar essa mesma chave novamente para uso como uma chave de assinatura. Não há limite quanto ao número de chaves de assinatura que você pode adicionar à sua conta.
O usa ssh_data, uma biblioteca Ruby de código aberto, para confirmar que seus commits e suas marcas assinados localmente são criptograficamente verificáveis em relação a uma chave pública que você adicionou à sua conta em sua instância do Enterprise Server.
Observação
A verificação de assinatura SSH está disponível no Git 2.34 ou posterior. Para atualizar sua versão do Git, acesse o site do Git.
Para assinar commits usando SSH e para que esses commits sejam verificados no , siga estas etapas:
- Verifique se há chaves SSH existentes
- Gere uma nova chave SSH
- Adicionar uma chave de assinatura SSH à sua conta do
- Informar o Git sobre a chave de assinatura
- Assinar commits
- Assinar tags
Você pode usar S/MIME para assinar commits com uma chave X.509 emitida pela organização.
O usa o pacote ca-certificates do Debian, o mesmo repositório confiável usado pelos navegadores Mozilla, para confirmar que as tags e os commits assinados localmente são criptograficamente verificáveis em relação a uma chave pública em um certificado raiz confiável.
Observação
A verificação de assinatura S/MIME está disponível no Git 2.19 ou posterior. Para atualizar sua versão do Git, acesse o site do Git.
Para assinar commits usando S/MIME e para que esses commits sejam verificados no , siga estas etapas:
Não é preciso fazer upload da chave pública no .