MozFR

Avertir des dangers du HTTP non sécurisé

par Tanvi Vyas et Peter Dolanjski (Mozilla), le 20 janvier 2017,

Firefox 51 : mot de passe non sécuriséHTTPS, la version sécurisée du protocole HTTP, est depuis longtemps un des éléments de base du Web moderne. Il crée des connexions sécurisées en fournissant de l’authentification et du chiffrement entre le navigateur et le serveur web. HTTPS vous protège contre les écoutes et la falsification de vos communications, que ce soit lorsque vous consultez le site de votre banque ou lorsque vous discutez avec des amis. C’est essentiel, car, à travers une connexion HTTP classique, quelqu’un d’autre présent sur votre réseau peut lire ou modifier le site internet que vous consultez, vous mettant en danger.

Pour protéger les utilisateurs en ligne, nous aimerions voir tous les développeurs utiliser HTTPS pour leurs sites web. Utiliser HTTPS est devenu un jeu d’enfant. Des progrès fulgurants ont été faits, car désormais une partie significative du trafic internet est sécurisée par HTTPS.

Changements de l’expérience sécurité des utilisateurs de Firefox

Jusqu’à maintenant, Firefox affichait un cadenas vert dans la barre d’adresse pour indiquer qu’un site web utilisait HTTPS et un indicateur neutre (sans icône de cadenas) quand ce n’était pas le cas. Le cadenas vert indique un site qui utilise une connexion sécurisée.

Connexion sécurisée (HTTPS) actuelle Connexion sécurisée (HTTPS) actuelle

Connexion non sécurisée (HTTP) actuelle Connexion non sécurisée (HTTP) actuelle

Afin de bien attirer l’attention des utilisateurs sur le risque qu’ils courent, à partir de ce mois dans Firefox 51, les pages web qui demandent un mot de passe mais qui n’utilisent pas HTTPS afficheront un cadenas gris barré de rouge dans la barre d’adresse.

panonceau de connexion non sécurisée

Cliquer sur l’icône « i » affichera les messages « Connexion non sécurisée » et « Les identifiants saisis sur cette page pourraient être compromis ».

Nous avons testé cette expérience utilisateur avec Firefox sur le canal Developer Edition à partir de janvier 2016. Depuis, le pourcentage de formulaires d’identification détectés par Firefox et qui sont pleinement sécurisés par HTTPS est passé de 40 % à presque 70 %. Quant au nombre total de pages HTTPS, il a également augmenté de 10 %, comme vous pouvez le voir sur le graphique ci-dessus.

Dans ses versions à venir, Firefox affichera un message d’avertissement directement dans la liste déroulante lorsqu’un utilisateur cliquera sur un champ de saisie de nom d’utilisateur ou mot de passe d’une page qui n’utiliserait pas HTTPS. Ce message affichera la même icône de cadenas gris barré de rouge, avec des messages similaires : « Cette connexion n’est pas sûre. Les identifiants saisis sur cette page pourraient être compromis ».

Alerte dans un champ de mot de passe sur une page qui n'utilise pas HTTPS Alerte dans un champ de mot de passe sur une page qui n’utilise pas HTTPS

Ce que nous allons faire à l’avenir

Pour continuer à promouvoir l’utilisation de HTTPS et prévenir les utilisateurs des risques, Firefox va finalement afficher le cadenas barré de rouge sur toutes les pages qui n’utilisent pas HTTPS, afin de bien montrer qu’elles ne sont pas sécurisées. Nous allons continuer de publier des nouvelles en fonction de l’évolution de nos plans, mais notre espoir est d’encourager tous les développeurs à prendre les mesures nécessaires pour protéger les utilisateurs du Web grâce à HTTPS.

Pour plus d’informations techniques au sujet de cette nouveauté, veuillez vous référer au billet de blog de l’année dernière. Si vous voulez tester ces changements avant qu’ils n’arrivent dans Firefox, nous vous invitons à installer la dernière version de Firefox Nightly.

Remerciements

Merci à l’ingénierie, l’expérience utilisateur, la recherche utilisateur, l’assurance qualité et aux équipes produit qui m’ont aidé – Sean Lee, Tim Guan-tin Chien, Paolo Amadini, Johann Hofmann, Jonathan Kingston, Dale Harvey, Ryan Feeley, Philipp Sackl, Tyler Downer, Adrian Florinescu et Richard Barnes. Et un remerciement très spécial à Matthew Noorenberghe sans qui ceci n’aurait pas été possible.


Traduction et relecture : Thegennok, Goofy, Théo, Julien “Sphinx”, Mozinet, Hellosct1 et anonymes

Les captures ont été localisées par le traducteur.

Notre précédent billet : Plus sûr·e avec Firefox, de Panagiotis Astithas (Mozilla)

Plus sûr·e avec Firefox

par Panagiotis Astithas, le 13 janvier 2017,

Les dernières améliorations de sécurité et de protection de la vie privée dans Firefox

red panda puzzle

[Cet article est paru d’abord sur Medium]

Firefox est le seul navigateur web qui ne rende des comptes qu’à vous, nos utilisateurs. C’est pour ça que chacun d’entre nous qui travaillons sur Firefox produisons un effort important pour rendre votre utilisation de Firefox plus privée et plus sûre. Nous mettons Firefox à jour toutes les 6 semaines, et tout nouveau changement vous est publié aussi rapidement que nous pouvons le créer et le vérifier. Depuis quelques versions, nous avons intégré des éléments d’un ensemble plus large de changements en matière de sécurité et de vie privée. Cet article vous donnera une vue d’ensemble de tous ces changements.

Panneau d’identité du site et de permissions

Le principal projet a entraîné des améliorations à la manière dont Firefox gère les demandes de permission des sites qui veulent faire des choses que la plateforme web ne permet pas par défaut, comme accéder à la caméra de votre portable ou votre capteur GPS. Pour découvrir comment le modèle actuel s’en sortait, nous avons conduit un certain nombre d’études sur des utilisateurs et recueilli des retours d’utilisateurs et de développeurs web.

permissions-localisation.png

Ce que nous avons trouvé d’évident : les utilisateurs ont du mal à utiliser pleinement les permissions web. Voici quelques-unes de nos observations :

  • Il est facile de passer outre une fenêtre qui demande une autorisation, pour empêcher les sites web de vous harceler. Mais il n’est pas aussi évident de revenir en arrière pour retrouver cette invite qu’on a pu fermer par mégarde, ce que les utilisateurs ont trouvé déroutant.
  • Gérer les permissions pour chaque site web s’est avéré difficile en raison du grand nombre d’options proposées.
  • On a trouvé peu ergonomique de donner l’accès au partage d’écran. En effet, il était difficile de choisir la zone de l’écran qui serait partagée, de plus le partage d’écran n’était autorisé qu’avec des sites web figurant sur une liste gérée manuellement.

Pour que la plateforme du Web ouvert soit à la hauteur des possibilités des plateformes natives et propriétaires, nous devions régler ces problèmes. Nous avons d’abord concentré nos efforts sur le regroupement, en un seul endroit, de tout ce qui concerne la sécurité et la vie privée. Nous l’avons appelé le « Panneau des permissions et de l’identité du site », ou plus familièrement, le « Centre de contrôle ».

permissions panonceau

Celui-ci apparaît quand vous cliquez sur le l’icône ronde autour de la lettre i (i comme information) qui figure à l’extrémité gauche de la barre d’adresse intelligente. Le panneau est conçu pour être le lieu unique de ressources pour tout ce qui est sécurité et vie privée, pour le site que vous visitez. Cela comprend les certificats pour les connexions chiffrées, les mises en garde contre les contenus mixtes, le statut de la protection contre le pistage ainsi que les permissions qui ne sont pas prévues par défaut. Nous sommes ravis de voir que Chrome a adopté lui aussi une interface similaire.

Privilèges élevés pour les permissions qui ne sont pas par défaut

Par défaut, les sites web requièrent un niveau élevé de privilèges pour avoir accès au matériel de votre ordinateur tel que la caméra, le microphone, le GPS ou d’autres capteurs. Quand un site demande une permission de ce type et que l’utilisateur l’accorde, le panneau d’identité du site affichera l’élément autorisé avec un bouton « x » pour revenir sur ce choix. Dans le cas de permissions particulièrement sensibles en termes de vie privée, telles que l’accès au microphone ou à la caméra, l’icône aura une couleur rouge et une petite animation pour attirer l’attention.

Utiliser la caméra autoriser

Quand l’utilisateur a accordé des privilèges élevés à un site, l’icône « i » dans la barre d’URL (adresse internet) est estampillée avec un point qui indique l’information supplémentaire présente dans le panneau d’identité du site. Ceci vous permet d’évaluer les caractéristiques de sécurité de votre session de navigation en cours d’un coup d’œil rapide à la barre d’adresse intelligente, où les icônes « i » et en forme de cadenas sont affichées ensemble.

info avec cadenas vert

Les utilisateurs qui veulent un contrôle encore plus détaillé sur toutes les permissions disponibles peuvent se rendre à l’onglet « Permissions » dans la boîte d’informations sur la page (flèche droite dans le panneau d’identité > Plus d’informations).

permissions succession

Invite et boîte de dialogue de permission

Les boîtes de dialogue de permission sont désormais plus cohérentes qu’avant, à la fois en termes d’actions et de messages disponibles.

Quand un site demande une permission, une invite de permission apparaît avec un message et des icônes spécifiques selon le type de permission demandé et les actions disponibles. La plupart du temps, il y en aura seulement deux : autoriser ou ne pas autoriser l’accès. L’action par défaut ressortira accentuée en bleu, rendant l’action la plus commune plus facile à réaliser.

Autoriser la caméra

Dans quelques cas d’invites de permission avec plus de deux actions, un menu déroulant apparaîtra à côté du bouton d’action secondaire.

Identifiants : Ne jamais enregistrer

Autoriser de façon permanente ou rejeter une permission pour un site se fait en cochant l’option présente en permanence « Se souvenir de cette décision ».

Caméra à partager : Se souvenir de cette décision

Nous avons reçu beaucoup de retours d’expérience sur la façon dont ces invites sont faciles à refuser et sur la façon dont les utilisateurs n’arrivaient souvent plus à découvrir comment les rappeler. Dans le nouveau design, les invites de permission persistent même quand vous interagissez avec la page. Vous pouvez bien sûr les ignorer et continuer à utiliser la page normalement. Mais grâce à la persistance de l’invite, il est désormais plus facile d’associer le comportement inadéquat – une webcam qui ne fonctionne pas ou des localisations qui ne s’affichent pas – avec un bouton d’autorisation/de refus qui attend votre réponse.

D’ailleurs, les demandes de permission refusées sont dorénavant affichées avec des icônes barrées dans la barre d’adresse intelligente pour indiquer une possible cause du dysfonctionnement du site. Par exemple, un site de visioconférence ne fonctionnera pas très bien si vous rejetez ses demandes de permission d’accès à la caméra. Donc, l’icône de caméra barrée restera par la suite, à côté de l’icône « i », pour vous rappeler ce fait-là.

Icônes des permission barrées

Passer à un autre onglet cachera l’invite (parce qu’elle est spécifique au site ouvert dans chaque onglet), mais, quand l’onglet précédent est sélectionné de nouveau, l’invite réapparaîtra.

Permissions lors du changement d'onglets

Les permissions audio, vidéo et de partage d’écran

Les permissions relatives à WebRTC disposent d’encore plus de nouveautés.

Pour commencer, il n’est plus nécessaire d’utiliser une liste blanche distincte de sites pour le partage d’écran. Cela signifie que tous les sites peuvent désormais utiliser le partage d’écran WebRTC dans Firefox.

