Comment publier un logiciel en open source en toute sécurité
Certains éléments sont essentiels à réaliser avant de rendre votre projet open-source. Voici quelques bonnes pratiques.
La décision de passer un logiciel en open source est souvent intimidante. Vous avez pesé le pour et le contre, vous avez recueilli le soutien de toutes les parties prenantes et vous avez obtenu le feu vert pour ouvrir ce projet qui, selon vous, bénéficierait de la dynamique de l'écosystème et de la communauté open-source.
La seule chose qui reste à faire est de le publier sur une plateforme publique et ce sera terminé, n'est-ce pas ? Peut-être, mais procédons d’abord à quelques vérifications finales.
Voici les quelques éléments essentiels à réaliser avant de rendre votre projet open-source :
- Vérifier que votre dépôt ne contient pas de secrets
- Remplacer les noms et emails internes par des noms publics
- Rédiger les directives de contribution (CONTRIBUTING.md)
- Rédiger un modèle de rapport de bogue et un modèle de pull request.
- Choisir un modèle de licence (LICENSE.md)
- Rédiger la politique de sécurité (SECURITY.md)
- Rédiger l'introduction du projet (README.md)
Vérifier que votre dépôt ne contient pas de secrets
Une des premières choses à faire avant de rendre votre dépôt public est de vérifier qu'il n'y a pas de secrets dans votre historique git. Il est toujours important de se rappeler qu'avec git, ce n'est pas seulement la version actuelle de votre projet que vous rendez publique. Vous rendez également publiques toutes les modifications et itérations que vous avez effectuées.
Les secrets ne doivent jamais être stockés même dans les dépôts internes.
L'idée qu'un dépôt interne est privé et qu'il est protégé par une authentification vous donne un faux sentiment de sécurité. Si un dépôt contient des secrets et qu’il est compromis (par l’obtention de clés d’accès par exemple), il donne alors accès à un périmètre interne plus important et généralement à des zones plus sensibles du périmètre (consultez cette vidéo sur la violation des données de l'ONU pour plus d'informations sur ce type d'infiltration).
Si vous utilisez un outil de détection de secrets, vous pouvez facilement analyser l'historique complet de votre dépôt à la demande.
Mais peut-être souhaitez-vous analyser une branche locale avec quelques réécritures de l'historique git avant de la pousser. Pour cela, vous pouvez utiliser GG Shield, qui vous permet d'analyser différents types de données à la demande en utilisant son API publique.
Un secret peut être caché profondément dans l'historique du dépôt, si c’est le cas voici un mode d’emploi sur la suppression des secrets de l'historique git.
Remplacer les noms et emails internes par des noms publics
Bien qu'il ne s'agisse pas d'un problème de sécurité (à moins que la sécurité par l'obscurité soit considérée comme de la sécurité), vous pourriez vouloir remplacer certaines informations dans l'historique de votre dépôt par des informations plus à jour afin de ne pas confondre les futurs contributeurs ou de les relier au bon auteur. Ces informations peuvent être par exemple :
- Des emails internes utilisés dans le développement qui ne correspondent pas aux adresses email publiques des auteurs sur la plateforme d'hébergement publique (GitHub, GitLab).
- Des noms de produits internes qui ne correspondent pas aux noms publics.
- Censure des domaines internes utilisés dans les tests
- Remplacement des emails de robots internes par des emails de développeurs en charge du projet
Lister les emails utilisés dans le référentiel
En utilisant git shortlog nous sommes en mesure de vérifier tous les emails des auteurs présents dans notre branche, si nous voulons vérifier les emails des committers nous pouvons ajouter l'option --committer à la commande.
Dans cet exemple, nous vérifions que jorge.lampos@gitguardian.com est l'auteur de 4 commits, mais nous savons que l'email de cet utilisateur sur GitHub, la plateforme où nous voulons opensourcer notre dépôt, est jlampos@gg.com.
Filtrer un email dans l'historique git
Cette commande remplace l'email de l'auteur et du committer dans votre branche s'il correspond à la variable OLD_EMAIL avec la variable NEW_EMAIL.
Attention : Elle supprime également l’éventuelle signature de tout commit affecté.
Pousser votre dépôt en privé
Une fois que toute la réécriture de l'historique git est faite (le moins possible, c’est le mieux), nous devons trouver un nouvel emplacement pour votre dépôt. Il existe de nombreuses solutions d'hébergement pour votre dépôt en open-source, comme github.com, gitlab.com et bitbucket.org. Si vous utilisez déjà GitHub Enterprise ou une instance GitLab auto-hébergée, vous pouvez choisir la version cloud de ces solutions pour éviter de passer du temps à vous familiariser avec une nouvelle plateforme.
Pour notre exemple, nous utiliserons github.com.
Une fois votre dépôt nu créé, vous pourrez y pousser un dépôt existant. GitHub nous aide même à le faire.
La prochaine étape est de vous assurer que certains fichiers existent à la racine de votre dépôt.
Rédiger vos directives de contribution (CONTRIBUTING.md)
Votre contributing.md est le point d'entrée pour les développeurs qui souhaitent participer à votre projet. Il ne doit pas être trop détaillé mais répondre à quelques questions clés du point de vue du développeur :
- Quel est le workflow de développement ?
- Dois-je créer une “issue” pour une fonctionnalité ou une correction de bogue et en discuter avec les contributeurs existants ?
- Dois-je simplement présenter une merge request avec mes modifications ?
- Mes modifications doivent-elles être accompagnées d'une documentation ?
- Quels sont les liens que je devrais connaître ? (documentation, bug tracker, roadmap)
- Comment puis-je entrer en contact avec l'équipe de développement ?
- Quelles sont les conventions de code ?
- Ce référentiel suit-il un certain style de code ?
- Ce référentiel suit-il un certain modèle de messages de validation ?
- Comment puis-je configurer l'environnement de développement pour ce projet ?
Quelques exemples de directives de contribution peuvent être trouvés ici :
Rédiger un modèle de rapport de bogue et un modèle de pull request
Il est utile d'écrire ces deux modèles de base afin de rationaliser les contributions à votre projet. GitHub et GitLab ont tous deux un support spécifique pour intégrer des modèles dans leur interface.
Voici quelques questions de base que votre modèle de rapport de bogue devrait poser à la personne qui signale le bogue :
- Sur quelle version du projet a-t-il été trouvé ?
- Peut-il être reproduit dans la version nightly/développement du projet ?
- Comment décririez-vous le bogue ?
- Quelles sont les étapes de reproduction de ce bogue ?
- Quel est le comportement attendu de cette fonctionnalité ?
Quelques questions de base pour votre modèle de pull request :
- Où cette modification a-t-elle été discutée ?
- Quelle est la fonctionnalité ou le domaine du projet concerné par cette demande de modification ?
- Quels sont les problèmes que le reviewer doit connaître ?
Incluez également une liste de contrôle qu'un contributeur peut cocher pour les étapes nécessaires à l'acceptation de la pull request (style de code respecté, documentation ajoutée, correspond à ce qui a été discuté).
BONUS : Rédigez également un modèle de demande de fonctionnalité.
Choisir votre licence (LICENSE.md)
La LICENSE est un élément central d'un projet open-source. Vous pouvez utiliser https://choosealicense.com/ pour vous aider dans ce choix. Chaque licence de logiciel open source possède son propre ensemble de limitations, de conditions et de permissions. Les licences abordent des questions telles que :
- Quel type de reconnaissance est accordé au créateur du code ?
- Quelles autorisations sont accordées aux utilisateurs du projet ?
- Comment le code source doit-il être distribué et mis à la disposition des autres développeurs ?
- Existe-t-il des conditions dans lesquelles les utilisateurs ne sont pas tenus de distribuer le code source ?
- Dans quelles conditions les utilisateurs peuvent-ils distribuer leur logiciel à des fins commerciales ?
Veillez à ce que la licence que vous avez choisie n'entre pas en conflit avec l'une des dépendances de votre projet. En général, les licences de logiciels open-source se divisent en deux grands types : les licences permissives et les licences copyleft. Les licences permissives sont presque toujours compatibles entre elles, alors que les licences copyleft ne le sont souvent pas.
Rédiger votre politique de sécurité (SECURITY.md)
La politique de sécurité de votre dépôt est destinée aux spécialistes de la sécurité et à tout contributeur ayant trouvé une vulnérabilité de sécurité sur votre projet.
Elle devrait contenir au minimum un point de contact pour une divulgation responsable des vulnérabilités, et si possible une description du processus suivi par l'équipe une fois la vulnérabilité reconnue.
C'est également un bon endroit pour signaler tout programme de bugs bounty existant lié au projet.
Rédiger l'introduction de votre projet (README.md)
Ce fichier est destiné à l'utilisateur final de votre projet et doit être une présentation du projet. Il doit répondre aux questions suivantes :
- Que fait le projet ?
- Comment puis-je l'installer ?
- Quelles sont les questions fréquemment posées sur son utilisation ?
- Où puis-je trouver des informations plus détaillées sur le projet ?
Vous devriez également profiter de l'occasion pour créer un lien vers votre politique de sécurité, votre licence et vos directives de contribution, car votre README.md sert d'index au référentiel.
Que faire ensuite ?
Dans cet article, nous avons couvert quelques tâches essentielles à faire avant d'ouvrir votre projet interne. Elles représentent un bon point de départ afin que votre dépôt reçoive des contributions.