Examinar as fontes no repositório permite avaliar o nível de segurança dos aplicativos. Mas se ninguém estiver olhando para o código, os problemas só crescerão. Felizmente, o GitHub tem seus próprios especialistas em segurança que descobriram recentemente o Trojan em vários repositórios do Git. Por alguma razão, ele não foi notado pelos proprietários desses repositórios. Embora não possamos ditar para outras pessoas como gerenciar nossos próprios repositórios, podemos aprender com seus erros. Neste artigo, veremos técnicas úteis para trabalhar com repositórios.
Explore seu repositório
Esta é talvez a recomendação mais importante. Se você criou o repositório você mesmo ou o entregou, é importante conhecer o conteúdo do seu repositório. No mínimo, você precisa conhecer os componentes básicos da base de código que você gerencia. Se, após algumas dúzias de mesclagens, um arquivo aleatório aparecer, você poderá identificá-lo facilmente, pois ele fará perguntas para você. Em seguida, você vai querer dar uma olhada para descobrir e depois decidir o seu destino.
Tente não adicionar binários
O Git foi projetado originalmente para arquivos de texto, seja código C, Python ou Java, ou JSON, YAML, XML, Markdown, HTML e assim por diante:
$ cat hello.txt
This is plain text.
It's readable by humans and machines alike.
Git knows how to version this.
$ git diff hello.txt
diff --git a/hello.txt b/hello.txt
index f227cc3..0d85b44 100644
--- a/hello.txt
+++ b/hello.txt
@@ -1,2 +1,3 @@
This is plain text.
+It's readable by humans and machines alike.
Git knows how to version this.O Git não gosta de binários:
$ git diff pixel.png
diff --git a/pixel.png b/pixel.png
index 563235a..7aab7bc 100644
Binary files a/pixel.png and b/pixel.png differ
$ cat pixel.png
PNG
▒
IHDR7n $gAMA
abKGD݊ tIME
-2R
IDA c` ! 3%tEXtdate:create2020-06-11T11:45:04+12:00 r.%tEXtdate:modify2020-06-11T11:45:0Os dados em um arquivo binário não podem ser analisados da mesma maneira que o texto sem formatação; portanto, se algo mudar no binário, ele deverá ser completamente substituído.
Para piorar a situação, você não pode verificar (ler e analisar) os dados binários sozinho.
Além das ferramentas POSIX usuais, você pode encontrar binários usando o git diff. Quando você tenta executar o diff com a opção --numstat, o Git retornará nulo:
$ git diff --numstat /dev/null pixel.png | tee
- - /dev/null => pixel.png
$ git diff --numstat /dev/null file.txt | tee
5788 0 /dev/null => list.txtSe você está pensando em adicionar binários ao seu repositório, pare e pense. Se um binário é gerado durante o processo de compilação, por que adicioná-lo ao seu repositório? Se você decidir que faz sentido fazer isso, descreva em um arquivo LEIA-ME ou em um local semelhante por que mantém os binários e qual é o protocolo para atualizá-los. As atualizações devem ser feitas com moderação, pois toda vez que você faz uma alteração no blob, o espaço de armazenamento dobra.
Bibliotecas de terceiros devem permanecer como terceiros
Embora um dos muitos benefícios do código aberto seja o fato de poder usar e redistribuir livremente o código que não foi gravado, existem muitas boas razões para não hospedar uma biblioteca de terceiros em seu próprio repositório. Primeiro, você precisará verificar independentemente todo esse código e suas atualizações adicionais para garantir que a biblioteca seja confiável. Segundo, quando você copia bibliotecas de terceiros no repositório Git, ele muda o foco do projeto principal.
Use o Submodule Git para gerenciar dependências externas .
Não use o git add às cegas
Se o seu projeto foi compilado com êxito, resista à necessidade de usar o comando git add. (onde "." é o diretório atual, por exemplo). Isso é especialmente importante se você não estiver compilando manualmente seu projeto, mas usando um IDE para gerenciá-lo. Pode ser extremamente difícil acompanhar o que foi adicionado ao seu repositório quando o IDE gerencia seu projeto. Portanto, é importante adicionar apenas o que você mesmo criou e preparou para adicionar, e não qualquer novo objeto que apareceu misteriosamente na pasta do projeto.
Portanto, antes de executar o git add, revise o que será adicionado ao repositório. Se você vir um objeto desconhecido, descubra de onde ele veio e por que ele ainda está no diretório do projeto depois de executar o make clean (ou um comando equivalente).
Use o Git ignorar
Um diretório de projeto típico contém muitos arquivos ocultos, metadados e artefatos desnecessários. É melhor ignorar esses objetos: quanto mais houver, maior será a probabilidade de você ser perturbado por esse "lixo" e perderá algo importante ou perigoso.
O arquivo gitignore torna possível filtrar coisas desnecessárias. O Github.com/github/gitignore oferece vários modelos personalizados de gitignore que você pode baixar e hospedar em seu projeto. O Gitlab.com , por exemplo, ofereceu esses modelos há vários anos.
Alterações moderadas na base de código
Ao receber uma solicitação Pull ou Pull, ou quando você recebe um patch por email, verifique se está tudo bem. Seu trabalho é estudar o novo código que entra na sua base de código e entender o que ele faz. Se você não concorda com sua implementação, ou pior, não entende essa implementação, escreva uma mensagem ao remetente e peça esclarecimentos. Não há nada errado em aprender um novo código que reivindique um lugar no seu projeto. Além disso, você faz isso para o benefício de seus usuários: nesse caso, eles entenderão claramente quais mudanças você está aceitando e por quê.
Tomar responsabilidade
Manter o software de código aberto seguro é um trabalho da comunidade. Explore a base de código, desencoraje a confusão e ignore as ameaças potenciais à segurança nos repositórios que você clona. O Git é poderoso, mas é apenas um programa de computador; portanto, a responsabilidade pelo gerenciamento dos repositórios é sua.
Como anúncio
Os servidores épicos são servidores virtuais Linux ou Windows com processadores AMD EPYC poderosos e unidades Intel NVMe muito rápidas. Dispersar como bolos quentes!