De plus, le partage d’écran inclut maintenant un aperçu du contenu à partager afin de faciliter l’identification de l’écran, de l’application ou de la fenêtre à partager.

partage d’écran : fenêtres

Dans les cas les plus risqués, tels que le partage de l’écran entier ou le partage de l’application Firefox, un message d’alerte s’affichera pour s’assurer que vous savez bien ce que vous allez faire.

Partage d'écran

De plus, lorsque vous avez accordé à un site de visioconférence l’accès simultané à votre caméra et à votre microphone, si vous retirez l’une des deux permissions accordées, cela retirera également la seconde. Cela vous aidera à éviter les fuites accidentelles de vos données privées.

Améliorations du panneau des modules complémentaires

En travaillant sur ces améliorations de sécurité, nous avons corrigé de vieux bogues du panneau de la plateforme qui touchent tous les types de panneaux, dont ceux créés par les modules complémentaires.

Pages d’erreur

Et finalement, les pages d’erreur ont aussi bénéficié de quelques astuces.

La cause la plus courante - Google Slides] des erreurs de connexion sécurisée se révèle être des systèmes avec une heure incorrecte. Firefox détectera quand l’heure de votre horloge semble vraiment différente et vous suggérera la façon de la corriger dans le message d’erreur.

Horloge faussée

Une autre cause courante - Google Slides] des connexions défaillantes est la présence d’un portail captif. Firefox détectera désormais ce cas et vous conseillera de vous connecter dans le portail captif. Bien que certains systèmes d’exploitation aient une prise en charge intégrée des portails captifs, si vous utilisez régulièrement vos comptes de réseaux sociaux pour vous connecter, l’expérience avec Firefox sera plus agréable. Ce changement est actuellement dans les versions Nightly et Developer Edition et devrait bientôt intégrer la version stable.

Portail captif

Repenser à ce que nous sommes arrivés à accomplir dans ces quelques derniers mois me rend fier de travailler avec cette fantastique équipe d’ingénieurs, de designers, de chercheurs sur les utilisateurs, d’ingénieurs en assurance qualité et de chefs de projet et de produit talentueux et passionnés. Mais bien sûr, nous sommes loin d’en avoir fini avec les améliorations de la vie privée et de la sécurité de nos utilisateurs. Restez à l’écoute pour davantage de nouvelles passionnantes sur la vie privée et la sécurité dans Firefox en 2017 !

[Un grand merci à Bram Pitoyo, Nihanth Subramanya, Tanvi Vyas, Peter Dolanjski, Florian Quèze et Johann Hofmann pour leur relecture des brouillons de ce billet.]


Traduction et relecture : Mozinet, Goofy, Hellosct1, Julien “Sphinx”, Anthony, Théo et anonymes

Certaines captures proviennent de l’article originale.

Premier TupperRust à Lyon le 2 février

La Maison pour Tous de LyonDisons-le tout de suite pour les Non-Parisiens qui nous reprochent de faire tous nos événements à Paris (où Mozilla a des bureaux), voici un événement à Lyon. Il est donc possible de réunir des personnes autour des sujets mozilliens à côté de chez vous. Lancez-vous !

Rust

Rust, vous connaissez ? Vous avez peut-être découvert le terme lors de son inclusion dans Firefox ou lors du lancement du projet Quantum qui renouvellera Firefox. Rust sera au cœur du nouveau moteur d’affichage de Firefox, Servo. Voilà comment David Bryant définit Rust :

Logo de RustIl s’agit d’un langage de programmation système qui fonctionne à la vitesse de l’éclair et simplifie le développement de programmes parallélisés, en garantissant la sûreté de la mémoire et l’isolation entre les threads (tâches). Dans la plupart des cas, le code écrit en Rust refusera même de compiler s’il n’est pas fiable.

La sécurité, voilà sur quoi Mozilla insiste quand il est question de Rust :

Badge RustMozilla investit également dans les technologies fondamentales pour éviter l’apparition de ces vulnérabilités de sécurité. Le langage de programmation Rust est spécialement conçu pour garantir que plusieurs types importants de vulnérabilités de sécurité ne puissent tout simplement pas advenir, y compris celle qui a mené à la tristement célèbre vulnérabilité Heartbleed. Il est littéralement impossible d’écrire un programme en Rust qui contiendrait une de ces vulnérabilités de sécurité. Même si Rust a débuté chez Mozilla, il ne lui aurait cependant pas été possible d’arriver à maturité aussi rapidement pour obtenir un langage prêt pour la production s’il n’y avait plus de 1 500 contributeurs pour l’y aider.

Si vous vous demandez si Rust est prêt pour la production et n’est pas qu’un langage pour répondre aux besoins de Mozilla, sachez que Dropbox l’a adopté pour créer sa propre infrastructure de cloud.

Tupper

Rust, OK ! mais Tupper ?

Tupper, parce que c’est la reprise du concept des TupperVim :

Les Tuppervim sont des événements où l’on partage des connaissances et des astuces à propos de Vim.

Les TupperVim s’inspirent autant des agapes maçonniques du troisième millénaire que des soirées tupperware™ des années 60. Tout un concept.

La Maison pour Tous de LyonDonc Lyon verra le premier TupperRust de l’histoire !

Les TupperRust s’articulent en deux parties :

  • une présentation d’une heure par l’intervenant invité ;
  • des revues de code sur la base du volontariat : un membre du public expose un bout de code écrit en Rust et le public le commente et pose des questions. C’est un moment propice pour apprendre plein de bonnes pratiques !

Pour cette session, nous accueillons Ivan Enderlin, qui travaille sur Tagua VM, une machine virtuelle PHP expérimentale écrite en Rust pour prévenir une grande partie des vulnérabilités de la machine virtuelle classique.

Où et quand ?

EPNDans le cadre des conférences jeudi du libre

Jeudi 2 février 2017 de 19 h 00 à 21 h 30

GRATUIT – inscription sans inscription

ALDIL et EPN

Logo ALDILSalle des Rancy de la Maison Pour Tous

249, rue Vendôme 69003 Lyon (carte libre)

» Sur l’agenda du Libre


@Mozinet

Le précédent événement : Un atelier de traduction en avril chez Mozilla (en avril)

Crédit illustrations : photos fournies par La Maison pour Tous de Lyon

Logos de l’EPN et de l’ALDIL. Tous droits réservés.

Moz://a : le nouveau logo est là

Nouveau logo Mozilla sur un ordinateur portableTim Murray, directeur créatif de Mozilla, peut, après un long processus ouvert, nous présenter le nouveau logo de Mozilla. La communauté Mozilla francophone a traduit l’annonce pour vous :

L’arrivée

Sept mois après le lancement de cette initiative visant à rafraîchir l’image de marque de Mozilla, nous y sommes ! Des milliers de courriels, des centaines de réunions, des dizaines de concepts et trois rounds de recherche plus tard, nous avons quelque chose à partager. Si vous venez tout juste de rejoindre ce processus, vous pouvez aller voir cet article ou celui-là.

Au cœur de ce projet, un objectif essentiel : rendre la mission et l’identité de Mozilla compréhensibles par le plus grand nombre. Mozilla souhaite être identifié comme le porte-drapeau d’un Internet sain, un Internet où tous les internautes peuvent explorer, découvrir, créer et innover sans barrières ni limites. Un Internet où le pouvoir est entre les mains des internautes, pas d’une poignée de personnes. Un Internet où protection, sécurité et identité sont respectées.

Aujourd’hui, nous pensons que ces principes sont plus importants que jamais. En tant qu’organisation à but non lucratif, Mozilla est dans une position unique pour concevoir ces produits, technologies et autres programmes qui permettent à Internet de croître sainement, avec des individus informés et aux commandes de leur vie en ligne.

L’identité de marque de Mozilla – logo, voix, design – est un indicateur fort de ce en quoi nous croyons et de ce que nous faisons. Nous nous investissons pleinement pour nous assurer qu’Internet soit une ressource publique, mondiale, saine, ouverte et accessible à tous, c’est pourquoi notre nouvelle identité est empreinte du langage d’Internet.

Aujourd’hui, nous partageons notre nouveau logo et une palette de couleurs suggérée, l’architecture d’un langage autour de cette identité et une approche pour les images associées. Fidèles à notre intention de nous engager avec les communautés créatives et techniques au travers de cette démarche Open Design, nous attendons vos retours quant à ces éléments pendant que nous construisons notre charte graphique.

Entrons un peu plus dans le détail des composants de notre identité de marque, développée en collaboration avec un partenaire exceptionnel : le consultant londonien en design johnson banks.

Notre logo

Notre logo et son clin d’œil au langage des URL renforcent l’idée qu’Internet est au cœur de Mozilla. Nous restons attachés à l’idée originale du lien en tant que point de départ d’une expérience sans filtre, sans intermédiaire vers la richesse du contenu d’Internet.

Logo Mozilla

La police de caractères utilisée pour le logotype et les textes associés est Zilla. Créée pour nous par Typotheque aux Pays-Bas, Zilla est gratuite et libre pour tous.

Typotheque est un des partenaires historiques de Mozilla. C’était la première fonderie typographique à proposer des polices destinées au Web et le navigateur de Mozilla, Firefox, était un des premiers à adopter ces polices de caractères pour le Web. Nous avons choisi de nous associer à Peter Bilak de Typotheque, pour sa connaissance approfondie de la localisation des polices de caractères et parce que nous souhaitions avoir une police qui inclue également des langues différentes de l’anglais. Avant ce partenariat avec Typotheque, nous avons reçu des concepts et des conseils de la part d’Anton Koovit et de FontSmith.

johnsonbanks Mozilla zilla type 2

Choisie pour évoquer la police Courier, utilisée par défaut dans le code à ses débuts, Zilla suggère une impression journalistique qui renforce notre engagement à participer aux discussions relatives aux problèmes majeurs de la santé d’Internet. Elle contredit la convention actuelle des polices sans serif. Tout un chacun peut créer le logo Mozilla en saisissant du texte et en utilisant la police Zilla, rendant ainsi le logo ouvert et accessible à tous. Le trait noir qui encadre le logo est une pièce maîtresse du design, il renvoie à la façon dont nous sélectionnons le texte dans les barres de menus et les programmes.

Mozilla est le point de départ pour l’ensemble des applications de ce système à l’instar de tout protocole qui initie un voyage sur Internet. Les lignes de texte, les couleurs et les images découlent de cette source, semblables aux découvertes qui découlent d’un voyage sur le Web.

Notre palette de couleurs

Notre palette de couleurs, qui dérive des couleurs utilisées pour la surbrillance dans Firefox et dans les autres navigateurs, permet de différencier notre marque parmi ses contemporaines. La couleur se déverse dans notre logo et change en fonction du contexte dans lequel le logo est utilisé. Au fur et à mesure que nous développerons notre guide stylistique, nous définirons les associations de couleurs, les intensités et les recommandations associées.

Logo de Mozilla en différentes couleurs

Notre langage et son architecture

Le texte qui accompagne le logo, à droite ou en dessous, contient les messages clés de Mozilla. On y trouve également des programmes, des événements et des noms d’équipe, ce qui permet de simplifier et d’unifier les nombreuses activités de Mozilla. Il sera désormais plus facile de savoir que quelque chose vient de Mozilla et de comprendre comment nos initiatives mondiales sont connectées et se renforcent les unes les autres.

Ce système permet aux communautés de bénévoles Mozilla autour du monde de créer leur propre identité en sélectionnant une couleur et en choisissant des visuels qui leur sont propres. En parallèle, les éléments-clés de notre système, le cadre noir et la typographie apporteront la cohérence permettant d’afficher clairement que ces communautés font partie de Mozilla.

Mozilla architecture

Nos visuels

