A forma mais segura de garantir que a pessoa que fez o commit é realmente quem ela diz ser é por meio dos commits assinados, garantindo a segurança de projetos. Durante este artigo, vamos ver as melhoras práticas para trabalhar com commits assinados e proteção de branches.
[adrotate banner=”4″]
Como funcionam os commits assinados?
Existem duas chaves: uma pública e outra privada. Todas as vezes que um commit for criado, serão checadas ambas as chaves e, se tudo tiver certo, o commit é realizado.
Para gerar as chaves, vamos utilizar o GPG. Assim, vamos demonstrar como utilizá-lo no Windows. Entretanto, o método é muito semelhante para o Linux.
GNU Privacy Guard (GnuPG ou GPG) é um software livre, que utiliza de criptografia híbrida, sendo ela composta de criptografia de chave simétrica e criptografia de chave pública. Dessa forma, garante velocidade e facilidade na troca segura de chaves. O GPG pode ser utilizado para transportar e-mails e arquivos de forma segura, mas neste artigo vamos focar seu uso para geração de chaves para commits assinados.
Para acessar o link de download do GPG para Windows, clique aqui.
Passo a passo para criação do commit
O primeiro passo é instalar o GPG na sua máquina. Uma dica: não é necessário realizar uma doação para utilizar o sistema, você pode selecionar a opção de doar $0.
Após a instalação, vamos abrir o terminal e rodar o comando gpg –list-secret-key –keyid-form LONG para mostrar as chaves já criadas. Agora, iremos criar nossa primeira chave, usando o comando gpg –full-generate-key.
Nesse campo, iremos selecionar o tipo da chave que será gerada (no exemplo, foi escolhida a primeira opção).
Depois iremos escolher a quantidade de bits que a chave gerada irá possuir.
Agora iremos escolher a duração da chave. Isto é, ela pode ter duração de dias, semanas, meses, anos ou não ter duração (dependendo da necessidade do usuário).
Após a escolha da duração da chave, será impresso no console a data de expiração da chave e o sistema irá solicitar uma confirmação.
Neste momento, iremos inserir um nome para identificar a chave. A dica é: utilize o mesmo nome do seu github.
Insira o e-mail que será utilizado, use o mesmo e-mail do github (é possível adicionar outros e-mails posteriormente).
Podemos também inserir um comentário, mas não é necessário.
Confirmação
Neste momento pode ser alterado os campos de nome, comentário, e-mail, salvar ou sair.
Depois da confirmação, é solicitada a criação de uma senha para acessar a chave.
Após a criação da senha, a chave é impressa na tela.
Rodando novamente o comando gpg –list-secret-key –keyid-form LONG temos a nova chave gerada.
Com a chave gerada, iremos usar o comando gpg –armor –export ID. O id é a parte em vermelho na imagem acima. Esse comando retorna o endereço da chave pública (como demonstrado na imagem abaixo).
O próximo passo é acessar seu github e ir nas configurações, selecionar SSH and GPG keys e adicionar uma nova chave GPG, colar todo o bloco gerado pelo comando anterior e adicionar a chave.
Com a chave no github, é possível comparar ela com a assinatura dos futuros commits. Se elas forem similares, seu commit será considerado verificado.
Verificação
Utilizaremos o comando git config –global user.sigingkey ID para escolher a chave padrão nas assinaturas e o comando git config gpg.program “C:\Program Files (x86)\GnuPG\bin\gpg.exe” para assinar os commits de um único repositório ou utilizar o comando git config –global gpg.program “C:\Program Files (x86)\GnuPG\bin\gpg.exe” para todos repositórios.
Lembrando que o caminho pode variar dependendo da instalação. O caminho utilizado acima é o padrão.
Por fim, utilize o comando git config –global commit.gpgsign true. A partir desse momento, seu commit pedirá a senha criada anteriormente. Utilizando o comando git log –show-signature, será exibido que o commit foi realizado assinado com sucesso.
Caso ocorra algum erro, verifique se está tudo de acordo no .gitconfig do seu usuário, ele deveria conter as seguintes linhas:
Após subir as modificações para o github, podemos ver que o commit estará verificado.
Proteção de branches e boas práticas
Durante o desenvolvimento de um projeto, erros podem acontecer. Isso pode causar uma enorme dor de cabeça e muito retrabalho.
Entretanto, não podemos impedir todos os erros de acontecerem, mas podemos reduzir sua quantidade. Um exemplo disso é trocar a branche padrão do projeto para a branche de desenvolvimento, para garantir que nada vai direto para a master.
Podemos ainda adicionar novas regras para as branches. Por exemplo, exigir que todos os commits criados sejam assinados ou exigir uma pull request antes de subir qualquer alteração no projeto, entre outras regras que podemos utilizar para tornar o desenvolvimento do projeto seguro e tranquilo.
Veja também:
Diferença entre compilação e interpretação
Autor: Luiz Sergio Alves Rodrigues
[adrotate banner=”5″]
