Bidouilleux d'Web - Mot-clé - CorrectifLe blog technique de la communauté Mozilla francophone2022-02-04T14:07:43+01:00Communauté Mozilla francophoneurn:md5:935a9b6df47b29d6dc8c2ca47296b179DotclearDétails techniques sur la panne des modules complémentaires de Firefoxurn:md5:792560e8e1288351b86614afaf2e346b2019-05-10T18:52:00+02:002019-05-11T16:08:31+02:00sphinxGénéralCorrectifFirefoxHacksmodules complémentairesMozilla<p><em>Cet article est une traduction de</em> <a href="https://hacks.mozilla.org/2019/05/technical-details-on-the-recent-firefox-add-on-outage/">Technical Details on the Recent Firefox Add-on Outage</a>, <em>écrit par Eric Rescorla, directeur technique de l’équipe de Firefox. Pour un aperçu moins technique, vous pouvez lire <a href="https://blog.mozfr.org/post/2019/05/Ce-que-nous-faisons-quand-les-choses-tournent-mal" title="Ce que nous faisons quand les choses tournent mal (10 mai 2019) Communauté Mozilla francophone">cet article</a>. Merci à Vincent pour la relecture !</em></p>
<hr />
<p>Il y a quelques jours, Firefox a rencontré un problème empêchant la plupart des modules complémentaires de fonctionner. Nous avons commis une erreur en laissant expirer un des certificats utilisés pour la signature des modules. Cela a eu pour effet de désactiver une majeure partie des modules. Maintenant que ce problème a été corrigé pour la plupart des utilisateurs et que la plupart des modules sont revenus à la normale, nous souhaitions revenir sur les détails de ce problème, les raisons de son origine et la façon dont nous l’avons résolu.</p>
<h2>Un peu de contexte : les modules complémentaires et leur signature</h2>
<p>Bien que de nombreuses personnes utilisent Firefox tel quel, il est également possible d’étendre ses fonctionnalités grâce à des « modules complémentaires » (aussi appelées <em>add-ons</em> ou extensions). Les modules permettent ainsi aux utilisateurs d’ajouter des fonctionnalités tierces qui complètent les fonctionnalités par défaut. Il existe aujourd’hui plus de 15 000 modules pour Firefox qui permettent par exemple de <a href="https://addons.mozilla.org/firefox/addon/ublock-origin/" title="Extension uBlock Origin">bloquer des publicités</a> ou de <a href="https://addons.mozilla.org/firefox/addon/tree-style-tab/" title="Extension Tree Style Tab">gérer des centaines d’onglets</a>.</p>
<p>Pour qu’un module puisse être installé dans Firefox, il faut qu’il soit <a href="https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/">signé numériquement</a>. Cette condition fait partie des mesures visant à protéger les utilisateurs de modules malveillants et implique au moins une revue de certains standards dans le module par l’équipe Mozilla. Cette mesure a été introduite en 2015 après avoir rencontré de <a href="https://blog.mozilla.org/addons/2015/04/15/the-case-for-extension-signing/">graves problèmes</a> avec des modules malveillants.</p>
<p>Pour signer numériquement un module, Firefox est configuré avec un « certificat racine » préinstallé. Cette racine est stockée hors ligne dans une <a href="https://fr.wikipedia.org/wiki/Hardware_Security_Module">boîte noire transactionnelle</a> (ou <em>hardware security module</em> en anglais, abrégé en HSM). Toutes les quelques années, ce certificat racine est utilisé afin de signer un nouveau « certificat intermédiaire » qui est conservé en ligne et utilisé dans le processus de signature. Lorsqu’un module est envoyé pour être signé, nous générons un nouveau certificat temporaire : le certificat d’entité final et nous le signons avec le certificat intermédiaire. C’est ce certificat d’entité final qui est utilisé afin de signer le module.</p>
<p>Voici un schéma qui illustre ce fonctionnement :</p>
<p><a href="https://tech.mozfr.org/dotclear/public/bidouilleux/armagaddon2/Add-on-blog-post-visual-May-7-2019_fr.png" title="Illustration des liens de signatures entre les certificats et les modules"><img src="https://tech.mozfr.org/dotclear/public/bidouilleux/armagaddon2/.Add-on-blog-post-visual-May-7-2019_fr_m.png" alt="Illustration des liens de signatures entre les certificats et les modules" style="margin: 0 auto; display: block;"/></a></p>
<p>On pourra voir que chaque certificat possède un sujet (l’entité à laquelle le certificat appartient) et un émetteur (celui qui l’a signé). Pour le certificat racine, l’émetteur et le sujet sont les mêmes. Pour les autres certificats en revanche, c’est l’émetteur du certificat est le sujet du certificat ayant servi à la signature.</p>
<p>On pourra noter un point important : chaque module est signé par un certificat d’entité final qui lui est propre mais la quasi-intégralité des modules partage le même certificat intermédiaire <a href="https://tech.mozfr.org/post/2019/05/10/Details-techniques-sur-la-panne-des-modules-complementaires-de-Firefox#exp1"><sup>[1]</sup></a>. C’est ce certificat qui a posé problème. En effet, chaque certificat est valide pendant une période de temps donnée. Avant ou après cette période, le certificat ne sera plus accepté et les modules signés avec ce certificat ne pourront plus être chargés dans Firefox. Malheureusement, le certificat intermédiaire que nous utilisions a expiré le 4 mai après 01:00 <abbr lang="en" title="Universal Time Coordinated">UTC</abbr>. Après cet instant, chaque module signé avec ce certificat intermédiaire est devenu invérifiable et ne pouvait plus être chargé dans Firefox.</p>
<p>Toutefois, bien que les modules aient expiré autour de minuit, l’impact de cet arrêt ne s’est pas fait ressentir immédiatement. En fait, les modules sont vérifiés toutes les 24 heures et l’heure de vérification est différente pour chaque utilisateur. Aussi, certaines personnes ont eu le problème immédiatement tandis que d’autres ne l’ont rencontré que bien plus tard. À Mozilla, nous avons réalisé ce problème le 3 mai à 18 h 00 (heure du Pacifique) et avons immédiatement regroupé une équipe afin de le résoudre.</p>
<h2>Circonscrire les dégâts</h2>
<p>Après avoir réalisé de quoi il en retournait, nous avons pris plusieurs mesures pour éviter d’empirer les choses.
Pour commencer, nous avons désactivé la signature pour les nouveaux modules. Nous avons pris cette décision, car nous savions que le certificat utilisé pour la signature avait expiré. Avec le recul, nous aurions pu laisser poursuivre cette signature mais cela aurait interféré avec une solution d’atténuation consistant à inscrire une date en dur (cf. ci-après, au final, nous n’avons pas utilisé cette solution).</p>
<p>Ensuite, nous avons immédiatement envoyé un correctif afin de supprimer le mécanisme consistant à revérifier les modules. L’idée visait à éviter de casser le fonctionnement des modules pour les utilisateurs pour lesquels la validation quotidienne n’avait pas encore eu lieu. Nous avons appliqué ce correctif avant d’en avoir d’autres et nous l’avons retiré maintenant que des correctifs plus pérennes sont disponibles.</p>
<p>À l’heure actuelle, la signature des nouveaux modules fonctionne à nouveau.</p>
<h2>Travailler en parallèle</h2>
<p>En théorie, résoudre un tel problème semble plutôt simple : on crée un nouveau certificat valide puis on publie à nouveau les modules avec ce certificat.</p>
<p>Malheureusement, nous avons vite constaté que cela ne fonctionnerait pas pour plusieurs raisons :</p>
<ol>
<li>Il existe une multitude de modules (plus de 15 000) et le service utilisé pour la signature n’est pas optimisé pour signer en masse, resigner chaque module prendrait plus de temps que ce que nous voulions ;</li>
<li>Une fois les modules signés, les utilisateurs auraient dû récupérer les nouvelles versions de leurs modules. Certains de ces modules sont hébergés sur les serveurs de Mozilla et Firefox aurait mis à jour ces modules en 24 heures. Toutefois, les utilisateurs auraient dû mettre à jour manuellement les modules installés depuis d’autres sources : cela se serait avéré plus que gênant.</li>
</ol>
<p>À la place, nous nous sommes concentrés sur le développement d’un correctif que nous pourrions fournir à l’ensemble de nos utilisateurs et qu’il y ait le minimum d’intervention manuelle.</p>
<p>Après avoir étudié différentes approches, nous avons rapidement convergé vers deux stratégies principales que nous avons menées en parallèle :</p>
<ol>
<li>Corriger Firefox afin de modifier la date utilisée pour valider le certificat. Cela permettrait aux modules de fonctionner à nouveau par enchantement, mais il fallait produire et distribuer une nouvelle version de Firefox ;</li>
<li>Générer un certificat de remplacement toujours valide et, d’une certaine façon, convaincre Firefox de l’accepter plutôt que le certificat existant expiré.</li>
</ol>
<p>Nous n’étions pas certains que l’une de ces deux solutions fonctionnerait et nous avons décidé de les mener en parallèle et de déployer la première qui semblerait fonctionner. En fin de journée, nous avons fini par déployer ce deuxième correctif, un nouveau certificat de remplacement, que nous décrirons ensuite en détail.</p>
<h2>Un certificat de remplacement</h2>
<p>Comme expliqué ci-avant, cette solution se décomposait en deux étapes :</p>
<ol>
<li>Générer un nouveau certificat qui soit valide ;</li>
<li>L’installer à distance dans Firefox.</li>
</ol>
<p>Pour comprendre comment cela fonctionne, il nous faut plonger plus en détails dans la façon dont Firefox valide les modules. Le module est constitué d’un ensemble de fichier incluant la chaîne de certificat utilisée pour le signer. Ainsi, le module peut être vérifié indépendamment tant qu’on connaît le certificat racine (configuré dans Firefox lors de la compilation). Toutefois, comme nous l’avons dit, le certificat intermédiaire ayant expiré, le module ne pouvait être vérifié.</p>
<p>En réalité, lorsque Firefox tente de valider un module, il ne se limite pas à utiliser les certificats contenus dans le module. Il essaie en fait de construire une chaîne de certificats valide en commençant par le certificat d’entité final et en remontant jusqu’à la racine. L’algorithme même est compliqué, mais on peut le résumer ainsi : on commence par le certificat d’entité final et on trouve ensuite un certificat dont le sujet est égal à l’émetteur du certificat final (ici il s’agit normalement du certificat intermédiaire). Dans un scénario simple, le navigateur remonte au certificat intermédiaire, mais il pourrait tout à fait s’agir d’un certificat que le navigateur connaît. Si nous pouvons ajouter à distance un nouveau certificat, valide, Firefox pourrait vérifier ce certificat plutôt que celui qui est expiré. Le schéma qui suit illustre la situation avant et après l’installation du nouveau certificat :</p>
<p><a href="https://tech.mozfr.org/dotclear/public/bidouilleux/armagaddon2/Add-on-blog-post-visual-2-May-7-2019_fr.png" title="Schéma avant/après illustrant l'ajout d'un maillon avec un certificat intermédiaire valide"><img src="https://tech.mozfr.org/dotclear/public/bidouilleux/armagaddon2/.Add-on-blog-post-visual-2-May-7-2019_fr_m.png" alt="Schéma avant/après illustrant l'ajout d'un maillon avec un certificat intermédiaire valide" style="margin: 0 auto; display: block;" /></a></p>
<p>Une fois le nouveau certificat installé, Firefox a désormais le choix entre deux certificats pour valider la chaîne de certificats : le certificat expiré (invalide) et le nouveau certificat (valide). Un élément important permet que cela fonctionne : le nouveau certificat possède le même sujet et la même clé publique que l’ancien certificat et sa signature sur le certificat d’entité final est donc valide. Heureusement, Firefox est suffisamment intelligent pour essayer chacune des pistes jusqu’à trouver un chemin qui fonctionne afin que le module soit à nouveau valide.</p>
<p>On notera ici que c’est la même logique qui est à l’œuvre pour valider les certificats <abbr lang="en" title="Transport Layer Security">TLS</abbr> : il s’agit donc d’un code bien connu que nous avons pu utiliser.<a href="https://tech.mozfr.org/post/2019/05/10/Details-techniques-sur-la-panne-des-modules-complementaires-de-Firefox#exp2"><sup>[2]</sup></a></p>
<p>Le grand avantage de cette méthode est qu’elle ne nécessite pas de modifier les modules. Tant que le nouveau certificat peut être fourni à Firefox, les modules (y compris ceux portant le certificat expiré) pourront être vérifiés automatiquement. Là où ça devient donc compliqué, c’est qu’il faut envoyer le nouveau certificat dans Firefox, automatiquement et à distance puis faire le nécessaire afin que Firefox revérifie les modules qui auraient pu être désactivés.</p>
<h2>Normandy et le système d’études</h2>
<p>Avec une certaine ironie, le véhicule utilisé pour la solution à ce problème a été un « module système » (ou <em>system add-on</em> abrégé en SAO en anglais) qui est un type de module spécial. Afin de pouvoir mener des études de recherche, nous avons développé un système intitulé Normandy qui nous permet de distribuer des modules système aux utilisateurs de Firefox. Ces modules système sont exécutés automatiquement dans le navigateur de l’utilisateur. Bien qu’ils soient généralement utilisés pour lancer des tests, ils possèdent également un accès privilégié aux API internes de Firefox. Ils peuvent notamment ajouter de nouveaux certificats à la base de données utilisée par Firefox pour vérifier les modules.<a href="https://tech.mozfr.org/post/2019/05/10/Details-techniques-sur-la-panne-des-modules-complementaires-de-Firefox#exp3"><sup>[3]</sup></a></p>
<p>Le correctif consiste donc à construire un module système qui réalise deux choses :</p>
<ol>
<li>Installer le nouveau certificat ;</li>
<li>Forcer le navigateur à revérifier chaque module afin que les modules désactivés puissent être activés à nouveau.</li>
</ol>
<p>Mais… si les modules ne fonctionnent plus, comment exécuter ce module système ? Eh bien en le signant avec le nouveau certificat !</p>
<h2>Récapitulons… pourquoi tout ce temps ?</h2>
<p>Nous avons donc un plan : émettre un nouveau certificat afin de remplacer l’ancien, construire un module système à installer sur Firefox et le déployer via Normandy. Après avoir commencé à travailler sur le sujet le 3 mai à 18 h 00 (heure du Pacifique), nous déployions le correctif via Normandy à 2 h 44 le lendemain matin (soit moins de 9 heures), 6 à 12 heures se sont ensuite écoulées avant que la plupart de nos utilisateurs en bénéficient.</p>
<p>Il s’agit d’une durée assez courte, mais nous avons vu plusieurs questions sur Twitter nous demandant pourquoi nous n’avions pas pu aller plus vite.</p>
<p>Plusieurs étapes ont été chronophages.</p>
<p>Premièrement, il a fallu un certain temps pour émettre le nouveau certificat intermédiaire. Comme indiqué ci-avant, le certificat racine est situé dans une boîte noire transactionnelle stockée hors ligne. Il s’agit d’une règle de sécurité importante : le certificat racine est rarement utilisé et on veut qu’il soit sécurisé. En revanche, ce n’est pas idéal lorsqu’on souhaite émettre un nouveau certificat en urgence. En tout cas, un de nos ingénieurs a dû conduire à l’endroit où la boîte noire était stockée. Ensuite, nous avons eu quelques faux départs où nous n’avons pas exactement émis le bon certificat, chaque tentative demandant une à deux heures de tests avant de pouvoir être certains.</p>
<p>Deuxièmement, le développement d’un module système prend du temps. Conceptuellement, c’est quelque chose de très simple mais même les programmes simples nécessitent une certaine attention et nous voulions à tout prix éviter d’empirer les choses. Puis, avant de livrer le module système, il a fallu le tester. Ces tests ont pris du temps, notamment parce qu’il fallait signer ce module et que le système de signature était désactivé : il nous a donc fallu trouver des méthodes de contournement.</p>
<p>Enfin, une fois le module système prêt à être livré, il y a toujours un temps incompressible au déploiement. Les clients Firefox contactent Normandy toutes les 6 heures et, bien entendu, de nombreux clients sont déconnectés : le correctif prendra donc un certain temps à se propager à l’ensemble de la population utilisant Firefox. À l’heure actuelle (9 mai 2019), nous pensons que la plupart des personnes ont reçu cette mise à jour et/ou la mise à jour mineure effectuée ensuite.</p>
<h2>Les dernières étapes</h2>
<p>Bien que le module système déployé avec Normandy et les études devrait corriger le problème pour la plupart des utilisateurs, il n’est pas parvenu jusqu’à tout le monde. Certains utilisateurs restent notamment affectés et pour ceux-là, une autre approche sera nécessaire :</p>
<ul>
<li>les utilisateurs ayant désactivé la télémétrie ou les études ;</li>
<li>les utilisateurs de Firefox pour Android (Fennec) qui ne possède pas de système d’étude ;</li>
<li>les utilisateurs des versions dérivant de Firefox ESR qui n’activent pas la télémétrie ;</li>
<li>les utilisateurs situés derrière des <em>proxies</em> HTTPS en « homme du milieu » : notre système d’installation de module oblige la vérification de certaines clés épinglées (<em>key pinning</em>) et les <em>proxies</em> interfèrent avec celles-ci ;</li>
<li>les utilisateurs de très anciennes versions de Firefox que ne peut pas atteindre le système d’études.</li>
</ul>
<p>En ce qui concerne ce dernier groupe, nous ne pouvons pas vraiment agir : ces utilisateurs devraient mettre à jour leur version de Firefox, car les anciennes versions sont sujettes à de graves vulnérabilités de sécurité non corrigées. Nous sommes conscients des personnes ayant conservé une ancienne version de Firefox afin de pouvoir exécuter d’anciens modules, mais la plupart fonctionne maintenant avec les nouvelles versions de Firefox.</p>
<p>Pour les autres groupes, nous avons développé un correctif pour Firefox qui installera le nouveau certificat lorsque les utilisateurs mettront à jour leur navigateur. Ce correctif a été émis avec une version mineure et la plupart pourront en bénéficier via le mécanisme de mise à jour classique (en réalité, ce devrait déjà être le cas). Si vous utilisez une version dérivée, vous devrez attendre une nouvelle mise à jour de la part du responsable de cette version dérivée.</p>
<p>Nous sommes conscients qu’aucune de ces solutions n’est parfaite. Des données relatives aux modules et aux utilisateurs ont notamment pu être perdues (par exemple avec le module <em><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1549204" title="bug 1549204">Firefox Multi-Account Containers</a></em>).</p>
<p>Nous n’avons pas été capables de développer un correctif qui aurait pu empêcher cet effet de bord et nous pensons que l’approche utilisée a été la meilleure pour nos utilisateurs à court terme. Sur le long terme, nous étudierons d’autres approches architecturales afin de gérer ce type de problème.</p>
<h2>Ce que nous avons appris</h2>
<p>Pour commencer, je souhaiterais féliciter l’équipe qui a accompli un travail extraordinaire : ils ont construit et déployé un correctif en moins de 12 heures après la détection du problème. Pour avoir assisté à ce travail, je peux dire que ces personnes ont travaillé d’arrache-pied, dans un contexte difficile et que peu de secondes ont été gaspillées.</p>
<p>Ceci étant dit, il est évident que cette situation est loin d’être idéale et n’aurait pas dû se produire pour commencer. Nous devons ajuster nos procédures pour réduire la probabilité de tels incidents et aussi pour les corriger plus facilement. Nous réaliserons une analyse rétrospective la semaine prochaine et publierons les modifications que nous souhaitons apporter. En attendant, voici mes premières réflexions sur ce que nous devons faire. Pour commencer, nous devons avoir une meilleure méthode pour vérifier le statut de chaque élément temporel contenu dans Firefox, sans quoi, cela risque d’exploser à tout moment : nous ne devons pas être pris par surprise. Nous travaillons encore là-dessus, mais il nous faut au moins inventorier tous les éléments de cette nature.</p>
<p>Ensuite, il nous faut un mécanisme qui permette de rapidement diffuser des mises à jour à nos utilisateurs lorsque tout le reste est cassé (surtout quand tout le reste est cassé). Nous avons pu tirer parti du système des études, mais il s’agissait d’un outil imparfait que nous avons mobilisé et qui a entraîné certains effets de bord indésirables.</p>
<p>Nous savons notamment que de nombreux utilisateurs activent les mises à jour automatiques mais préfèrent ne pas participer aux études : ce choix est respectable (pour être honnête, je l’avais également désactivé). En même temps, nous devons être capables de diffuser des mises à jour à nos utilisateurs quel que soit le véhicule technique. Les utilisateurs devraient pouvoir activer les mises à jour (y compris les correctifs d’urgence) et pouvoir désactiver tout le reste.</p>
<p>De plus, le canal de mise à jour doit être plus réactif. Nous avons eu lundi des utilisateurs qui n’avaient pas encore récupéré le correctif ou la version mineure : c’est loin d’être idéal. Certains travaux sont et étaient déjà en cours à cet égard mais cet incident montre combien cet effort est important.</p>
<p>Enfin, nous étudierons plus généralement l’architecture relative à la sécurité des modules pour nous assurer qu’un niveau de sécurité suffisant est respecté tout en minimisant les risques de panne.</p>
<p>Nous donnerons suite la semaine prochaine avec les résultats d’une analyse rétrospective plus poussée mais en attendant, je serai ravi de répondre à vos questions (en anglais) à ekr-blog[AD]mozilla[POINT]com.</p>
<p>[1]<a name="exp1"></a> Quelques modules très anciens étaient signés avec un certificat intermédiaire différent.</p>
<p>[2]<a name="exp2"></a> Les personnes familières avec WebPKI reconnaîtront la méthode également utilisée pour la certification croisée.</p>
<p>[3]<a name="exp3"></a> Note technique : nous n’ajoutons pas un certificat avec un privilège quelconque. L’autorité de ce certificat provient de la racine avec laquelle il a été signé. Nous ajoutons uniquement un nouveau certificat intermédiaire à l’ensemble de certificats qui peuvent être utilisés dans Firefox. Autrement dit, nous n’ajoutons pas un nouveau certificat, privilégié d’une quelconque façon, dans Firefox.</p>
Première contribution : rapporter un bogue sur Bugzillaurn:md5:7b742c0bba32d26a8e8419aeee3241202013-04-23T22:43:00+02:002016-01-17T12:13:38+01:00GoofyGénéralBogueBugzillaConseilsContribuerCorrectifTutorielWebRTC <p><em>Il est notoire que le bugzilla de Mozilla peut s’avérer difficile à aborder et maîtriser. Pour vous guider dans ce labyrinthe, Liz Henry a rédigé un très bon article illustré sur son blog : <a title="article original en anglais" hreflang="en" href="http://bookmaniac.org/file-a-bug-the-missing-manual-now-with-unicorns/">File a bug: the missing manual, now with unicorns.</a></em></p><p><em>Nous vous le proposons ici en espérant qu’il vous incitera à contribuer à Mozilla.</em></p><p><em><strong>Si vous rapportez un bogue ou contribuez à un bogue dans le cadre de la communauté francophone, indiquez le avec le texte <code>[mozfr-community]</code> dans le champs <i>whiteboard</i> (voir ci-après).</strong></em></p><p>Traduction : <strong>Sphinx</strong> pour MozFr.</p><h2>Rapporter un bogue : le manuel qui manquait, maintenant avec des licornes</h2><p>Lors d’innombrables conférences, j’ai entendu la réponse habituelle à la question « comment s’impliquer dans un projet open source ? ». Ça ressemble un peu à ça :</p><ul><li>Étape 1 : rapporter un bogue !</li><li>Étape 2 : Envoyer un correctif ! (répéter les étapes 1 et 2 pendant un petit moment)</li><li>Étape 3 : Vous voilà maintenant prêt à écrire de nouvelles fonctionnalités et de nouveaux trucs ! Déployez vos ailes !</li></ul><p>J’ai toujours pensé que c’était intéressant parce que cela représente une tentative pour rassurer les gens en leur disant qu’il n’y a pas forcément du développement et du code dès le début. Juste remplir un rapport de bogue, c’est le premier pas. Cela fait que des gens viennent dans des projets et se demandent vaguement comment trouver des bogues.</p><p>En tant que bugmaster pour Mozilla, une partie de ce que je veux réaliser est d’ajouter une étape : regardez tous les bogues que vous avez déjà rapportés, il y en a des tonnes et des tonnes, et voyez ce que vous pouvez faire pour améliorer les méta-données relatives à ces bogues.</p><p>Aujourd’hui sur Planet Mozilla, j’ai remarqué quelques très bons conseils de Jason Smith sur la meilleure façon de trouver des bogues : <a hreflang="en" title="article de Jason Smith sur recherche de bogues" href="http://jasondanielsmith.wordpress.com/2013/04/06/webrtc-testing-try-out-conversat-io-and-file-bugs/">WebRTC testing: Try out conversat.io and file bugs</a>. C’est vraiment sensé mais aussi pratique. Le blog de Jason a quelques billets comme celui-là qui conseillent de se tourner vers des domaines en particulier, comme WebRTC ou les applications Desktop Web, en ajoutant l’utilisation de ces outils dans votre vie quotidienne. Notre séquence d’ « implication dans un projet <em>open source</em> » ressemble donc maintenant un peu plus à ça :</p><ul><li>Étape 1 : Trouvez une fonctionnalité qui pourrait être testée</li><li>Étape 2 : Trouvez comment l’utiliser régulièrement</li><li>Étape 3 : Utilisez-la</li><li>Étape 4 : Observez un comportement que vous pensez être un bogue</li><li>Étape 5 : RAPPORTER UN BOGUE (MAIS COMMENT ?)</li></ul><p>Il faut connaître beaucoup de choses de ce milieu pour réellement rapporter un bogue dans le système compliqué qu’est bugzilla.mozilla.org (ou BMO).</p><p>Prenons donc l’exemple de WebRTC. Disons que vous avez suivi le conseil de Jason, utilisé conversat.io pendant un moment et que vous avez trouvé un BOGUE. Heureusement, Jason fournit un lien qui pointe directement vers Bugzilla dans le formulaire enter_bug, avec les entrées Produit et Composant pré-remplies afin qu’il corresponde à <a hreflang="en" title="un bogue avec webRTC" href="https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=WebRTC">un bogue</a> avec WebRTC (le composant) et Core (le produit). Les bogues dans BMO sont catégorisés selon le produit comme Firefox Desktop, Firefox pour Android, FirefoxOS, Thunderbird, etc. « Core » est le produit pour le code partagé entre beaucoup d’autres produits. Si vous étiez en train de rapporter un bogue de WebRTC en partant de zéro, vous ne sauriez probablement pas sous quel produit l’enregistrer, et pourtant vous auriez dû en choisir un. Donc merci beaucoup Jason de donner un lien avec le bon produit et le bon composant !</p><p>Attendez… Il y a encore beaucoup plus de contexte à assimiler. Ce n’est pas obligatoire mais c’est très appréciable une fois qu’il est compris !</p><p>Tout d’abord, vous devez avoir un compte Bugzilla pour que le lien fonctionne correctement. Si vous faites ça, vous serez un nouvel utilisateur de Bugzilla et certains champs du formulaire de bogue vous apparaîtront différemment : vous serez automatiquement dirigé sur un « formulaire guidé de champs de bogue » qui est divisé en plusieurs étapes, au lieu d’avoir le formulaire vous montrant la « vue avancée » complète avec plusieurs douzaines de champs et de menus déroulants.</p><p>Ensuite, pourquoi ne pas regarder la liste de <a hreflang="en" title="tous les composants du produit Core" href="https://bugzilla.mozilla.org/describecomponents.cgi?product=Core">tous les composants du produit Core.</a> Cela représente une bonne partie des connaissances du domaine : un petit morceau de la carte ou de la géographie de Bugzilla. Comme vous pouvez le voir, il y a beaucoup d’autres composants en plus de Core. Descendez un peu jusqu’au WebRTC, vous pouvez voir qu’il y a plusieurs sous-catégories : WebRTC, WebRTC : Audio/Video, WebRTC : Networking (réseau) et WebRTC : Signaling (signaux). cliquer sur le composant général WebRTC pour voir une <a href="https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=WebRTC&resolution=---&list_id=6242791">liste des bogues ouverts sur WebRTC</a>. C’est là que la leçon de géographie devient utile.</p><p>En ce moment il y a 113 bogues ouverts pour WebRTC. Vous pouvez les consulter rapidement pour avoir une idée de ce que les autres ont pu trouver comme bogues. On y reviendra plus tard !</p><p>Le plus important maintenant est ce qui va suivre : est-ce que votre bogue a déjà été rapporté ? Suivant le nombre de bogues dans cette liste et votre degré de patience et d’intérêt, vous pourriez avoir envie de, soit parcourir et lire rapidement les résumés (le titre du bogue) ou soit de faire une recherche dans la page pour les mots qui peuvent correspondre au bogue que vous vous apprêtez à rapporter.</p><p>Si vous trouvez quelque chose dans cette liste que vous pensez être votre bogue, regardez y de plus près. Lisez le rapport et les commentaires pour essayer de comprendre ce dont ils sont en train de parler. Si c’est la même chose que votre bogue, vous pouvez avoir envie de laisser un commentaire décrivant ce que vous avez vu se produire.</p><p>Mais prenons le cas où vous n’avez pas trouvé votre bogue dans cette liste. Haha ! Et là, vous utilisez le lien du billet de blog original : <a href="https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=WebRTC">lien pour rapporter un bogue sur WebRTC</a>. Si vous êtes dans mon cas, ou êtes un utilisateur de Bugzilla qui a fait plus de 25 éditions ou commentaires à des bogues, vous verrez le formulaire avancé, qui est énorme :</p><p style="text-align:center">(cliquez sur l’image réduite pour l’agrandir)</p><p><a title="image 1 formulaire grand format" href="https://tech.mozfr.org/dotclear/public/bugzillaTips/image_1.png"><img alt="image 1 formulaire grand format" style="display:block; margin:0 auto;" title="image 1 formulaire grand format, avr. 2013" src="https://tech.mozfr.org/dotclear/public/bugzillaTips/.image_1_m.jpg" /></a></p><p>Si vous êtes un utilisateur de Bugzilla relativement nouveau, vous passerez par un formulaire guidé qui se décompose en plusieurs écrans. (Vous pouvez changer à tout moment pour avoir le formulaire avancé via un lien en bas de page si jamais le fait de passer par plusieurs écrans vous ennuie). Le premier écran pour une entrée de bogue guidée correspondra normalement à la sélection du produit et du composant. Étant donné que ceux-ci ont déjà été sélectionnés avec le lien pratique de Jason, vous pouvez commencer au deuxième écran pour renseigner un résumé de votre bogue. Dans ce cas, je rapporte une espèce d’invasion de licornes.</p><p><img alt="étape 2 avec licorne" style="display:block; margin:0 auto;" title="étape2 avec licorne, avr. 2013" src="https://tech.mozfr.org/dotclear/public/bugzillaTips/image2_step2.png" /></p><p>Une fois votre résumé écrit, vous verrez une liste de bogues potentiellement similaires apparaître sous le champ du résumé. Il est important de les parcourir et de les lire pour voir si quelqu’un d’autre a déjà rapporté des licornes envahissant leur écrans de conversat.io dans Firefox. Ici, ce n’est clairement pas le cas.</p><p><img alt="étape 3 avec arc-en-ciel" style="display:block; margin:0 auto;" title="étape 2 avec arc-en-ciel, avr. 2013" src="https://tech.mozfr.org/dotclear/public/bugzillaTips/image3_step22.jpg" /></p><p>Étant donné que personne n’a rapporté ce bogue, je clique sur « Mon problème n’est pas dans la liste » (en anglais : “My issue is not listed”) et je passe au troisième écran qui suggère comment décrire les actions ou les étapes pour reproduire le problème, ce qui se passe exactement lorsque j’observe un bogue et ce que je pense qui aurait plutôt dû se passer.</p><p><img alt="étape 3 image 4" style="display:block; margin:0 auto;" title="étape 3 image 4, avr. 2013" src="https://tech.mozfr.org/dotclear/public/bugzillaTips/image4_step3.png" /></p><p>Génial, nous avons rempli un rapport de bogue ! Revenons à cette liste « comment contribuer à un projet open source » :</p><ul><li>Étape 1 : Trouvez une fonctionnalité qui pourrait être testée</li><li>Étape 2 : Trouvez comment l’utiliser régulièrement</li><li>Étape 3 : Utilisez-la</li><li>Étape 4 : Observez un comportement que vous pensez être un bogue</li><li>Étape 4.5 : Créez un compte sur bugzilla.mozilla.org</li><li>Étape 4.6 : Confirmez votre compte avec l’e-mail de confirmation</li><li>Étape 4.7 : Connectez-vous sur bugzilla.mozilla.org</li><li>Étape 5 : RAPPORTEZ UN BOGUE (et maintenant vous savez comment faire !!!)</li></ul><p>Attendez, il y en a encore — enfin, si vous voulez retrouver votre cap sur cette carte de Bugzilla. Regardons à nouveau cette liste de tous les bogues ouverts à propos de WebRTC. Que pouvons-nous en tirer ?</p><p>Pendant que je regarde cette liste, elle me semble assez mystérieuse. Avec le langage contenu dans les résumés, je suppose que certains des bogues sont des notes de l’équipe de développement pour leur propre liste de trucs à faire, d’autres semblent avoir été découverts par des utilisateurs courants du logiciel. La première chose que je fais : trier la page de différentes façons pour voir ce qu’elle révèle. Trier les États (ou <em>status</em> en anglais) montre les bogues NON CONFIRMÉS en premiers et les NOUVEAUX juste en dessous. Il y en a un appelé <a title="getUserMedia gèle tout le système" href="https://bugzilla.mozilla.org/show_bug.cgi?id=801385">getUserMedia gèle tout le système</a> qui n’est pas encore confirmé et qui peut être un bon exemple.</p><p>En voici un intéressant : <a title="aucun événement lorsqu'un pair à distance disparaît" href="https://bugzilla.mozilla.org/show_bug.cgi?id=859761">aucun événement lorsqu’un pair à distance disparaît</a>. Mon aperçu de ce bogue va être différent du vôtre si vous êtes nouveau sur Bugzilla parce que j’ai plus de pouvoirs magiques comme la <a title="confirmation et édition de bogues" href="https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla">confirmation et édition de bogues</a> ainsi que d’autres choses concernant l’administration. Il y a beaucoup de choses sur la page et c’est très chargé en texte. Vous devez apprendre à l’<em>écrémer</em> et à la filtrer mentalement afin de voir et de remarquer ce qui important à cet instant. Voici à quoi ressemble un bogue pour un nouvel utilisateur de Bugzilla :</p><p><img alt="bogue soumis par autre utilisateur" style="display: block; margin: 0px auto;" title="bogue soumis par autre utilisateur, avr. 2013" src="https://tech.mozfr.org/dotclear/public/bugzillaTips/image5.png" /></p><p>Ce que je peux déduire de cette lecture c’est qu’au moins une personne est en train de regarder les nouveaux bogues rapportés, les trie et travaille sur le projet. En fait, si je clique sur d’autres bogues concernant WebRTC, je peux lire et voir que Jason est très actif sur la plupart d’entre eux, ce qui n’est pas surprenant vu qu’il écrit des billets sur le sujet.</p><p>Le blog de Jason ressemble à un endroit plutôt utile pour trouver des endroits où accueillir des testeurs et des trouveurs de bogues. Vous pouvez aussi consulter les <a title="pages de la communauté Assurance Qualité de Mozilla (QMO)" href="https://quality.mozilla.org/docs/misc/how-can-i-help-test/">pages de la communauté Assurance Qualité de Mozilla (QMO)</a> qui expliquent comment faire fonctionner des versions nightly et participer aux <a title="journées de tri et de test des bogues" href="https://quality.mozilla.org/category/events/">journées de tri et de test des bogues</a> de l’assurance qualité (QA).</p><p>Cependant, le point le plus important ici, c’est que pour commencer à contribuer à un projet<em> open source</em>, à part rapporter un bogue exceptionnel découvert par hasard, il est super utile d’apprendre l’environnement d’un projet. Adoptez le projet et regardez autour pour apprendre ce qui s’y passe. Si vous êtes en train de rapporter un bogue, regardez les autres bogues. Regardez qui commente et qui travaille sur ces bogues. Rejoignez leur canal IRC et lisez leurs <a title="pages wiki" href="https://tech.mozfr.org/post/2013/04/23/pages wiki">pages wiki</a> et (souvent plus formel que les pages wiki) leur documentation pour les développeurs. Sinon vous pouvez utiliser Google pour en apprendre plus sur le projet et ce qui va avec. Dans notre cas, j’ai trouvé que <a title="conversat.io était assez récent" href="https://hacks.mozilla.org/2013/03/making-webrtc-simple-with-conversat-io/">conversat.io était assez récent</a> et avait été développé en partie pour montrer <a title="ce qu'est WebRTC est et ce qu'il peut faire" href="https://hacks.mozilla.org/2013/03/webrtc-data-channels-for-great-multiplayer/">ce qu’est WebRTC et ce qu’il peut faire</a>.</p><p>Dans mes premières explorations, la grande transparence de Mozilla était clairement visible et m’a fait voir la fantastique profondeur technique que l’on peut atteindre juste en passant une demi-journée à lire et à naviguer dans les bogues. Pour la société dans laquelle nous vivons, nous devons nous rendre compte des implications que cela peut avoir pour l’éducation et le système éducatif. C’est une évolution culturelle importante et je suis heureuse d’y participer.</p>