Au regard des éléments qui constituent l’identité de notre marque, le concept d’une image ou d’une icône représentant l’ensemble de Mozilla et la globalité d’Internet, nous a semblé anachronique. Puisque les images sont un reflet important de la diversité et de la richesse d’Internet, nous avons toutefois décidé d’en faire un élément important de notre système.

Dans le monde numérique, les visuels changent en permanence, ce qui représente l’abondance de l’écosystème en ligne. Un visuel dynamique permet à l’identité de Mozilla d’évoluer avec Internet, toujours original et nouveau. Les versions statiques de notre système d’identité incluent des images multiples, empilées les unes sur les autres, telle la capture d’un instant de cette expérience numérique mouvante.

Mozilla imagerie

Comment cela peut-il fonctionner ? Nous avons l’intention d’inviter des artistes, des designers et des spécialistes des technologies pour contribuer à la création d’un visuel collectif, ensuite nous coderons des gif, des animations et des images qui se déverseront dans mozilla.org et dans nos autres expériences numériques. À travers cette approche de design ouvert, nous engagerons de nouveaux designers (que ce soit des particuliers ou des communautés) et nous rendrons accessibles davantage d’images, toutes sous licences Creative Commons. Nous sommes à l’écoute des communautés créatives pour nous aider à mettre en forme cette idée et la développer.

Mozilla applis

Au fur et à mesure que nous développons notre système de design, nous avons hâte de connaître vos retours et vos suggestions grâce aux commentaires ci-dessous. Vous êtes avec nous depuis le début et nous sommes heureux que vous soyez là également. Nous continuerons à partager des nouvelles et des commentaires sur cet espace.

Mozilla environnemental Mozilla applis 2

Crédits photo : Porte de Brandebourg, Pierre-Selim Huard, sous licence CC By 4.0

Champs magnétiques, Windell Oskay sous licence CC By 2.0


Vidéo disponible sur la chaîne YouTube de Mozilla.



Traduction et relecture : Marine, Mozinet, Goofy, Julien “Sphinx”, Théo, Frash et anonymes

Un atelier de traduction en avril chez Mozilla

Vous traduisez ? Rejoignez-nous !

Une invitation à un atelier de traduction avec Mozilla francophone

L’équipe de bénévoles de MozFr (Mozilla francophone) fait de son mieux pour offrir aux utilisateurs les applications et la documentation de Mozilla traduites en langue française. Il s’agit principalement de :

  • MDN, la plateforme de documentation technique pour les développeurs ;
  • SUMO, le site d’aide aux utilisateurs de tous les produits Mozilla ;
  • Mozilla.org et tous les autres sites par lesquels Mozilla communique ;
  • plusieurs billets de blog traduits par la communauté ;
  • … et bien sûr Firefox et Thunderbird !

Nous organisons régulièrement des ateliers de traduction dans les locaux de Mozilla Paris (que nous appelons des locasprints), mais la prochaine session, qui aura lieu les 8 et 9 avril 2017, sera exclusivement dédiée à l’accueil de nouveaux bénévoles qui ont peu ou jamais contribué encore. L’atelier sera limité à une vingtaine de participants.

Vous serez invité⋅e à un week-end dans les locaux de Mozilla Paris (frais de transport remboursés si vous ne venez pas de la région parisienne) et dans une ambiance détendue les traducteurs aguerris vous aideront à prendre en main les outils de traduction. Un aperçu ? Voici Pontoon et Transvision.

Transvision_logo.svg

Si vous correspondez à ce profil :

  • vous lisez et comprenez couramment l’anglais qui est la langue source de nos travaux ;
  • vous maîtrisez bien voire très bien la langue française qui est la langue cible ;
  • vous avez une certaine expérience de la traduction par vos activités professionnelles ou vos études ;
  • vous souhaitez apporter à Mozilla une contribution qui ne nécessite pas de compétences particulières en informatique… mais c’est un plus si vous avez de surcroît une certaine familiarité avec les termes de l’informatique.

… alors remplissez ce simple formulaire et nous vous contacterons.

Si vous avez des questions, n’hésitez pas à nous joindre sur IRC ou sur notre liste de diffusion.

Dans les entrailles de Git

Le billet qui suit a d’abord été publié sur son blog par Nicolas Leuillet, à qui nous devons l’excellent Wallabag. Cette traduction collaborative à laquelle a participé le groupe Framalang nous a semblé intéressante pour notre blog « technique » et c’est l’occasion pour nous de lancer une invitation à tous ceux qui voudraient publier ici sur les technologies web. N’hésitez pas à nous contacter.

 

Ce billet est une traduction de l’excellent billet de Mary Rose Cook, Git from the inside out. On y apprend vraiment plein de choses sur le fonctionnement de Git.

Il se peut qu’il reste quelques coquilles, n’hésitez pas à me les signaler.

Je tiens à remercier Pierre Ozoux, goofy, Agnès H, Stéphane Hulard, Jums, Julien aka Sphinx et xi de m’avoir aidé à traduire ce très très long billet.

Cet article explique comment fonctionne Git. Il part du principe que vous comprenez suffisamment Git pour l’utiliser en tant que système de gestion de versions pour vos projets.
Cet article se concentre sur la structure de graphe sur laquelle s’appuie Git et sur la manière dont les propriétés de ce graphe dictent le comportement de Git. Revenir aux bases vous permet de visualiser les choses telles qu’elles sont réellement, et vous évite d’échafauder des hypothèses à partir du fonctionnement de l’API. Ce modèle, plus fidèle à la réalité, vous permettra de mieux comprendre ce que Git a fait, ce qu’il fait et ce qu’il fera.

Cet article est structuré comme une série de commandes Git exécutées sur un projet. Par moments, il y a des remarques à propos de la structure de données en graphe sur laquelle Git est construit. Ces remarques illustrent une propriété du graphe et le comportement provoquée par celle-ci.

Après votre lecture, si vous voulez aller plus loin avec Git, vous pouvez regarder sur le code source annoté de mon implémentation de Git en JavaScript.

Créer le projet

~ $ mkdir alpha
~ $ cd alpha

L’utilisateur crée alpha, un répertoire pour son projet.

~/alpha $ mkdir data
~/alpha $ printf 'a' > data/letter.txt

Il se rend dans le répertoire alpha et crée un répertoire data. À l’intérieur, il crée un fichier appelé letter.txt qui contient le caractère a. Le répertoire alpha ressemble donc à ceci :

alpha
└── data
    └── letter.txt

Initialisation du dépôt

~/alpha $ git init
      Dépôt Git vide initialisé

git init transforme le répertoire courant en dépôt Git. Pour faire cela, il crée un répertoire .git et écrit quelques fichiers dedans. Ces fichiers définissent tout ce qui concerne la configuration Git et l’historique du projet. Ce sont des fichiers classiques. Rien d’extraordinaire. L’utilisateur peut les lire et les éditer avec un éditeur de texte ou avec son terminal. Ce qui revient à dire : l’utilisateur peut lire et modifier l’historique de son projet aussi facilement que les fichiers du projet.

Le répertoire alpha ressemble maintenant à ça :

alpha
├── data
|   └── letter.txt
└── .git
    ├── objects
    etc.

Le répertoire .git et son contenu appartiennent à Git. Tous les autres fichiers sont considérés comme la copie de travail. Ils appartiennent à l’utilisateur.

Ajouter quelques fichiers

~/alpha $ git add data/letter.txt

L’utilisateur exécute git add sur le fichier data/letter.txt. Cela a deux effets.

Tout d’abord, cela crée un nouveau fichier binaire dans le répertoire .git/objects/.

Ce fichier binaire contient le contenu compressé de data/letter.txt. Son nom est basé sur le contenu haché du fichier. Hacher du texte veut dire qu’un programme le convertit en un texte plus petit 1 qui identifie de manière unique 2 le texte original. Par exemple, Git hache le caractère a en 2e65efe2a145dda7ee51d1741299f848e5bf752e. Les deux premiers caractères sont utilisés comme nom de répertoire dans la base de données des objets : .git/objects/2e/. Le reste du hachage est utilisé comme nom pour le fichier binaire qui contient le contenu du fichier ajouté : .git/objects/2e/65efe2a145dda7ee51d1741299f848e5bf752e.

Notez que le simple fait d’ajouter un fichier à Git sauvegarde son contenu dans le répertoire objects. Son contenu restera intact dans Git si l’utilisateur supprime le fichier data/letter.txt de sa copie de travail.

Ensuite, git add ajoute le fichier à l’index. L’index est une liste qui contient chaque fichier dont Git doit conserver une trace. Il est stocké comme fichier ici : .git/index. Chaque ligne du fichier associe un fichier suivi au hachage de son contenu au moment où il a été ajouté. Voici l’index après l’exécution de la commande git add :

data/letter.txt 2e65efe2a145dda7ee51d1741299f848e5bf752e

L’utilisateur crée un fichier appelé data/number.txt qui contient 1234.

~/alpha $ printf '1234' > data/number.txt

Le répertoire de travail correspond donc à ça :

alpha
└── data
    └── letter.txt
    └── number.txt

L’utilisateur ajoute le fichier à Git.

~/alpha $ git add data

La commande git add crée un fichier binaire qui contient le contenu de data/number.txt. Elle ajoute une entrée dans l’index pour le fichier data/number.txt qui pointe vers le fichier binaire. Voici l’index après l’exécution, pour la deuxième fois, de la commande git add :

data/letter.txt 2e65efe2a145dda7ee51d1741299f848e5bf752e
data/number.txt 274c0052dd5408f8ae2bc8440029ff67d79bc5c3

Notez que seuls les fichiers dans le répertoire data sont listés dans l’index malgré le fait que l’utilisateur ait exécuté la commande git add data. Le répertoire data n’est pas listé séparément.

~/alpha $ printf '1' > data/number.txt
~/alpha $ git add data

Quand l’utilisateur a créé data/number.txt, il voulait taper 1 et non 1234. Il effectue la correction et ajoute de nouveau le fichier à l’index. La commande crée un nouveau fichier binaire avec le nouveau contenu. Et elle met à jour l’entrée dans l’index pour data/number.txt pour pointer vers ce nouveau fichier binaire.

Faire un commit

~/alpha $ git commit -m 'a1'
          [master (commit-racine) 774b54a] a1

L’utilisateur crée le « commit » a1. Git affiche quelques infos à propos du commit. La signification de ces informations sera plus claire dans quelques paragraphes. La commande commit est faite en trois étapes. Elle crée un arbre qui représente le contenu de la version du projet à commiter. Elle crée un objet de commit. Elle pointe la branche courante sur ce nouvel objet de commit.

Créer un arbre

Git enregistre l’état courant du projet en créant un arbre depuis l’index. Cet arbre enregistre l’emplacement et le contenu de chaque fichier dans le projet.

Ce graphe est composé de deux types d’objet : des fichiers binaires et des arbres.

Les fichiers binaires sont stockés par la commande git add. Ils représentent le contenu des fichiers.

Les arbres sont stockés quand un commit est créé. Un arbre représente un répertoire dans la copie de travail.

Voici un arbre qui enregistre les contenus du répertoire data pour le nouveau commit :

100664 blob 2e65efe2a145dda7ee51d1741299f848e5bf752e letter.txt
100664 blob 56a6051ca2b02b04ef92d5150c9ef600403cb1de number.txt

La première ligne enregistre tout ce qui est nécessaire pour reproduire le fichier data/letter.txt. La première partie correspond aux permissions du fichier. La seconde partie correspond au contenu de l’entrée, représentée par un fichier binaire plutôt que par un arbre. La troisième partie correspond à l’empreinte du fichier binaire. La quatrième partie correspond au nom du fichier.

La deuxième enregistre la même chose pour data/number.txt.

Voici un arbre pour le répertoire alpha, qui est le répertoire racine du projet :

