Précautions et bonnes pratiques pour mettre open source un projet Ruby on Rails

Hello,

Quelles sont les précautions à prendre avant de mettre un projet Rails open source ?
Quelles sont les bonnes pratiques pour la gestion des clés, mots de passe, database.yml… ? Avez-vous une checklist pour ne rien oublier ?

Merci !

Salut, tu peux regarder comment ont procédé les projets rails open source listés sur Open Source Rails.

2 « J'aime »

Je ne suis pas sûr qu’il y ait de méthode générale : selon la manière dont tu as écrit ton code jusque-là, l’open-sourcer a peut-être déjà été pris en compte ou à l’inverse peut s’avérer être un cauchemar !

Je dirais de faire la liste de tous les services externes que tu utilises et d’aller vérifier comment tu t’y authentifies.

Mais plus important encore, je dirais de supprimer ton historique git (rm -rf .git puis git init, il y a peut-être un manière plus propre de faire) pour définir le t0 de ton projet open source avec ton code dans l’état actuel.
Autrement, tout ton historique devient accessible et les clés qui y étaient stockées aussi.

Ex qui est arrivé à un de mes élèves du wagon : son access key AWS trainait dans ton historique de commits, des hackers l’ont interceptée, et ont créé pour 20 000€ d’instances EC2. Il a pu contester et se faire rembourser, mais sur le coup, c’est la panique donc on évite !

2 « J'aime »

J’utilise systématiquement la gem figaro, projet open source ou pas. Les fichiers sensibles (database.yml, secrets.yml) utilisent déjà des variables d’environnement pour les données sensibles. Aws et Mandrill sont deux services qui se feront systématiquement attaquer si les clés fuitent.

Mieux vaut y penser au début pour ne jamais introduire de clé dans le repository, car un énorme commit initial rebutera les premiers contributeurs qui n’auront pas d’accès facile aux diffs de tes features pour comprendre l’application.

Et pour corriger un repository :
https://help.github.com/articles/remove-sensitive-data/

3 « J'aime »
Human Coders - Le centre de formation recommandé par les développeur·se·s pour les développeur·se·s