This document is for CakePHP's development version, which can be significantly different from previous releases.
You may want to read current stable release documentation instead.

Page Contents

Tickets

Avoir des retours et de l’aide de la communauté sous forme de tickets est une partie extrêmement importante dans le processus de développement de CakePHP. Tous les tickets CakePHP sont hébergés sur Github.

Rapporter des bugs

Bien écrits, les rapports de bug sont très utiles. Il y a quelques étapes pour faire le meilleur rapport de bug possible:

  • A Faire Merci de faire des recherches pour un ticket similaire éventuellement existant, et s’assurer que personne n’a déjà reporté le bug ou qu’il n’a pas déjà été résolu dans le répertoire.

  • A Faire Merci d’inclure des instructions détaillées sur la manière de reproduire le bug. Cela peut être sous la forme de cas de Test ou un bout de code démontrant le problème. Ne pas avoir une possibilité de reproduire le problème, signifie qu’il est moins facile de le régler.

  • A Faire Merci de donner autant de détails que possible sur votre environnement: (OS, version de PHP, Version de CakePHP).

  • A ne pas Faire: Merci de ne pas utiliser un ticket système pour poser une question de support technique. Le canal IRC #cakephp sur Freenode a plusieurs développeurs prêts à répondre à vos questions. Les autres possibilités sont le Groupe Google de CakePHP et le déjà populaire Stack Overflow.

Rapporter des problèmes de sécurité

Si vous avez trouvé un problème de sécurité dans CakePHP, merci de bien vouloir utiliser la procédure suivante, plutôt que le système de rapport de bug classique. Au lieu d’utiliser le tracker de bug, la mailing-liste ou le canal IRC, merci d’envoyer un email à security [at] cakephp.org. Les emails envoyés à cette adresse vont à l’équipe qui construit le cœur de CakePHP via une mailing-liste privée.

Pour chaque rapport, nous essayons d’abord de confirmer la vulnérabilité. Une fois confirmée, l’équipe du cœur de CakePHP va entreprendre les actions suivantes:

  • La reconnaissance faite au rapporteur que nous avons reçu son problème, et que nous travaillons à sa réparation. Nous demandons au rapporteur de garder le problème confidentiel jusqu’à ce que nous l’annoncions.

  • Obtenir une préparation d’un fix/patch.

  • Préparer un message décrivant la vulnérabilité, et sa possible exploitation.

  • Sortir de nouvelles versions de toutes les versions affectées.

  • Montrer de façon évidente le problème dans la publication de l’annonce.