040000 tree 0eed1217a2947f4930583229987d90fe5e8e0b74 data

La seule ligne dans cet arbre pointe vers l’arbre data.

L'arbre pour le commit a1

Image : L’arbre pour le commit a1

Dans le graphe ci-dessus, l’arbre root pointe vers l’arbre data. L’arbre data pointe vers les fichiers binaires pour data/letter.txt et data/number.txt.

Créer un objet de commit

git commit crée un objet de commit après la création de l’arbre. L’objet de commit est simplement un autre fichier texte dans .git/objects/.

tree ffe298c3ce8bb07326f888907996eaa48d266db4
author Mary Rose Cook <mary@maryrosecook.com> 1424798436 -0500
committer Mary Rose Cook <mary@maryrosecook.com> 1424798436 -0500

a1

La première ligne pointe vers l’arbre. L’empreinte correspond à l’objet qui représente la racine de la copie de travail, c’est-à-dire le répertoire alpha. La dernière ligne correspond au commit.

L'objet pour le commit a1 qui pointe vers son arbre

Image : L’objet pour le commit a1 qui pointe vers son arbre

Placer la branche actuelle sur le nouveau commit

Finalement, la commande commit place la branche courante sur le nouvel objet commit. Quelle est la branche actuelle ? Git va dans le fichier HEAD se trouvant dans .git/HEAD et trouve :

ref: refs/heads/master

Cela signifie que HEAD pointe sur master. master est la branche actuelle. HEAD et master sont toutes les deux des références. Une référence est un libellé utilisé par Git ou l’utilisateur pour identifier un commit spécifique. Ce fichier que représente la référence master n’existe pas, parce que c’est le premier commit dans le dépôt. Git crée le fichier .git/refs/heads/master et y inscrit l’empreinte de l’objet de commit :

74ac3ad9cde0b265d2b4f1c778b283a6e2ffbafd

(Si vous exécutez ces commandes Git pendant que vous lisez, l’empreinte de votre commit a1 sera différente de celle que j’ai obtenue ici. Les objets de contenu comme les fichiers binaires et les arbres sont toujours hachés avec la même valeur. En revanche, l’empreinte d’un commit peut varier car un commit inclut une date et le nom de son créateur.)

Ajoutons HEAD et master sur le graphe Git :

HEAD pointant sur master et master pointant sur le commit a1

Image : HEAD pointant sur master et master pointant sur le commit a1

HEAD pointe sur master, comme elle le faisait avant le commit. Mais désormais, master existe et pointe sur le nouvel objet de commit.

Créer un commit qui n’est pas le premier commit

Ci-dessous, on voit le graphe Git après le commit a1 avec le contenu de la copie de travail et l’index.

Le commit a1, affiché avec la copie de travail et l'index

Image : Le commit a1, affiché avec la copie de travail et l’index

Notez que la copie de travail, l’index et le commit a1 ont tous le même contenu pour data/letter.txt et data/number.txt. L’index et le commit HEAD utilisent tous les deux des empreintes pour se référer aux objets binaires, mais le contenu de la copie de travail est stockée sous forme de texte dans un autre endroit.

~/alpha $ printf '2' > data/number.txt

L’utilisateur initialise le contenu de data/number.txt à 2. Cette action met à jour la copie de travail mais laisse l’index et le commit HEAD tels quels.

data/number.txt initialisé à 2 dans la copie de travail

Image : data/number.txt initialisé à 2 dans la copie de travail

~/alpha $ git add data/number.txt

L’utilisateur ajoute le fichier à Git. Cela rajoute un fichier binaire qui contient 2 dans le répertoire objects. Il pointe sur l’entrée de l’index pour data/number.txt sur le nouvel objet binaire.

`data/number.txt` initialisé à `2` dans la copie de travail et dans l'index

Image : data/number.txt initialisé à 2 dans la copie de travail et dans l’index

~/alpha $ git commit -m 'a2'
          [master f0af7e6] a2

L’utilisateur ajoute un commit. Les étapes pour le commit sont les mêmes que précédemment.

Tout d’abord, un nouvel arbre/graphe est créé pour représenter le contenu de l’index.

Dans l’index, l’entrée pour data/number.txt a changé. L’ancien arbre data ne correspond plus à l’état indexé du repertoire data. Un nouvel arbre data doit être créé :

  100664 blob 2e65efe2a145dda7ee51d1741299f848e5bf752e letter.txt
100664 blob d8263ee9860594d2806b0dfd1bfd17528b0ba2a4 number.txt

La nouvelle empreinte (hash) correspondant à l’arbre data est différente de la précédente. Un nouvel arbre root doit être créé pour enregistrer cette nouvelle empreinte :

040000 tree 40b0318811470aaacc577485777d7a6780e51f0b data

Deuxièmement, un nouvel objet de commit est créé.

tree ce72afb5ff229a39f6cce47b00d1b0ed60fe3556
parent 774b54a193d6cfdd081e581a007d2e11f784b9fe
author Mary Rose Cook <mary@maryrosecook.com> 1424813101 -0500
committer Mary Rose Cook <mary@maryrosecook.com> 1424813101 -0500

a2

La première ligne de ce commit pointe vers le nouvel arbre root. La deuxième ligne pointe vers a1 : le commit parent. Pour trouver le commit parent, Git est allé sur la référence HEAD puis a suivi sur master et a trouvé l’empreinte du commit a1.
Troisièmement, Git inscrit l’empreinte du nouveau commit dans le fichier qui décrit la branche master.

Le commit `a2`

Image : Le commit a2

Le graphe Git, sans index ni copie de travail

Image : Le graphe Git, sans index ni copie de travail

Propriété du graphe : le contenu est stocké en tant qu’arbre d’objets. Ce qui signifie que seules les différences entre les objets sont stockées dans la base de données des objets. Observez le graphe ci-dessus. Le commit a2 réutilise le fichier binaire qui a été créé avant le commit a1. Si le répertoire entier reste inchangé de commit en commit, alors son arbre et tous les blobs et arbres enfants pourront être réutilisés. En général, il n’y a que peu de changements d’un commit à un autre. Cela signifie que Git peut stocker un large historique de commits dans un très petit espace.

Propriété du graphe : chaque commit a un parent. Ce qui signifie qu’un répertoire peut stocker l’historique du projet.

Propriété du graphe : les références (ref) sont les points d’entrée vers une partie de l’historique de commit. Cela signifie qu’un commit peut être nommé de façon adéquate. L’utilisateur peut organiser son travail sous la forme de lignées de commits pertinentes pour un projet et les intituler avec des références concrètes, par exemple fix-for-bug-376. Git utilise des références symboliques telles que HEAD, MERGE_HEAD et FETCH_HEAD pour les commandes qui manipulent l’historique des commits.

Propriété du graphe : les nœuds du répertoire objects/ sont immuables. Ceci signifie que le contenu est édité, pas effacé. Tout ce qui a jamais été ajouté et tous les commits qui ont été réalisés se trouvent quelque part dans le répertoire objects3.

Propriété du graphe : les références (refs) sont modifiables. Par conséquent, la signification d’une référence peut changer. Le commit vers lequel pointe la branche master peut être la meilleure version existante d’un projet, mais très vite, il sera remplacé par un meilleur commit plus récent.

Propriété du graphe : la copie de travail et les commits vers lesquels pointent les références sont facilement accessibles mais les autres commits ne le sont pas. Ceci signifie que l’historique récent est plus facilement accessible, mais aussi qu’il change plus souvent. Autrement dit, Git a une mémoire vacillante qui doit souvent être rafraîchie.

La copie de travail est le point de l’historique le plus facile à accéder parce qu’elle est à la racine du répertoire. Y accéder ne nécessite même pas l’utilisation d’une commande Git. C’est aussi le point le moins fixe de l’historique. L’utilisateur peut faire une dizaine de versions d’un fichier mais Git n’en enregistrera aucune à moins qu’elles ne soient ajoutées.

On peut très facilement se souvenir du commit sur lequel pointe HEAD. Cette référence est à l’extrémité de la branche sur laquelle on travaille. Pour voir son contenu, l’utilisateur peut mettre de côté (stash)4 ses modifications et examiner la copie de travail. La référence HEAD est donc également celle qui change le plus souvent.

On peut facilement se souvenir du commit sur lequel pointe une référence concrète. Pour ce faire, l’utilisateur peut simplement basculer sur la branche correspondante. L’extrémité d’une branche évolue moins fréquemment que HEAD mais suffisamment pour que le nom de la branche traduise quelque chose qui évolue.

Il est plus difficile de se rappeler un commit pour lequel il n’existe aucune référence. Plus on s’écarte d’une référence, plus il est difficile de reconstituer le sens d’un commit. Cela dit, plus on s’éloigne d’une référence, moins il y a de chances que quelqu’un ait modifié l’historique depuis la dernière fois qu’on l’a consulté5.

Basculer sur un commit

~/alpha $ git checkout 37888c2
          You are in 'detached HEAD' state...

L’utilisateur bascule sur le commit a2 en utilisant son empreinte. (Si vous lancez cette commande Git telle quelle, elle ne fonctionnera pas. Vous devez utiliser git log afin de trouver l’empreinte qui correspond au commit a2.)

Le basculement se fait en quatre étapes.

Premièrement, Git récupère le commit a2 et le graphe vers lequel il pointe.

Deuxièmement, il écrit les fichiers listés dans le graphe dans la copie de travail. Ici, cela ne produit aucune modification car la copie de travail contient déjà les mêmes fichiers que le graphe car HEAD pointait déjà, via la branche master, sur le commit a2.

Troisièmement, Git écrit la liste des fichiers du graphe dans l’index. Là encore, aucune modification n’est appliquée. L’index contient déjà le contenu du commit a2.

Enfin, lors de la quatrième étape, HEAD est mis à jour avec l’empreinte du commit a2 :

f0af7e62679e144bb28c627ee3e8f7bdb235eee9

Lorsque le contenu de HEAD est défini avec une empreinte, le dépôt est dans un état où la tête (HEAD) est détachée. On voit dans le schéma ci-après que HEAD pointe directement sur le commit a2 plutôt que de pointer vers master.

La référence `HEAD`, détachée, sur le commit `a2`

Image : La référence HEAD, détachée, sur le commit a2

~/alpha $ printf '3' > data/number.txt
~/alpha $ git add data/number.txt
~/alpha $ git commit -m 'a3'
          [HEAD détachée 3645a0e] a3

L’utilisateur écrit 3 dans le fichier data/number.txt puis ajoute un commit pour cette modification. Git utilise la référence HEAD pour obtenir le parent du commit a3. Plutôt que de trouver une référence de branche, Git trouve et renvoie l’empreinte du commit a2.

Git met à jour la référence HEAD pour qu’elle pointe directement sur l’empreinte du commit a3. Le depôt est alors toujours dans un état où HEAD est détachée. Elle n’est pas sur une branche car aucune référence de branche ne pointe sur le commit a3 ou l’un de ses descendants. Cela signifie qu’on peut facilement perdre le travail en cours.

À partir de maintenant, la plupart des schémas n’incluront plus les arbres et les blobs.

Le commit `a3` qui n'est pas sur une branche

Image : Le commit a3 qui n’est pas sur une branche

Créer une branche

~/alpha $ git branch deputy

Avec cette commande, l’utilisateur crée une nouvelle branche intitulée deputy. Cette opération crée simplement un nouveau fichier situé sous .git/refs/heads/deputy et qui contient l’empreinte vers laquelle HEAD pointe, c’est-à-dire l’empreinte du commit a3.

Propriété du graphe : les branches sont simplement des références (refs) et les références sont simplement des fichiers. Cela signifie que les branches Git sont légères.

