Comme a son habitude, GitHub a annoncé quelques petites améliorations ces derniers jours. L'une d'entre est concerne son système de recherche qui a été entièrement revu afin d'être plus complet et plus efficace... un peu trop même puisque l'on trouve parfois des fichiers qui n'ont rien à faire dans un dépôt public.
GitHub continue de s'améliorer. Ainsi, depuis le début du mois, on a vu apparaître une nouvelle section au sein des profils utilisateurs : les contributions. Celle-ci permet de voir si vous êtes actifs ou non sur différents projets via une liste des plus populaires ou des plus récents auxquels vous avez participé, mais aussi une représentation graphique de votre activité de l'année passée :
Il est aussi possible de supprimer et de créer des branches depuis l'interface en ligne, restaurer une branche qui aurait été supprimée après la fermeture d'une Pull request, d'afficher et de trier la liste de ces dernières, de créer des listes de tâches à effectuer sous forme de cases à cocher dans vos textes via le Markdown maison, mais aussi de fermer un bug via un simple message lors d'un commit.
Mais c'est le changement le plus récent qui met en lumière l'innocence de certains développeurs : le nouveau moteur de recherche. Celui-ci exploite Elasticsearch et dispose d'un design plus simple, ainsi que d'un nouveau mode avancé. Il permet de chercher des morceaux de code spécifiques, des noms de dépôts, des utilisateurs, mais aussi des fichiers par taille, par dossier, par extension...
Les requêtes que l'on peut effectuer sont nombreuses et certaines font déjà jaser :
- Fichiers id_rsa contenant le mot Private
- Fichiers Key contenant le mot Private
- Fichiers PEM contenant le mot Private
- Fichiers PGP contenant le mot Private
Dans ces quatre exemples, on peut en effet trouver dans la liste des réponses des clefs privées que certains développeurs ont cru bon de placer dans un dépôt public. Pour rappel (voir notre dossier dédié à MEGA), dans le cadre du chiffrement asymétrique, une clef privée est confidentielle puisqu'elle permet de lire un message chiffré avec votre clef publique (un tiers vous envoyant un message) mais aussi de signer un message pour vous identifier comme l'auteur. Autant dire que la divulgation d'un tel élément peut avoir des conséquences assez graves.
Le moteur de recherche de GitHub n'est bien entendu en rien responsable, puisqu'il ne fait que mettre en lumière les erreurs de certains membres du service. Espérons que ceux qui sont concernés réagiront promptement.
Commentaires (15)
#1
met en lumière l’innocence de certains développeurs
Comme je suis pas développeur et que j’y comprend de toute façon pas grand chose, c’est ce que je retiendrai de l’article.
Quand on donne à tous les clés servant à protéger un lieu, on mérite de se faire cambrioler (à mon avis).
#2
Dépôt public vs. infos privées
" />
#3
Foutre une clé privée RSA sur un dépôt public… faut être vraiment tête en l’air !
" />
#4
#5
On voit que certains développeurs ont tout compris au chiffrement asymétrique. Je ne veux même pas savoir à quel point leurs applications doivent être sécurisées…
#6
#7
Et les databases.yml des projets symfony ? :)
Pas mal aussi, faut filtrer les résultats, mais ça peut occasionner certains résultats intéressants :)
#8
euh sinon personne utilise bitbucket car c’est vraiment bien, on a des dépôts privés illimités !!
#9
#10
Dans la majorité des cas, il y a “test”/‘sample”/“helloworld” dans le nom du dépot ou de la clé. Il ne faut pas non plus confondre quelqu’un qui commit sa propre clé privée avec quelqu’un qui fait une lib avec du chiffrage et qui envoie un exemple.
#11
#12
#13
#14
#15