L'examen des sources dans le référentiel vous permet d'évaluer le niveau de sécurité des applications. Mais si personne ne regarde le code, les problèmes ne feront que croître. Heureusement, GitHub dispose de ses propres experts en sécurité qui ont récemment découvert le cheval de Troie dans plusieurs dépôts Git. Pour une raison quelconque, il n'a pas été remarqué par les propriétaires de ces dépôts. Bien que nous ne puissions pas dicter à d'autres personnes comment gérer nos propres référentiels, nous pouvons apprendre de leurs erreurs. Dans cet article, nous examinerons des techniques utiles pour travailler avec des référentiels.
Explorez votre référentiel
C'est peut-être la recommandation la plus importante. Que vous ayez créé le référentiel vous-même ou que vous vous l'ayez remis, il est important de connaître le contenu de votre référentiel. Au minimum, vous devez connaître les composants de base de la base de code que vous gérez. Si, après quelques dizaines de fusions, un fichier aléatoire apparaît, vous pouvez facilement le repérer car il soulèvera des questions pour vous. Ensuite, vous voudrez le vérifier pour le comprendre, puis décider de son sort.
Essayez de ne pas ajouter de binaires
Git a été conçu à l'origine pour les fichiers texte, que ce soit du code C, Python ou Java, ou JSON, YAML, XML, Markdown, HTML, etc.
$ 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.Git n'aime pas les binaires:
$ 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:0Les données d'un fichier binaire ne peuvent pas être analysées de la même manière que du texte brut, donc si quelque chose change dans le binaire, il doit être complètement écrasé.
Pour aggraver les choses, vous ne pouvez pas vérifier (lire et analyser) les données binaires vous-même.
En plus des outils POSIX habituels, vous pouvez trouver des binaires en utilisant git diff. Lorsque vous essayez d'exécuter diff avec l'option --numstat, Git retournera null:
$ 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.txtSi vous envisagez d'ajouter des binaires à votre référentiel, arrêtez-vous et réfléchissez. Si un binaire est généré pendant le processus de construction, pourquoi l'ajouter à votre dépôt? Si vous décidez que cela a du sens de le faire, assurez-vous de décrire dans un fichier README ou un endroit similaire pourquoi vous conservez les binaires et quel est le protocole de mise à jour. Les mises à jour doivent être effectuées avec parcimonie, car chaque fois que vous apportez une modification à l'objet blob, l'espace de stockage double.
Les bibliothèques tierces doivent rester tierces
Si l'un des nombreux avantages de l'open source est que vous pouvez librement utiliser et redistribuer du code que vous n'avez pas écrit, il existe de nombreuses bonnes raisons de ne pas héberger une bibliothèque tierce dans votre propre référentiel. Tout d'abord, vous devrez vérifier indépendamment tout ce code et ses mises à jour ultérieures pour vous assurer que la bibliothèque est fiable. Deuxièmement, lorsque vous copiez des bibliothèques tierces dans le référentiel Git, cela détourne le focus du projet principal.
Utilisez Git Submodule pour gérer les dépendances externes .
N'utilisez pas git add aveuglément
Si votre projet a été compilé avec succès, résistez à l'envie d'utiliser la commande git add. (où "." est le répertoire courant par exemple). Ceci est particulièrement important si vous ne compilez pas manuellement votre projet, mais utilisez un IDE pour gérer votre projet. Il peut être extrêmement difficile de garder une trace de ce qui a été ajouté à votre référentiel lorsque l'EDI gère votre projet. Par conséquent, il est important de n'ajouter que ce que vous avez vous-même créé et préparé pour l'ajout, et non un nouvel objet apparaissant mystérieusement dans votre dossier de projet.
Donc, avant d'exécuter git add, vérifiez ce qui sera ajouté au référentiel. Si vous voyez un objet inconnu, découvrez d'où il vient et pourquoi il est toujours dans le répertoire de votre projet après avoir exécuté make clean (ou une commande équivalente).
Utilisez Git ignore
Un répertoire de projet typique contient de nombreux fichiers cachés, métadonnées et artefacts inutiles. Vous feriez mieux d'ignorer ces objets: plus il y en a, plus vous risquez d'être dérangé par cette «poubelle» et vous manquerez quelque chose d'important ou de dangereux.
Le fichier gitignore permet de filtrer les choses inutiles. Github.com/github/gitignore propose plusieurs modèles gitignore personnalisés que vous pouvez télécharger et héberger dans votre projet. Gitlab.com , par exemple, proposait de tels modèles il y a plusieurs années.
Modifications modérées de la base de code
Lorsque vous recevez une Pull ou Pull Request, ou lorsque vous recevez un correctif par e-mail, vous devez vous assurer que tout va bien. Votre travail consiste à étudier le nouveau code entrant dans votre base de code et à comprendre ce qu'il fait. Si vous n'êtes pas d'accord avec sa mise en œuvre, ou pire, si vous ne comprenez pas cette implémentation, écrivez un message à l'expéditeur et demandez des éclaircissements. Il n'y a rien de mal à apprendre un nouveau code qui revendique une place dans votre projet. De plus, vous le faites pour le bénéfice de vos utilisateurs: dans ce cas, ils comprendront clairement les changements que vous acceptez et pourquoi.
Prendre la responsabilité
Assurer la sécurité des logiciels open source est un travail communautaire. Explorez la base de code, découragez l'encombrement et ignorez les menaces de sécurité potentielles dans les référentiels que vous clonez. Git est puissant, mais ce n'est qu'un programme informatique, donc la responsabilité de la gestion des dépôts vous incombe en fin de compte.
La publicité
Les serveurs Epic sont des serveurs virtuels Linux ou Windows dotés de puissants processeurs AMD EPYC et de lecteurs Intel NVMe très rapides. Dispersez-vous comme des petits pains!