La création de la branche deputy permet d’enregistrer le commit a3 de façon sûre, sur une branche. HEAD est toujours détachée car elle pointe toujours directement vers un commit.

Le commit `a3`, désormais sur la branche `deputy`

Image : Le commit a3, désormais sur la branche deputy

Basculer sur une branche

~/alpha $ git checkout master
          Basculement sur la branche 'master'

L’utilisateur bascule sur la branche master.

Pour commencer, Git récupère le commit a2 vers lequel pointe la branche master puis il récupère le graphe sur lequel pointe le commit.

Ensuite, dans la copie de travail, Git écrit le contenu des fichiers qui sont listés dans le graphe. Ainsi, il écrit 2 dans le fichier data/number.txt.

Lors d’une troisième étape, Git écrit la liste des fichiers du graphe dans l’index. Dans l’index, l’élément pour le fichier data/number.txt pointe désormais vers l’empreinte du blob 2.

Enfin, Git fait pointer la référence HEAD sur master en modifiant son contenu :

ref: refs/heads/master

Basculement sur `master` et pointage vers le commit `a2`

Image : Basculement sur master et pointage vers le commit a2

Basculer sur une branche incompatible avec la copie de travail

~/alpha $ printf '789' > data/number.txt
~/alpha $ git checkout deputy
          Your local changes to the following files would be overwritten
          by checkout:
            data/number.txt
          Commit your changes or stash them before you
          switch branches.

L’utilisateur écrit par erreur 789 dans le fichier dans data/number.txt puis essaie de basculer sur la branche deputy. Git empêche le basculement.

La référence HEAD pointe sur la branche master qui pointe vers le commit a2data/number.txt contient 2. La branche deputy pointe vers le commit a3data/number.txt contient 3. Dans la copie de travail, data/number.txt contient 789. Toutes ces versions sont différentes et ces différences doivent être résolues.

Git pourrait remplacer la version du fichier data/number.txt de la copie de travail par celle qui correspond au commit sur lequel on bascule mais il empêche à tout prix de perdre des données.

Git pourrait fusionner la version de la copie de travail avec la version sur laquelle on bascule… mais c’est compliqué.

C’est pour ça que Git interrompt le basculement.

~/alpha $ printf '2' > data/number.txt
~/alpha $ git checkout deputy
          Basculement sur la branche 'deputy'

L’utilisateur remarque qu’il a édité data/number.txt par accident puis réécrit 2 dans le fichier. Il peut alors basculer sans problème.

Basculement sur `deputy`

Image : Basculement sur deputy

Fusionner un commit qui est un ancêtre

~/alpha $ git merge master
          Already up-to-date.

L’utilisateur fusionne la branche master sur la branche deputy. Fusionner deux branches signifie qu’on fusionne deux commits. Le premier commit est celui sur lequel pointe la branche deputy : c’est le commit receveur. Le deuxième commit est celui sur lequel point la branche master : c’est le commit donneur. Pour cette fusion, Git n’a rien à faire et c’est ce qu’il indique : Already up-to-date (déjà à jour).

Propriété du graphe : la succession de commits du graphe est interprétée comme une succession de modifications à appliquer au contenu du dépôt. Cela signifie que, lors d’une fusion, si le commit donneur est un ancêtre du commit receveur, Git n’a rien à faire : les modifications concernées ont déjà été intégrées au dépôt.

Fusionner un commit qui est un descendant

~/alpha $ git checkout master
          Basculement sur la branche 'master'

L’utilisateur bascule sur la branche master.

Basculement sur `master` qui pointe sur le commit `a2`

Image : Basculement sur master qui pointe sur le commit a2

~/alpha $ git merge deputy
          Fast-forward

Grâce à cette commande, l’utilisateur fusionne la branche deputy avec la branche master. Git analyse et comprend que le commit receveur, a2, est un ancêtre du commit donneur, a3. Il peut donc appliquer une fusion en avance rapide (fast-forward merge).

Git récupère le commit donneur et l’arbre correspondant. Il écrit les fichiers du graphe dans la copie de travail et dans l’index puis effectue une avance rapide pour pointer sur le commit a3.

Le commit `a3` de la branche `deputy`, fusionné en avance rapide sur la branche `master`

Image : Le commit a3 de la branche deputy, fusionné en avance rapide sur la branche master

Propriété du graphe : les suites de commits du graphe sont interprétées comme une suite de modifications appliquées sur le contenu du dépôt. Cela signifie que pendant une fusion, si le commit donneur est un descendant du commit receveur, l’historique n’est pas modifié. Il existe déjà une succession de commits qui décrit les modifications à réaliser : ce sont les commits situés entre le commit receveur et le commit donneur. Toutefois, si l’historique Git ne change pas, le graphe Git, lui, change. La référence concrète vers laquelle pointe HEAD est mise à jour pour correspondre au commit donneur.

Fusionner deux commits ayant des historiques différents

~/alpha $ printf '4' > data/number.txt
~/alpha $ git add data/number.txt
~/alpha $ git commit -m 'a4'
          [master 7b7bd9a] a4

L’utilisateur écrit 4 dans le fichier number.txt puis ajoute un commit pour cette modification sur la branche master.

~/alpha $ git checkout deputy
          Basculement sur la branche 'deputy'
~/alpha $ printf 'b' > data/letter.txt
~/alpha $ git add data/letter.txt
~/alpha $ git commit -m 'b3'
          [deputy 982dffb] b3

Avec ces instructions, l’utilisateur bascule sur la branche deputy puis écrit b dans le fichier data/letter.txt et ajoute un commit pour cette modification sur la branche deputy.

Le commit `a4` appliqué sur `master`, le commit `b3` ajouté sur `deputy` et le basculement sur `deputy`

Image : Le commit a4 appliqué sur master, le commit b3 ajouté sur deputy et le basculement sur deputy.

Propriété du graphe : les commits peuvent partager un même parent. Cela signifie que de nouveaux historiques peuvent être créés.

Propriété du graphe : un commit peut avoir plusieurs parents. Cela signifie que deux historiques peuvent être fusionnés par un commit qui possède deux parents, c’est ce qu’on appelle un commit de fusion.

~/alpha $ git merge master -m 'b4'
          Merge made by the 'recursive' strategy.

Ici, l’utilisateur fusionne la branche master avec la branche deputy.

Git découvre que le commit receveur, b3 et que le commit donneur, a4, ont chacun un historique différent. Il crée un commit de fusion. Ce processus se déroule selon huit étapes.

Tout d’abord, Git écrit l’empreinte du commit donneur dans le fichier alpha/.git/MERGE_HEAD. Ce fichier, lorsqu’il existe, indique que Git est en train d’effectuer une fusion.

Ensuite, Git détermine le commit de base : c’est le plus proche ancêtre commun au commit donneur et au commit receveur.

`a3`, le commit de base pour `a4` et `b3`

Image : a3, le commit de base pour a4 et b3

Propriété du graphe : les commits ont des parents. Cela signifie qu’on peut déterminer le point à partir duquel deux historiques ont divergé. Git remonte l’historique de b3 pour trouver ses ancêtres et fait de même avec a4 pour trouver les ancêtres de a4. Il trouve alors l’ancêtre le plus récent, présent dans les deux historiques : a3. Ce commit est le commit de base.

Dans un troisième temps, Git génère trois index pour le commit de base, le commit donneur et le commit receveur grâce à leurs graphes respectifs.

Lors de la quatrième étape, Git génère une différence qui combine les modifications appliquées à la base par le commit receveur d’une part et le commit donneur d’autre part. Cette différence est une liste de chemins de fichiers qui identifient un changement : un ajout, une suppression, une modification ou un conflit.

Pour la construire, Git dresse la liste de tous les fichiers qui apparaissent dans les index du commit de base, du commit receveur et du commit donneur. Pour chacune, il compare les éléments de l’index pour choisir le changement à appliquer au fichier et il écrit l’élément correspondant dans la différence. Dans cet exemple, la différence possède deux éléments.

Le premier élément concerne data/letter.txt. Le contenu de ce fichier vaut a pour le commit de base, b pour le commit receveur et a pour le commit donneur. Le contenu est donc différent entre la base et le receveur mais est le même entre la base et le donneur. Git détecte que le contenu a été modifié par le receveur mais pas par le donneur. Aussi, l’élément de la liste des différences pour data/letter.txt est une modification (ce n’est pas un conflit).

Le deuxième élément se rapporte à data/number.txt. Dans ce cas, le contenu est le même entre la base et le receveur et il est différent dans le donneur. L’élément de la liste des différences pour le fichier data/letter.txt est également une modification.

Propriété du graphe : il est possible de déterminer le commit de base d’une fusion. Cela signifie que si un fichier a évolué depuis le commit de base mais uniquement sur le receveur ou sur le donneur, Git peut automatiquement résoudre la fusion pour ce fichier. Cela diminue le travail laissé à l’utilisateur.

Cinquièmement, les modifications indiquées dans la liste des différences (diff) sont appliquées sur la copie de travail. Le contenu de data/letter.txt vaut désormais b et le contenu de data/number.txt vaut désormais 4.

Sixièmement, les modifications indiquées dans la liste des différences sont appliquées à l’index. L’entrée pour data/letter.txt pointe désormais vers le blob b et l’entrée pour data/number.txt pointe désormais vers le blob 4.

Septièmement, l’index mis à jour est commité :

tree 20294508aea3fb6f05fcc49adaecc2e6d60f7e7d
parent 982dffb20f8d6a25a8554cc8d765fb9f3ff1333b
parent 7b7bd9a5253f47360d5787095afc5ba56591bfe7
author Mary Rose Cook <mary@maryrosecook.com> 1425596551 -0500
committer Mary Rose Cook <mary@maryrosecook.com> 1425596551 -0500

b4

On peut remarquer ici que le commit possède deux parents.

À la huitième et dernière étape, Git fait pointer la branche courante, deputy, sur le nouveau commit.

`b4`, le commit de fusion obtenu suite à la fusion récursive de `a4` sur `b3`

Image : b4, le commit de fusion obtenu suite à la fusion récursive de a4 sur b3

Fusionner deux commits ayant un historique différent et qui modifient le même fichier

~/alpha $ git checkout master
          Basculement sur la branche 'master'
~/alpha $ git merge deputy
          Fast-forward

L’utilisateur bascule sur la branche master puis fusionne la branche master. Cela propage la branche master en avance rapide jusqu’au commit b4. Les branches master et deputy pointent désormais vers le même commit.

La branche `deputy`, fusionnée avec `master` permet d'amener `master` au dernier commit, `b4`

Image : La branche deputy, fusionnée avec master permet d’amener master au dernier commit, b4.

~/alpha $ git checkout deputy
          Basculement sur la branche 'deputy'
~/alpha $ printf '5' > data/number.txt
~/alpha $ git add data/number.txt
~/alpha $ git commit -m 'b5'
          [deputy bd797c2] b5

L’utilisateur bascule sur la branche deputy puis ajoute un fichier data/number.txt qui contient 5 et ajoute un commit sur deputy pour enregistrer cette modification.

~/alpha $ git checkout master
          Basculement sur la branche 'master'
~/alpha $ printf '6' > data/number.txt
~/alpha $ git add data/number.txt
~/alpha $ git commit -m 'b6'
          [master 4c3ce18] b6

L’utilisateur bascule sur master. Il définit un fichier data/number.txt qui contient 6 et ajoute un commit sur master pour cette modification.

Le commit `b5` sur `deputy` et le commit `b6` sur `master`

Image : Le commit b5 sur deputy et le commit b6 sur master.

~/alpha $ git merge deputy
          CONFLIT (contenu) : Conflit de fusion dans data/number.txt
          La fusion automatique a échoué ; réglez les conflits et validez le résultat.

L’utilisateur fusionne deputy et master. Il y a un conflit et la fusion est donc interrompue. Lorsqu’un conflit se produit, les 6 premières étapes sont les mêmes que lors d’une fusion sans conflit : on définit .git/MERGE_HEAD, on trouve le commit de base, on génère les index de la base, les commits donneurs et receveurs, on crée un diff, on met à jour la copie de travail et l’index. Étant donné le conflit, la septième étape de commit et la huitième qui met à jour la référence n’ont jamais lieu. Revoyons les étapes pour voir ce qui se passe exactement.

Pour commencer, Git écrit l’empreinte du commit donneur dans un fichier .git/MERGE_HEAD.

L'écriture de `MERGE_HEAD` lors de la fusion de `b5` sur `b6`

_Image : L’écriture de MERGE_HEAD lors de la fusion de b5 sur b6_

Ensuite, Git identifie le commit de base : b4.

Lors de la troisième étape, Git génère les index pour le commit de base, le commit donneur et le commit receveur.

À la quatrième étape, Git génère une différence (diff) qui combine les modifications appliquées à la base par le commit receveur d’une part et par le commit donner d’autre part. Cette différence est une liste de chemins de fichiers qui traduisent un changement : un ajout, une suppression, une modification ou un conflit.

Dans notre cas, la différence ne contient qu’un seul élément : data/number.txt. Cet élément est identifié comme un conflit car le contenu de data/number.txt est différent entre le receveur, le donneur et la base.

Ensuite, à la cinquième étape, les modifications indiquées pour chacun des éléments de la différence sont appliquées à la copie de travail. Lorsqu’il s’agit d’un conflit, Git écrit les deux versions du fichier dans la copie de travail. Le contenu de data/number.txt vaut alors :

<<<<<<< HEAD
6
=======
5
>>>>>>> deputy

À la sixième étape, les modifications listées pour les éléments de la différence sont appliquées à l’index. Les éléments de l’index sont identifiés de façon unique grâce à une combinaison de leur chemin et de leur niveau. Le niveau correspondant à un fichier sans conflit est 0. Avant cette fusion, l’index ressemblait à ceci, les 0 correspondant aux niveaux :

0 data/letter.txt 63d8dbd40c23542e740659a7168a0ce3138ea748
0 data/number.txt 62f9457511f879886bb7728c986fe10b0ece6bcb

Après l’écriture de la différence relative à la fusion dans l’index, l’index ressemble à ceci :

0 data/letter.txt 63d8dbd40c23542e740659a7168a0ce3138ea748
1 data/number.txt bf0d87ab1b2b0ec1a11a3973d2845b42413d9767
2 data/number.txt 62f9457511f879886bb7728c986fe10b0ece6bcb
3 data/number.txt 7813681f5b41c028345ca62a2be376bae70b7f61

L’élément pour data/letter.txt de niveau 0 est le même qu’avant la fusion. Il n’y a plus d’élément data/number.txt de niveau 0 mais trois nouveaux éléments à la place. L’élément de niveau 1 contient l’empreinte du contenu de data/number.txt pour le commit de base. L’élément de niveau 2 contient l’empreinte du contenu de data/number.txt pour le commit receveur. Celui de niveau trois contient l’empreinte du contenu de data/number.txt pour le commit donneur. La présence de ces trois éléments permet à Git d’identifier un conflit pour le fichier data/number.txt.

Le processus de merge s’arrête.

~/alpha $ printf '11' > data/number.txt
~/alpha $ git add data/number.txt

Ici l’utilisateur intègre le contenu des deux versions conflictuelles en écrivant 11 dans data/number.txt. Ensuite, il ajoute le fichier à l’index. Git ajoute un blob qui contient 11. L’ajout d’un fichier en conflit indique à Git que le conflit est résolu. Aussi, Git retire les éléments de niveaux 1, 2 et 3 dans l’index qu’il remplace par une nouvelle ligne de niveau 0 contenant l’empreinte du nouveau blob. L’index contient désormais les lignes suivantes :

0 data/letter.txt 63d8dbd40c23542e740659a7168a0ce3138ea748
0 data/number.txt 9d607966b721abde8931ddd052181fae905db503

~/alpha $ git commit -m 'b11'
          [master 251a513] b11

Lors de la septième étape, l’utilisateur ajoute un commit. Git voit le fichier .git/MERGE_HEAD dans le dépôt et sait donc qu’une fusion est en cours. Il vérifie l’index et ne trouve aucun conflit, il crée alors un nouveau commit, b11, pour enregistrer le contenu de la fusion pour laquelle le conflit a été résolu. Il supprime le fichier .git/MERGE_HEAD. La fusion est alors terminée.

Enfin, à la huitième étape, Git fait pointer la branche courante, master, sur le dernier commit.

`b11`, le commit de fusion provenant de la fusion récursive conflictuelle entre `b5` et `b6`

Image : b11, le commit de fusion provenant de la fusion récursive conflictuelle entre b5 et b6

Supprimer un fichier

Le diagramme de ce graphe Git contient l’historique des commits, les arbres et les blobs du dernier commit, ainsi que la copie de travail et l’index :

La copie de travail, l'index, le commit `b11` et son graphe

Image : La copie de travail, l’index, le commit b11 et son graphe

~/alpha $ git rm data/letter.txt
          rm 'data/letter.txt'

L’utilisateur indique à Git de supprimer data/letter.txt. Le fichier est supprimé de la copie de travail et l’entrée est supprimée de l’index.

L'état après la suppression de `data/letter.txt` de la copie de travail et de l'index.

Image : L’état après la suppression de data/letter.txt de la copie de travail et de l’index.

~/alpha $ git commit -m '11'
          [master d14c7d2] 11

L’utilisateur ajoute un commit. Comme toujours avec le commit, Git construit l’arbre qui représente le contenu de l’index. data/letter.txt n’est pas inclus dans cet arbre car il n’est pas dans l’index.

Le commit `11` réalisé après la suppression de `data/letter.txt`

Image : Le commit 11 réalisé après la suppression de data/letter.txt

Copier un dépôt

~/alpha $ cd ..
~ $ cp -R alpha bravo

L’utilisateur copie le contenu du répertoire alpha/ dans le répertoire bravo/. On obtient alors l’arborescence de fichiers suivante :

~
├── alpha
|   └── data
|       └── number.txt
└── bravo
    └── data
        └── number.txt

Il y a désormais un autre graphe Git dans le répertoire bravo :

Le nouveau graphe créé lorsqu’`alpha` est copié en `bravo` avec `cp`

Image : Le nouveau graphe créé lorsqu’alpha est copié en bravo avec cp

Lier un dépôt à un autre dépôt

~ $ cd alpha
~/alpha $ git remote add bravo ../bravo

L’utilisateur retourne dans le dépôt alpha. Ensuite, il définit bravo, un dépôt distant de alpha. Cette opération ajoute les lignes suivantes au fichier alpha/.git/config :

[remote "bravo"]
    url = ../bravo/

Ces lignes signifient qu’il y a un dépôt distant appelé bravo et que celui-ci se situe à l’emplacement ../bravo.

Récupérer une branche depuis un dépôt distant

~/alpha $ cd ../bravo
~/bravo $ printf '12' > data/number.txt
~/bravo $ git add data/number.txt
~/bravo $ git commit -m '12'
          [master 94cd04d] 12

L’utilisateur se déplace dans le dépôt bravo puis crée un fichier data/number.txt qui contient 12 puis ajoute un commit pour cette modification sur la branche master de bravo.

Le commit `12` sur le dépôt `bravo`

Image : Le commit 12 sur le dépôt bravo

~/bravo $ cd ../alpha
~/alpha $ git fetch bravo master
          Dépaquetage des objets : 100%
          Depuis ../bravo
            * branch master -> FETCH_HEAD

L’utilisateur se déplace dans le dépôt alpha. Il récupère ensuite la branche master depuis le dépôt bravo vers alpha. Cette récupération se fait en quatre étapes.

Pour commencer, Git récupère l’empreinte (hash) du commit sur lequel pointe la branche master du dépôt bravo. C’est l’empreinte du commit 12.

Ensuite, Git dresse la liste de tous les objets dont dépend le commit 12 : l’objet même qui décrit le commit, les objets qui sont sur son graphe, les commits ancêtres du commit 12 et les objets qui sont dans leurs graphes. Il retire alors de cette liste tous les objets déjà contenus dans la base de données des objets de alpha. Ce qui reste est copié dans alpha/.git/objects/.

La troisième étape consiste à modifier le fichier de référence alpha/.git/refs/remotes/bravo/master afin qu’il contienne l’empreinte du commit 12.

Enfin, le contenu de alpha/.git/FETCH_HEAD est défini avec :

94cd04d93ae88a1f53a4646532b1e8cdfbc0977f branch 'master' of ../bravo

Cette ligne indique que la commande fetch la plus récente a récupéré le commit 12 de la branche master depuis bravo.

`alpha` après avoir récupéré `bravo/master`

Image : alpha après avoir récupéré bravo/master

Propriété de graphe : les objets peuvent être copiés. Cela veut dire que l’historique peut être partagé entre les dépôts.

Propriété de graphe : un dépôt peut stocker des références à des branches distantes comme alpha/.git/refs/remotes/bravo/master. Cela veut dire qu’un dépôt peut enregistrer localement l’état d’une branche ou d’un dépôt distant. C’est valable au moment où on le récupère mais ça sera périmé quand la branche distante changera.

Fusionner FETCH_HEAD

~/alpha $ git merge FETCH_HEAD
          Mise à jour d14c7d2..94cd04d
          Fast-forward

L’utilisateur fusionne FETCH_HEAD. FETCH_HEAD est simplement une autre référence. Elle correspond ici au commit 12, celui qui est donné. La référence HEAD correspond au commit 11, celui qui reçoit. Git fait une fusion en avance rapide (fast-forward merge) et fait pointer la branche master sur le commit 12.

Le dépôt `alpha` après la fusion avec `FETCH_HEAD`

_Image : Le dépôt alpha après la fusion avec FETCH_HEAD_

Tirer une branche depuis un dépôt distant

~/alpha $ git pull bravo master
          Already up-to-date.

Ici, l’utilisateur tire la branche master depuis le dépôt bravo vers le dépôt alpha. pull est un raccourci pour « récupère puis fusionne FETCH_HEAD » (fetch/merge). Git applique ces deux commandes puis indique que la branche master est déjà à jour.

Cloner un dépôt

~/alpha $ cd ..
~ $ git clone alpha charlie
          Clonage dans 'charlie'

Là, l’utilisateur remonte dans le dossier parent puis clone le dédpôt alpha vers un dépôt charlie. Cloner le dépôt vers charlie permet d’obtenir des résultats similaires à la copie (via cp) utilisée pour créer le dépôt bravo. Ici, Git crée un nouveau répertoire appelé charlie. Il initialise ce dossier en tant que dépôt Git puis ajoute alpha comme un dépôt distant, appelé origin. Il récupère (fetch) le contenu de origin puis fusionne FETCH_HEAD.

Pousser une branche vers une branche distante utilisée

~ $ cd alpha
~/alpha $ printf '13' > data/number.txt
~/alpha $ git add data/number.txt
~/alpha $ git commit -m '13'
      [master 3238468] 13

L’utilisateur retourne dans le dépôt alpha, ajoute un fichier data/number.txt qui contient 13 puis ajoute un commit pour cette modification sur la branche master sur le dépôt alpha.

~/alpha $ git remote add charlie ../charlie

Ensuite, il ajoute un dépôt charlie qui est un dépôt distant d’alpha.

~/alpha $ git push charlie master
          Écriture des objets : 100%
          remote error: refusing to update checked out
          branch: refs/heads/master because it will make
          the index and work tree inconsistent

Enfin, il pousse la branche master vers charlie.

Tous les objets nécessaires au commit 13 sont copiés dans charlie.

À cette étape, le push s’arrête. Git, comme à son habitude, indique à l’utilisateur qu’il y a un problème. Il refuse de pousser vers une branche utilisée sur le dépôt distant. C’est plutôt logique, une opération push mettrait à jour l’index du dépôt distant et son commit HEAD. Cette modification serait source de confusion si quelqu’un éditait la version de travail sur le dépôt distant.

Ici, l’utilisateur, pourrait créer une nouvelle branche, fusionner ce commit 13 sur cette branche puis pousser cette branche vers le dépôt charlie. En fait, ce qu’il veut, c’est un dépôt vers lequel pousser à tout moment, un dépôt central vers lequel on peut pousser ou depuis lequel on peut tirer des branches, sans personne qui n’y ajoute de commits directement. Bref, il veut quelque chose qui se comporte comme GitHub : c’est ce qu’on appelle un dépôt nu (bare).

Cloner un dépôt nu

~/alpha $ cd ..
~ $ git clone alpha delta --bare
          Clonage dans le dépôt nu 'delta'

Ici, l’utilisateur se déplace dans le répertoire parent. Ensuite, il clone le dépôt alpha dans un dépôt delta, indiqué comme un dépôt nu (bare repository). C’est un clone classique avec deux différences notables : le fichier de configuration indique que le dépôt est un dépôt nu et les fichiers normalement stockés dans le dossier .git sont ici stocké à la racine du répertoire :

delta
├── HEAD
├── config
├── objects
└── refs

Les graphes d’`alpha` et de `delta` après le clonage dans `delta`

Image : Les graphes d’alpha et de delta après le clonage dans delta

Pousser une branche vers un dépôt nu

~ $ cd alpha
~/alpha $ git remote add delta ../delta

L’utilisateur retourne dans le dépôt alpha puis définit delta comme un dépôt distant sur alpha.

~/alpha $ printf '14' > data/number.txt
~/alpha $ git add data/number.txt
~/alpha $ git commit -m '14'
          [master cb51da8] 14

Ces instructions ajoutent un fichier data/number.txt (dont le contenu est 14) puis ajoutent un commit sur la branche master du dépôt alpha.

Le commit `14` sur `alpha`

Image : Le commit 14 sur alpha

~/alpha $ git push delta master
      Écriture des objets : 100%
      To ../delta
        3238468..cb51da8 master -> master

Ici, on pousse les données de master vers delta. Cela se fait en trois étapes.

Tout d’abord, tous les objets nécessaires au commit 14 de la branche master sont copiés de alpha/.git/objects/ vers delta/objects.

Ensuite, delta/refs/heads/master est mis à jour pour pointer au commit 14.

Troisièmement, alpha/.git/refs/remotes/delta/master pointe vers le commit 14. alpha a ainsi un état à jour de delta.

Le commit `14` poussé depuis `alpha` vers `delta`

Image : Le commit 14 poussé depuis alpha vers delta

Résumé

Git est construit sur un graphe. Presque toutes les commandes Git manipulent ce graphe. Pour comprendre Git en profondeur, il faut se concentrer sur les propriétés de ce graphe et non sur des workflows ou sur des commandes.

Pour en savoir plus sur Git, examinez le répertoire .git. Ce n’est pas forcément effrayant. Regardez à l’intérieur. Changez le contenu des fichiers et regardez ce qui se passe. Créez un commit à la main. Essayez et regardez comment vous pouvez mettre un dépôt sens dessus dessous. Ensuite, réparez-le.


  1. Dans ce cas, l’empreinte est plus longue que le contenu. Mais tous les morceaux de contenu plus longs que le nombre de caractères dans l’empreinte seront exprimés de façon plus concise que l’original. 

  2. Il y a une chance que deux contenus différents aient la même empreinte mais les probabilités sont faibles. 

  3. git prune supprime tous les objets qui ne peuvent êtres atteints depuis une référence. Si un utilisateur utilise cette commande, il peut perdre du contenu. 

  4. git stash sauvegarde toutes les différences entre la copie de travail et le commit HEAD dans un endroit sûr. Elles peuvent être retrouvées plus tard. 

  5. La commande rebase peut être utilisée afin d’ajouter, éditer ou supprimer des commits dans l’historique du dépôt. 

Salle comble pour la réforme du droit d'auteur pour le 21e siècle

Public dans la salle des fêtes de Mozilla Paris pour la soirée réforme du droit d'auteur pour le 21e siècleComme prévu Mozilla Paris a accueilli une soirée dans le cadre des Maker Party sur la réforme du droit d’auteur pour le 21ᵉ siècle. La réforme du droit d’auteur dans l’Union européenne est un des sujets majeurs pour l’équipe Net Policy de Mozilla en 2017 et le projet de réforme présenté par la Commission est très critiqué par Mozilla et les associations de défense des libertés dont La Quadrature du Net et Wikimedia France qui étaient présentes ce lundi soir.

En plus de ces associations, des créatrices confrontées aux limites du système de droit d’auteur actuel ont débattu pendant plus de deux heures avec une salle comble.


80 personnes assistent aux présentations et débats de cette soirée à Mozilla Paris
(9 s sur YouTube).

Lisez ou relisez :

Vous pouvez retrouver la partie présentation-débat sur Air Mozilla dans une vidéo de deux heures :

Les organisations

Logo de Wikimedia FranceWikimédia France – Association pour le libre partage de la connaissance est une association à but non lucratif, dont le but est de soutenir en France la diffusion libre de la connaissance et notamment les projets hébergés par la Wikimedia Foundation comme l’encyclopédie Wikipédia, la médiathèque Wikimedia Commons, le dictionnaire Wiktionnaire et plusieurs autres projets liés à la connaissance.

LQDN : soutienLa Quadrature du Net est une association de défense des droits et libertés des citoyens sur Internet. Elle promeut une adaptation de la législation française et européenne qui soit fidèle aux valeurs qui ont présidé au développement d’Internet, notamment la libre circulation de la connaissance.

Les liens évoqués

Voici quelques liens cités lors de la soirée :

La page Wikipédia du Viaduc de Millau pour laquelle l’encyclopédie en ligne à pris le risque de publier des photos sans autorisation de l’architecte qui serait titulaire du droit d’auteur sur l’image de l’ouvrage.

La page française de la campagne Save The Link/Garder le lien qui entend préserver la liberté de faire des liens hypertextes et contre le droit voisin des éditeurs de presse.

La Quadrature du Net organise un atelier le 4 février : directive européenne sur la réforme du droit d’auteur : atelier de propositions positives.

Pour les positions et propositions de l’association :

Les fanfictions

Alixe, auteure de fanfictions, a rédigé la riche page de Wikipédia sur le sujet.

Son site personnel sur le phénomène est aussi très complet.

Elle a cité le webdocumentaire de France Télévision : Citizen Fan.

Pizzas…

Les discussions se sont poursuivies autour de pizzas, de chips et de beignets dans une bonne ambiance.

bar de Mozilla Paris Pizzas chez Mozilla Paris

Bonus

Le célèbre lancé de micro de Mozilla Paris :


Stéphanie au service ! (sur YouTube)

@Mozinet

Crédit illustrations : Photos, Mozinet sous licence CC By 2.0.

Bannière La Quadrature du Net.

Logo Wikimédia France.

Vivre dans l'ordinateur : Mozilla appelle à un internet des objets responsable

IoTpar Mark Surman de la fondation Mozilla, le 5 janvier 2017

Un nouveau papier de la coalition NetGain Partnership s’intéresse aux opportunités et aux dangers d’un internet envahissant

Aujourd’hui, nous vivons connectés. Internet interconnecte tout : du commerce et du journalisme à l’art en passant par la participation citoyenne.

Mais de plus en plus, être connecté ne se limite pas à être assis en face d’un écran, une souris à la main. L’internet des objets (Internet of Things ou IoT ) – le réseau informatique qui recouvre le globe – permet à Internet de pénétrer dans nos vêtements, nos maisons, notre santé. Internet est maintenant fait de milliards d’objets connectés et de zettaoctets de données. Internet est omniprésent.

L’omniprésence d’Internet n’est pas une simple nouveauté ou une étape parmi d’autres. C’est un bond extraordinaire qui permet de connecter les systèmes de distribution électrique, les systèmes d’urgence, les pacemakers et les appareils électroménagers. Ce qui nécessite donc une réflexion et une attention profondes. Cette avancée doit être guidée par un ensemble de principes.

Au cours des dernières décennies, nous avons vu le pouvoir que représente Internet. C’est une force qui peut destituer les dictateurs, révolutionner l’éducation, réorganiser les économies et connecter des milliards de personnes. Malheureusement, c’est aussi une force qui permet de surveiller, de réprimer, de harceler et d’exclure. Il peut fragiliser nos valeurs les plus importantes.

Nous sommes aujourd’hui à la croisée des chemins. Alors que l’internet des objets évolue et s’immisce dans notre sphère privée, nous devons trouver un équilibre entre le progrès et les principes que nous devons respecter. Il ne suffit pas de se demander : « Est-ce que c’est possible ? » Il faut également se poser la question : « Est-ce responsable ? »

NetGain Partnership – une large coalition d’organisations sans but lucratif, engagées dans la protection d’Internet comme une ressource publique – a publié un article quant au chemin qui nous attend. « We All Live in the Computer Now » (nous vivons tous dans l’ordinateur désormais) explore les pistes ouvertes par un Internet omniprésent, les défis qui lui sont associés et la direction que nous prenons.

D’une part, l’internet des objets peut contribuer au bénéfice de tous : il peut être utilisé pour le partage des connaissances et des technologies. Il peut aider à la préservation de la planète : des villes comme San Antonio, Barcelone et Hubli ont tiré parti de l’internet des objets pour économiser l’eau et l’énergie. La démocratie peut également en bénéficier : de Hong Kong à Dublin, les gens utilisent le Web pour participer aux décisions du gouvernement. L’internet des objets est une ressource pour des organisations et des mouvements d’intérêt public, des Arduino aux makerspaces.

D’autre part, certains dangers existentiels guettent. L’internet des objets menace la vie privée avec ses légions de micros et caméras qui peuvent suivre nos mouvements et nos conversations à notre insu. La surveillance de masse est à la portée des gouvernements et les données personnelles sont les proies faciles de hordes d’entreprises intéressées. L’internet des objets ouvre la porte à plus de vulnérabilités, permettant l’attaque Dyn qui a eu lieu récemment ou le piratage des élections.

Les points d’inflexion qui balisent le passé d’Internet nous fournissent une aide précieuse. Avec le recul, nous nous apercevons qu’un meilleur équilibre et de meilleurs principes auraient été bénéfiques. Pendant les années 90, lorsque le Web a explosé, le pouvoir s’est rapidement concentré autour du monopole d’un navigateur. Plus récemment, nous avons vu que l’évolution du Web a creusé les écarts : les plus privilégiés ont été favorisés et les autres, plus pauvres ou non anglophones, ont été mis de côté.

Oui, nous avons progressé sur ces fronts. Les utilisateurs d’Internet peuvent désormais choisir et contrôler leur navigateur. Les ONG, les entreprises et les gouvernements promeuvent l’intégration numérique. Mais aujourd’hui, nous avons la chance de pouvoir agir proactivement sur ces dangers à venir. À l’heure de la genèse de l’internet des objets, nous pouvons construire un avenir sûr.

Que faire ? Des organisations philanthropiques telles que Mozilla, Ford, Knight, MacArthur et Open Society sont en première ligne pour construire un meilleur Internet. L’internet des objets sera la première bataille majeure de 2017. Dans notre papier, nous partageons six principes pour un meilleur internet des objets. Nous prévoyons également d’organiser des projets de recherche, des bourses et des expositions pour mieux tracer l’avenir. Et enfin, NetGain recherche d’autres technologues, militants et entrepreneurs pour amplifier le mouvement. ■

Internet of Things – NetGain Partnership.pngLe papier de Netgain sur l’internet des objets, Mark Surman et Michelle Thorne de la fondation Mozilla, 20 octobre 2016 [PDF, 541 Ko, 22 pages, via Google Drive]

Traduction et relecture : Léonarf, Mozinet, Julien “Sphinx”, Goofy, Sizvix, Porkepix et anonymes

Crédit illustration (ajouté par le traducteur) : IoT par geralt sous licence CC0 – domaine public.

Remplacer le moteur de l'avion en plein vol

plane-twitter-300x150.jpgpar Jen Simmons, le 4 janvier 2017

Safari tourne sur Webkit. Chrome tourne sur Blink. Et Firefox tourne sur Gecko… qui est vieux… vraiment vieux. Je pense que c’est le plus vieux moteur d’affichage encore largement utilisé.

Bien sûr, avec deux décennies d’expérience, nous avons aujourd’hui de « bien meilleures idées » sur la façon de créer un moteur d’affichage de navigateur (et du logiciel en général). Ainsi, pendant les dernières années, Mozilla a travaillé sur un tout nouveau moteur top secret. Sauf qu’il n’est pas du tout top secret… et ne l’a jamais été. Dans une autre entreprise, il aurait été un projet top secret. Chez Mozilla, tout a été fait au grand jour.

Logo de ServoLe projet s’appelle Servo. Il a débuté en tant qu’expérience. Il est codé dans un nouveau langage de programmation appelé Rust (Gecko est écrit en C++). Et il est open source. Vous pouvez en tout point nous aider à le construire.

Qu’est-ce que cela signifie pour Firefox ? Eh bien, d’abord, je parlerai du moteur d’affichage et non du navigateur en entier – le moteur d’affichage est la partie du navigateur qui analyse et affiche chaque page web, ce qui est distinct de trucs comme les outils pour gérer les marque-pages, les barres d’URL (adresse internet) et de recherche, et les menus pour les fonctions de Firefox. Si dans un claquement de doigts nous pouvions remplacer Gecko tout d’un coup, les gens normaux n’auraient pas idée de ce qu’il s’est passé – enfin, sauf que les sites web se chargeraient extrêmement vite. Supervite, même. Vite, parce que nous avons de « bien meilleures idées ».

Le tour de force est de trouver comment passer de l’ancien moteur d’affichage au nouveau. Vous ne pouvez pas le faire tout d’un coup. C’est comme trouver un moyen de remplacer le moteur d’un avion en plein vol. Je suppose que nous pourrions faire atterrir l’avion, laisser tous les passagers débarquer pour qu’ils puissent déambuler et prendre d’autres avions, sans fournir aucun service pendant un moment tandis que nous échangeons les moteurs… mais non ! Non, nous ne pouvons pas faire ça. Et ça n’arrivera pas.

Badge RustNous pourrions continuer à faire voler l’avion actuel, tout en repartant de zéro pour construire un avion complètement nouveau sur le terrain – en choisissant spécialement chaque écrou, chaque boulon, en dessinant un nouveau cockpit et en attendant de nombreuses années pour faire voler cet avion. Mais nous ne voulons pas non plus faire cela. Nous avons déjà un avion géant. Et c’est un avion plutôt bon. Nous devons continuer à l’utiliser. Nous voulons uniquement un nouveau moteur sur cet avion. Dès que nous pourrons l’avoir.

C’est là qu’entre en scène Quantum, le nom de code du projet pour trouver comment remplacer le moteur sur notre avion toujours en vol. Une de ses parties est appelée Quantum style (alias Stylo) – c’est ce qui nous permet de passer d’un Gecko rendant toutes les feuilles de style CSS à l’utilisation de Quantum pour les CSS. Quantum Style assemble Gecko et Servo en demandant à chacun de faire le boulot qu’il fait le mieux. Parce que, en fait, même si c’est depuis environ 20 ans, Gecko fait des choses plutôt étonnantes et nous voulons continuer à tirer parti des bons morceaux. Faire du neuf n’est pas toujours la meilleure solution.

À un moment à la mi-2017, les nouveautés du CSS seront élaborées avec les parties de l’avion provenant de Quantum et plus de Gecko. À l’avenir, ce sera plus facile et plus agréable d’implémenter de nouvelles propriétés CSS. Cela facilitera la contribution des membres de la communauté open source. Cela accélérera la sortie de nouvelles choses.

L’année devant nous devrait être une bonne année pour Firefox. Si vous ne l’avez pas essayé depuis quelque temps, faites-le. Après s’être recentré en 2015, avoir jeté les bases du renouveau en 2016, Mozilla a préparé Firefox pour faire sensation en 2017.


Traduction et relecture : Mozinet, Goofy et anonymes

(Re)lire : Quantum va vous faire réaimer Firefox et le Web

Images rajoutées par le traducteur

Crédit illustrations : logo de Servo et badge de Rust, Mozilla.

Le navigateur Tor et Mozilla Firefox en symbiose

onion heartTel un calendrier de l’Avent qui n’en porte pas le nom, le projet Tor a au cours du mois de décembre publié une série de billets Tor at the Heart qui met en exergue des organisations et des projets « qui dépendent de Tor, sont développés par dessus Tor ou accomplissent mieux leurs missions grâce à l’existence de Tor ». Fin décembre, ce sont Ethan Tseng et Richard Barnes de Mozilla qui ont explicité la collaboration étroite entre les équipes de développement du Navigateur Tor et celles de Firefox. La communauté Mozilla francophone a traduit ce billet pour vous :

Firefox <3 le Navigateur Tor

par Ethan Tseng et Richard Barnes

Tor BrowserSi vous avez utilisé Tor, vous avez probablement utilisé le Navigateur Tor[1], et donc Firefox. En terme de lignes de code, le Navigateur Tor est en grande partie Firefox : il y a quelques modifications et ajouts, mais environ 95 % du code du Navigateur Tor provient de Firefox. Les équipes de Firefox et du projet Tor collaborent depuis un certain temps déjà, mais en 2016 nous avons commencé à passer à l’étape suivante, rapprochant plus que jamais Firefox et le Navigateur Tor. Avec une collaboration plus étroite, nous avons permis aux développeurs du Navigateur Tor de faire leur travail encore plus facilement, et en offrant plus d’options aux utilisateurs de Firefox pour prendre soin de leur vie privée, tout en rendant les deux navigateurs plus sûrs.

L’équipe du Navigateur Tor le développe en utilisant les versions ESR[2] de Firefox et en appliquant des patchs sur celles-ci. Grâce à ces modifications, les usagers du Navigateur Tor profitent de précieuses fonctionnalités de protection de la vie privée. Cependant, ces changements signifient aussi que chaque fois que cette équipe souhaite utiliser une nouvelle version de Firefox, elle doit mettre à jour ces patchs afin qu’ils fonctionnent sur cette nouvelle version. Ces mises à jour représentent une part substantielle des efforts de développement du Navigateur Tor.

En 2016, nous avons commencé à intégrer, dans Firefox, les modifications apportées au Navigateur Tor. Quand un patch est intégré, nous prenons les changements dont le Navigateur Tor a besoin et les ajoutons à Firefox de telle sorte qu’ils soient désactivés par défaut mais qu’ils puissent être activés via une simple préférence. Cela permet de préserver le travail de développement du navigateur, puisqu’il suffit désormais à son équipe de développement de modifier des préférences plutôt que de mettre à jour le patch. Cela fournit également aux équipes de développement de Firefox un moyen d’expérimenter des fonctionnalités avancées de protection de la vie privée, développées pour le Navigateur Tor, afin de voir s’ils peuvent les proposer à un public bien plus large.

Notre cible principale dans le projet d’intégration a été une fonctionnalité appelée isolation par origine, qui fournit une très forte protection contre le pistage (au risque de casser certains sites). Mozilla a mis sur pied une équipe dédiée à l’intégration de cette fonctionnalité du Navigateur Tor à Firefox, en utilisant la même technologie que nous avons utilisée pour créer la fonctionnalité des contextes. L’équipe a développé aussi des tests complets et un processus de QA[3] afin de s’assurer que cette isolation dans Firefox était aussi solide que celle du Navigateur Tor, et a même identifié quelques pistes pour ajouter des protections encore plus fortes. L’équipe de Mozilla a travaillé en étroite collaboration avec celle du Navigateur Tor, y compris avec des téléconférences hebdomadaires et une rencontre en personne en septembre.

Aperçu du bouton dans la barre principale(Re)lire : Les onglets contextuels dans Firefox Nightly

L’isolation par origine sera incluse dans Firefox 52, qui servira de base à la prochaine version majeure du Navigateur Tor. De ce fait, l’équipe du Navigateur Tor ne sera plus obligée de mettre à jour les patchs d’isolation par origine pour cette version. Dans Firefox, l’isolation par origine est désactivée par défaut (à cause des risques d’incompatibilité), mais les utilisateurs de Firefox pourront choisir d’utiliser l’isolation par origine en allant dans « about:config » et en passant « privacy.firstparty.isolate » à « true ».

Nous sommes impatients de poursuivre cette collaboration en 2017. Le travail d’intégration d’un ensemble de patchs, protégeant de différentes formes de pistage par l’empreinte du navigateur, va bientôt commencer. Nous allons aussi rechercher comment travailler ensemble pour améliorer le bac à sable[4], en nous basant sur le travail de Yawning Angel pour le Navigateur Tor et les fonctionnalités de bac à sable de Firefox qui sont prévues pour être diffusées début 2017.

Enfin, nous devrions reconnaître la valeur de cette collaboration prolongée entre Mozilla et le Tor Project concernant les failles de sécurité. L’importance de cette collaboration a été mise sur le devant de la scène, il y a quelques semaines, lorsque nous avons simultanément été alertés de l’exploitation d’une vulnérabilité zero-day[5] ciblant le Navigateur Tor au travers d’une faille présente dans Firefox. Travaillant ensemble, nous avons été capables de développer, tester et mettre à disposition un correctif pour les deux navigateurs en moins de 24 heures.

La collaboration entre les équipes de Firefox et du Navigateur Tor illustre justement la manière avec laquelle les principes d’ouverture et de participation de Mozilla peuvent aider à faire évoluer la sécurité et la vie privée sur Internet. Nous sommes fiers de tout ce que nous avons accompli ensemble avec le Tor Project en 2016 et sommes impatients de continuer à rendre le Web plus sécurisé et respectueux de la vie privée. ■


Traduction et relecture : Porkepix, Mozinet, Théo, Sphinx, Vincent, Anthony, nicoo et anonymes

Images rajoutées par le traducteur.


Notes du traducteur

[1] : vous trouverez souvent le logiciel appelé par son nom en anglais : Tor Browser.

[2] : les « Extended Support Releases » sont des versions de Firefox destinées aux organisations et entreprises pour lesquelles Mozilla fournit des mises à jour de sécurité et de stabilité sans nouvelles fonctionnalités pendant à peu près un an.

[3] : on désigne par assurance qualité un moyen d’obtenir confiance dans l’assurance de la qualité c’est-à-dire dans l’aptitude de la société ou de l’organisation à satisfaire le niveau de qualité désiré (source).

[4] : dans le domaine de la sécurité des systèmes informatiques, un sandbox (anglicisme signifiant « bac à sable ») est un mécanisme qui permet l’exécution de logiciel(s) avec moins de risques pour le système d’exploitation (source).

[5] : une vulnérabilité Zero day est une vulnérabilité informatique n’ayant fait l’objet d’aucune publication ou n’ayant aucun correctif connu (source).