Linux (fr)

  • Les Init alter-natifs (Journaux LinuxFR)

    Dans l’ordre alphabétique :

    • openrc
    • upstart
    • runit
    • s6
    • shepherd
    • sinit
    • sysvinit
    • systemd

    Sans compter les systèmes d’init à la BSD. (Soit dit en passant, TrueOS compte passer sous OpenRC.)

    On en pense ce qu’on veut, on en dira ce qu’on veut, mais ils vous donnent le choix, de les
    apprécier, ou simplement de les ignorer.

    En tant qu’utilisateur de plusieurs de ces inits (incluant le dernier de la liste, si si),
    je vous conseille la lecture de ces pages :

    Init-freedom
    Systemd-free

    Amusez-vous bien jusque vendredi !

    Lire les commentaires

  • Les bêtas de Linux Mint et Trisquel GNU/Linux sont sorties (Journaux LinuxFR)

    Si vous voulez essayer une distribution 100% libre, la bêta de Trisquel GNU/Linux vient de sortir. Elle utilisera maintenant le bureau MATE.
    La bêta de Linux MINT vient aussi de sortir, elle propose MATE ou Cinnamon comme bureaux.
    L'annonce de sortie de Trisquel GNU/Linux : https://listas.trisquel.info/pipermail/trisquel-devel/2016-November/001023.html
    Les ISO de Trisquel GNU/Linux : http://jenkins.trisquel.info/makeiso/iso/
    Linux Mint Cinnamon : http://blog.linuxmint.com/?p=3165
    Linux Mint MATE : http://blog.linuxmint.com/?p=3168
    Pensez à remonter les bogues si vous testez, ça profitera à tout le monde.

    Lire les commentaires

  • Lancement du projet Open Compute Toolchain (Journaux LinuxFR)

    Bonjour a tous,

    Et oui deja plusieurs fautes d'accents, je suis encore de l'autre cote de l'Atlantique et a force je perds la keymap francaise :(. Ne m'en voulez pas, je corrigerai ce journal en rentrant en France prochainement ! Mais comme la nouvelle est sortie cette semaine, et que je ne voulais pas qu'elle tombe aux oubliettes, j'ai prefere prendre le risque d'avoir qqs soucis avec nos francophiles chevronnes (et ils ont raison).

    Comme vous le savez je suis implique dans Open Compute, et notre implication est passee a un niveau superieur cette semaine suite a cette annonce en anglais je precise Open Compute Toolchain. Je suis aussi contributeur au projet FreeCAD ( http://www.freecadweb.org) et nous essayons d'eduquer la communaute Open Compute aux problemes d'accessibilites des fichiers proprietaires pour les membres de la communaute qui n'ont pas les moyens de s'offrir des licences logicielles proprietaires qui valent une fortune (et je mesure mon propos).

    Et ben on a reussi a franchir une etape et ca fait plaisir. L'objectif du projet est de construire une toolchain (ouverte) qui permettra aux equipes de developpements de travailler de maniere collaborative sur un meme design, et de developper les technologies associees. Les implementations de references seront faites en utilisant des logiciels libres.

    Pour ceux qui veulent nous aider a faire avancer le sujet n'hesitez pas a rejoindre la mailing list, on a du boulot, et on emmenera les meilleurs contributeurs a l'Open Compute Summit pour presenter la premiere demo de la toolchain (rassurez vous en trois mois on risque pas de revolutionner la planete, mais on ne peut pas louper l'evenement) !

    FreeCAD et KiCAD sont majoritairement developpe en Europe, les plus gros membres d'Open Compute sont Facebook, Microsoft, Google, Intel, Rackspace, et les convaincre de regarder ces solutions a ete un exercice relativement interessant, j'espere qu'on pourra leur prouver que l'on peut construire quelque chose d'aussi innovant que RuggedPOD !

    vejmarie

    Lire les commentaires

  • Scrum, Kanban, Git : Tuleap 9.0 est disponible (Dépêches LinuxFR)

    La version 9.0 de Tuleap a été publiée fin octobre et déjà les versions suivantes arrivent. Petit retour sur les grandes nouveautés de Tuleap 9.

    Tuleap est une forge logicielle publiée sous licence GPL par la société Enalean.

    logo Tuleap
    La particularité de cette version 9 est de s'adresser à l'ensemble des membres d'une équipe de développement agile. Aux développeurs agiles bien entendu mais également à toutes personnes qui peuvent être impliquées de près ou de loin dans un projet logiciel : les product owners, les clients, les utilisateurs finaux, les directeurs techniques, les commerciaux pourquoi pas.

    Vous allez donc retrouver dans une seule plateforme tous les outils dont chacun a besoin : des outils de planification et de visualisation d'un projet agile, environnement Scrum ou tableau Kanban, un système de tracker (pour suivre les stories, tâches, incidents, etc.), un système de gestion de version (Git ou Subversion), de la revue de code (pull request ou Gerrit), de la documentation collaborative, un gestionnaire de livrables.

    L'objectif ? Ne pas avoir à basculer d'un outil à l'autre, d'éviter les copier-coller de tickets, automatiser le plus possible de flux de développement et avoir une gestion des utilisateurs et des droits d'accès centralisée.

    « En informatique, une forge est un système de gestion de développement collaboratif de logiciel. » nous dit Wikipédia. Tuleap permet donc aux équipes de développement de mieux gérer leurs projets logiciels et industrialiser leurs développements.

    Tuleap est basée sur une stack LAMP (Linux Apache MySQL Php) et utilisent des technologies comme AngularJS, NodeJS. On l'installe sur un serveur Red Hat ou CentOS 6 ou avec une image Docker.

    Les grandes fonctionnalités de Tuleap 9 en quelques mots

    Nouveau Kanban

    Tableau Kanban dans Tuleap

    Facilité d’usage avec copier/coller, un ou plusieurs Kanban par projet, spécification d’un WIP (Work In Progress) pour se concentrer sur le travail en cours, facilité d’ajout/renommage/suppression de colonnes, diagrammes cumulatifs.

    Nouvel environnement Scrum

    Scrum dans Tuleap

    Nouvelle vue du planning pour gérer et prioriser un large volume de tâches (user stories), amélioration des performances pour planifier les versions et les itérations (sprints), design revue.

    Git à l’échelle

    Git à l'échelle dans Tuleap
    Possibilité de déployer Git à large échelle en créant des miroirs, de migrer Git vers Gerrit avec route REST, d'automatiser des webhooks lors des Git push, gestion fine des permissions sur les branches Git.

    Amélioration de l’intégration avec Subversion

    Création de plusieurs dépôts Subversion par projet, meilleure intégration avec l’outil d’intégration continue Jenkins, amélioration de l’interface, support des "immutable tags".

    Nouvel outil d’import

    Importer vos artefacts depuis un outil tiers, Bugzilla par exemple.

    Les autres grandes fonctionnalités de Tuleap

    tracker dans Tuleap

    • Trackers configurables pour chaque projet (ajouter/modification des champs, des permissions, des workflow…) sans dépendre d’un administrateur central
    • Graphiques : Gantt, camemberts, barres, mur de cartes (cardwall), burndown
    • Intégration avec l’outil de revue de code Gerrit
    • Intégration avec l’outil d’intégration continue Jenkins
    • Intégration avec Eclipse via un plugin Mylyn eclipse et tuleap
    • Outil de gestion documentaire et édition collaborative, phpwiki, mediawiki la doc dans tuleap
    • Gestion centralisée des utilisateurs et de leurs droits
    • API REST

    À venir pour Tuleap 10

    Remerciements

    On profite de cette dépêche pour dire un grand merci aux contributeurs et sponsors du projet Tuleap : les contributeurs volontaires, les développeurs de Enalean, de STMicroelectronics, les partenaires et les sociétés, petites ou grosses, qui participent au financement collaboratif du projet dans le cadre de l'Open Roadmap.

    Processus de développement

    Parlons maintenant de la façon dont l'équipe Tuleap développe et livre la forge : le projet Tuleap promeut les principes et valeurs de l'agilité et des logiciels libres. Les développements en cours, passés et à venir sont visibles par tout le monde dans le tableau agile du projet et dans les notes de version.

    L'équipe Tuleap livre une version par mois, tout sous licence GPL, avec des fonctionnalités encore en cours de développement et des corrections d'incidents. L'idée c'est que chacun puisse tester les nouveautés et faire part de son opinion. Chacun est donc invité à donner son avis : est-ce que la fonctionnalité en cours de développement répond à votre besoin, quels sont les points à conserver, ceux à améliorer, etc.

    Et voici comment vous pouvez participer au projet Tuleap. Merci d'avance !

    Lire les commentaires

  • C++17 indique la disponibilité des entêtes (header) (Dépêches LinuxFR)

    Chaque jour de décembre a droit à sa surprise. Après l'ordre d'évaluation, aujourd'hui, le calendrier de l’Avent du C++ présente la Spécification Technique P0061 concernant une macro magique : #define __has_include.

    Une personne déprime de ne plus rien comprendre au C++ et son collègue le rassure que LinuxFr.org publie le calendrier de l'Avent du C++ avec des explications pédagogiques

    Sommaire

    Série de dépêches C++

    Cette dépêche fait partie de toute une série disponible également sur le dépôt Git du Groupe des Utilisateurs C++ Francophone.

    Publication Dépêche
    20 août 2016 Les coulisses du standard C++
    2 oct. 2016 Genèse du C++17
    1ᵉʳ déc. 2016 C++17 fixe l’ordre d’évaluation des expressions
    2 déc. 2016 C++17 indique la disponibilité des entêtes (header)
    à venir… … d’autres dépêches …
    en 2017 Faut-il continuer à apprendre le C++ ?

    Initialement, nous allions publier une grosse dépêche super trop longue. Puis, fin novembre, nous nous sommes ravisés et nous vous proposons plutôt une petite dépêche par jour, d’où l’idée du calendrier de l’Avent du C++.   (ღˇ◡ˇ)~♥

    Spécification Technique

    La macro __has_include est dans les cartons depuis plusieurs années. Le comité de normalisation du C++ a intégré cette fonctionnalité en amendant le TS P0061.

    La macro

    La macro __has_include() vérifie si l’en-tête est disponible pour inclusion.

    #if    __has_include(<filesystem>)
    #  include           <filesystem>
    #elif  __has_include(<experimental/filesystem>)
    #  include           <experimental/filesystem>
    #elif __has_include(<boost/filesystem.hpp>)
    #  include          <boost/filesystem.hpp>
    #else
    #  error Ne trouve aucune en-tête filesystem
    #endif

    Dépendance optionnelle

    Sans cette fonctionnalité, le code source avait moins de possibilité de s'adapter automatiquement à l'environnement de compilation. Pour les dépendances optionnelles, l'outil de compilation (autotools, CMake…) devaient détecter la présence de telle ou telle dépendance et passer au compilateur des macros pour activer/désactiver des parties du code source.

    Et sans cette complexité en amont, il est difficile de proposer du code C ou C++ qui gère des dépendances optionelles : si l'entête (header) d'une dépendance est absent, le compilateur arrête la compilation car le code source tente d'inclure l'entête introuvable de cette dépendance, même si la dépendance est optionnelle.

    Chère lectrice, cher lecteur LinuxFr.org, tu as peut être un exemple pertinent en tête.
    Tu souhaites déplacer la complexité de l'outil de compilation vers le code source ?
    Fait nous part de tes idées dans les commentaires.

    L'exemple ci-dessous illustre l'utilisation de la macro __has_include() mais aurait aussi pu se baser sur la détection de macros comme WIN32, _WIN64 ou MSCVER

    #if __has_include(<windows.h>)
    #  include <windows.h>
       LONGLONG ticks1nano = []() {
         LARGE_INTEGER freq;
         QueryPerformanceFrequency(&freq);
         return freq.QuadPart / 1000'000;
       }();
       LONGLONG nanosecondes() {
         LARGE_INTEGER time;
         QueryPerformanceCounter(&time);
         return time.QuadPart/ticks1nano;
       }
    #elif __has_include(<time.h>)
    #  include <time.h>
       auto nanosecondes() {
          struct timespec ts;
          clock_gettime(CLOCK_MONOTONIC,&ts);
          return 1000'000'000 * ts.tv_sec + ts.tv_nsec;
       }
    #else
    #  error Ne trouve ni <windows.h> ni <time.h>
    #endif

    L'exemple suivant utilise également la macro __has_include().
    C'est une possibilité pour une implémentation multi-plateforme du futur Networking TS.

    #if __has_include(<winsock2.h>)
    
    #include <winsock2.h>
    
    struct WindowsSocketImpl : AbstractSocket
    {
      // implémentation Windows
    };
    
    using MySocket = WindowsSocketImpl;
    
    #else
    
    #include <sys/socket.h>
    
    struct UnixSocketImpl : AbstractSocket
    {
      // implémentation Unix
    };
    
    using MySocket = UnixSocketImpl;
    
    #endif
    
    // Usage
    AbstractSocket * socket = new MySocket();

    Roue de secours

    Nous pouvons aussi imaginer l'utilisation de cette macro __has_include() pour sélectionner la bibliothèque à utiliser selon la disponibilité de différentes alternatives.

    #if __has_include(<optional>)
    
    #include <optional>
    using MyOptional = std::optional;
    
    #elif __has_include(<experimental/optional>)
    
    #warning Utilise std::experimental::optional à la place de std::optional
    #include <experimental/optional>  // roue de secour
    using MyOptional = std::experimental::optional;
    
    #elif __has_include(<boost/optional.hpp>)
    
    #warning Utilise boost::optional à la place de std::optional
    #include <boost/optional.hpp>     // roue de secour secondaire
    using MyOptional = boost::optional;
    
    #else
    #  error Ne trouve ni <optional>, ni <experimental/optional>, ni <boost/optional>
    #endif

    Faut-il continuer à apprendre le C++ ?

    Panneau Please Do Not Feed the Trolls Panneau Troll barré

    Merci de nous aider à structurer et consolider les différentes idées sur cette question sur l'espace de rédaction collaboratif de LinuxFr.org : « Faut-il continuer à apprendre le C++ ? »

    Réutilisation

    Le texte de cette dépêche est protégé par le droit d’auteur la gauche d’auteur et réutilisable sous licence CC BY-SA 4.0. Les images utilisées sont aussi sous licence libre (cliquer sur l'image pour plus de détails).

    Donc n'hésitez pas à réutiliser ce contenu libre pour créer, par exemple, des supports de formation, des présentations (Meetups), des publications sur d’autres blogs, des articles pour des magazines, et aussi un article C++17 sur Wikipédia dès que Wikipédia passera de la licence CC-BY-SA-3.0 à la CC-BY-SA-4.0 (le contenu de cette dépêche utilise la version la CC-BY-SA-4.0).

    Les auteurs

    Par respect de la licence, merci de créditer les auteurs :

    Continuer à améliorer ce document

    Malgré tout le soin apporté, il reste certainement des oublis, des ambiguïtés, des fôtes… Bien que cette dépêche restera figée sur le site LinuxFr.org, il est possible de continuer à l'enrichir sur le dépôt Git du Groupe des Utilisateurs C++ Francophone (C++FRUG). C’est donc sur ce dépôt que se trouve les versions les plus à jour.   (ღ˘⌣˘ღ)

    Alors que cet article restera figé sur le site LinuxFr.org, il continuera d’évoluer sur le dépôt Git. Merci de nous aider à maintenir ce document à jour avec vos questions/suggestions/corrections. L’idée est de partager ce contenu libre et de créer/enrichir des articles Wikipédia quand la licence sera CC BY-SA 4.0.   ٩(•‿•)۶

    La suite

    La dépêche suivante nous dévoilera une autre nouveauté du C++17.

    Chère lectrice, cher lecteur LinuxFr.org. Tu souhaites apporter ta pierre à cet édifice ? Rejoins‐nous dans l’espace de rédaction collaborative sur LinuxFr.org (un compte est nécessaire pour y accéder).

    À suivre…

    Lire les commentaires

  • C++17 fixe l'ordre d'évaluation des expressions (Dépêches LinuxFR)

    Le C++ est un langage bien présent et depuis longtemps dans les logiciels libres (environnements de bureau, outils bureautiques, navigateurs web…). 2017 approche à grands pas avec la promesse d’un tout nouveau C++17.

    Pour finir l’année, voici le calendrier de l’Avent du C++ avec des dépêches pédagogiques sur ce qui nous attend en 2017. Après deux dépêches de mise-en-bouche, nous entrons enfin dans le vif du sujet avec deux Spécifications Techniques concernant l’ordre d’évaluation des expressions. Allez, c’est parti !   ᕕ(ᐛ)ᕗ

    Bjarne propose de changer le C++ pour corriger son livre qu'il tient dans ses mains

    Sommaire

    Série de dépêches C++

    Cette dépêche fait partie de toute une série disponible également sur le dépôt Git du Groupe des Utilisateurs C++ Francophone. Alors que cet article restera figé sur le site LinuxFr.org, il continuera d’évoluer sur le dépôt Git. Merci de nous aider à maintenir ce document à jour avec vos questions/suggestions/corrections. L’idée est de partager ce contenu libre et de créer/enrichir des articles Wikipédia quand la licence sera CC BY-SA 4.0.  

    Publication Dépêche
    20 août 2016 Les coulisses du standard C++
    2 oct. 2016 Genèse du C++17
    1ᵉʳ déc. 2016 C++17 fixe l’ordre d’évaluation des expressions
    à venir… … d’autres dépêches …
    en 2017 Faut-il continuer à apprendre le C++ ?

    Initialement, nous allions publier une grosse dépêche super trop longue. Puis, fin novembre, nous prenions conscience que les lecteurs apprécieraient plutôt une petite dépêche par jour, d’où l’idée de faire le calendrier de l’Avent du C++.   (ღˇ◡ˇ)~♥

    Spécifications Techniques

    Deux TS ont été amendés par le comité de normalisation du C++ afin de fixer l’ordre d’évaluation des expressions :

    • P0145 définit les changements nécessaires au standard C++ ;
    • P0400 reformule une phrase de cette précédente TS P0145.

    Anecdote

    Le livre mythique The C++ Programming Language de l’inventeur du C++, Bjarne Stroustrup contient une erreur subtile à la page 1046 du paragraphe 36.3.6 STL-like Operations (quatrième édition publiée en 2013). Sauras-tu la retrouver ? Voici l’extrait en question :

    The replace() replaces one substring with another and adjusts the string’s size accordingly. For example:

    void f()
    {
     string s = "but I have heard it works even if you don't believe in it";
     s.replace(0,4,"");                   // erase initial "but "
     s.replace(s.find("even"),4,"only");
     s.replace(s.find(" don't"),6,"");    // erase by replacing with ""
     assert(s=="I have heard it works only if you believe in it");
    }

    A replace() returns a reference to the object for which it was called. This can be used for chaining operations:

    void f2()
    {
     string s = "but I have heard it works even if you don't believe in it";
     s.replace(0,4,"").replace(s.find("even"),4,"only").replace(s.find(" don't"),6,"");
     assert(s=="I have heard it works only if you believe in it");
    }

    Pas trouvé ? Pas d’inquiétude, aucun humain n’avait trouvé cette erreur. Bien après la publication de ce livre, cette erreur a été trouvée, non pas par une nouvelle forme d’Intelligence Artificielle, mais juste par un outil d’analyse statique de code source au nez et à la barbe des pointures C++ aguerries.

    Explications

    Pour des questions de performance, le standard C++ (avant C++17) indique que c’est le compilateur qui optimise l’ordre d’évaluation du chaînage et des paramètres de fonction. Le standard utilise le terme unsequenced (séquencement non défini). Le C et le C++ partagent ensemble cette règle.

    Donc, l’expression replace(find()).replace(find()) dans la fonction f2() peut être évaluée dans des ordres différents. En théorie, la variable s pourrait donc contenir différents résultats. Et c’est aussi le cas en pratique :

    Compilateur Résultat contenu par la variable s
    GCC et MSVC I have heard it works evenonlyyou donieve in it
    LLVM/Clang I have heard it works only if you believe in it

    Détails

    Ci-dessous, la première ligne déclare et initialise un objet std::string. La seconde ligne cherche et remplace plusieurs caractères de cette std::string en utilisant le chaînage des fonctions replace.

    std::string s = "but I have heard it works even if you don't believe in it";
    s.replace(0,4,"").replace(s.find("even"),4,"only").replace(s.find(" don't"),6,"");

    Intuitivement, on s’attendrait à évaluer les arguments des fonctions comme find("even") juste avant d’appeler replace(resultat,4,"only"). Mais ce n’est pas le cas avant C++17, ces arguments peuvent être évalués dans différents ordres. Plus de détails sont donnés par Shafik Yaghmour (en Anglais).

    Le tableau ci-dessous présente sur chacune des sept lignes, un ordre d’appel possible selon les standards C++ (avant C++17) et C (en supposant que ce soit une struct string avec des pointeurs de fonction).

    1ᵉʳ appel 2ᵉ appel 3ᵉ appel 4ᵉ appel 5ᵉ appel
    find(" don't") find("even") replace(0,4,"") replace(f,4,"only") replace(f,6,"")
    find("even") find(" don't") replace(0,4,"") replace(f,4,"only") replace(f,6,"")
    find(" don't") replace(0,4,"") find("even") replace(f,4,"only") replace(f,6,"")
    find("even") replace(0,4,"") find(" don't") replace(f,4,"only") replace(f,6,"")
    replace(0,4,"") find(" don't") find("even") replace(f,4,"only") replace(f,6,"")
    replace(0,4,"") find("even") find(" don't") replace(f,4,"only") replace(f,6,"")
    replace(0,4,"") find("even") replace(f,4,"only") find(" don't") replace(f,6,"")

    C++17 n’autorise qu’une seule possibilité, la dernière du tableau, et correspond à celle de la fonction f() du livre :

    s.replace(0, 4, "");
    s.replace(s.find("even"), 4, "only");
    s.replace(s.find(" don't"), 6, "");

    Autres exemples

    Par exemple, dans l’expression f().g(h()) la fonction f() peut-être appelée avant ou après h(). Le standard C++ fait la différence entre unspecified (non-spécifié) et unsequenced (non-séquencé). Ce comportement est bien spécifié, donc jusqu’à C++14 c’est unsequenced. À partir de C++17, c’est f() avant h() (sequenced before).

    // Avant C++17, f() peut être appelée avant ou après h()
    f().g( h() ); 
    // C++17 est plus intuitif : f() est toujours appelée avant h()

    C’est aussi le cas de l’expression std::cout << f() << g() << h(); dont les trois fonctions peuvent être appelées dans n’importe quel ordre.

    // Avant C++17, le compilateur décide l’ordre d’évaluation de f(), g() et h()
    std::cout << f() << g() << h() << std::endl; 
    // C++17 fixe l’ordre intuitif : d’abord f(), puis g() et enfin h()

    Encore d’autres exemples que le C++ partage avec le C :

    std::map<int, int> m;
    m[0] = m.size();
    std::cout << m[0]; // Affiche 0 ou 1 ?
    // Clang  : 0
    // GCC    : 1
    // MSVC++ : 0
    int i = 0;
    std::cout << i << ' ' << i++; // Affiche 0 0 ou 1 0 ?
    // Clang  : 0 0
    // GCC    : 1 0
    // MSVC++ : 1 0
    int i = 0;
    i = i++ + 1;    // unsequenced
    std::cout << i; // Quelle valeur ?
    // Clang   : 1  mais avertit : multiple unsequenced modifications to 'i'
    // GCC-6.2 : 1  mais avertit : operation on 'i' may be undefined

    Ci-dessus, pour toutes les versions du C++ et du C, l’opération est unsequenced et non pas undefined comme GCC-6.2 le laisse supposer.

    int i = 0;
    i = ++i, i++, i++, ++i, ++i, ++i, i++;
    std::cout << i; // Quelle valeur ?
    // Piège, toujours 7 car c'est "sequenced before"
    // GCC-6.2 avertit : operation on 'i' may be undefined

    Notons que GCC-6.2 suppose encore que l’opération est undefined alors que dans ce dernier cas, l’opération est sequenced before quelle que soit la version du C++ (et même du C).

    Conséquence

    Donc, beaucoup de codes sont potentiellement truffés de ces pièges, ce qui est également le cas quand std::future<T> est utilisé. Tout le monde se fait avoir, débutants comme experts. Et le comité de normalisation du C++ a donc amendé sans trop discuter ce TS afin de fixer l’ordre d’évaluation dans certains cas.

    Et c’est justement cet exemple du livre The C++ Programming Language qui illustre le paragraphe 5.2.2 Function call (page 107) du standard C++ (brouillon de juillet 2016).

    Nouvelle règle

    L’évaluation est :

    • De la gauche vers la droite pour les expressions suffixées. Ceci inclue les appels de fonction et la section des membres ;
    • L’affectation de la droite vers la gauche (a = b = c = d) ;
    • Les opérateurs de décalage (shift operators) de la gauche vers la droite.

    Par contre, lorsque une surcharge d’opérateur est invoquée, la priorité arithmétique est utilisée.

    Peut-être que le code généré sera moins performant, et que les standards C et C++ divergent un peu plus, mais au moins, le langage C++ devient un peu plus intuitif.
    ¯\(ツ)

    Appel à participation

    La précédente dépêche a reçu 227 commentaires, soit un volume dix fois supérieur à la dépêche elle-même. Tous ces commentaires cachent tout de même quelques joyeux trolls velus !

    Quand on pense à toute cette énergie dépensée et toutes ces heures consacrées à rédiger ces 227 commentaires ! Avec le recul nous aurions pu concentrer tout cet investissement dans une dépêche collaborative du style « Aujourd’hui, est-il pertinent de choisir le C++ pour une nouvelle application ? ».

    Panneau Please Do Not Feed the Trolls Panneau Troll barré

    Mais il n’est jamais trop tard ! Aussi nous proposons vous de rédiger la dépêche « Faut-il continuer à apprendre le C++ ? » Les nombreux commentaires de la dépêche précédente méritent d’y être copiés. Malheureusement, ceux-ci sont rarement sous licence compatible CC BY-SA 4.0. Ceci est donc un appel à tous leurs auteurs pour les copier dans cette dépêche afin de la nourrir. Ainsi, nous pourrons les structurer et proposer des réponses concises, claires et utiles à tous.

    Merci et à vos claviers !  

    Réutilisation

    Le texte de cette dépêche est protégé par le droit d’auteur la gauche d’auteur et réutilisable sous licence CC BY-SA 4.0. Les images utilisées sont aussi sous licence libre (cliquer sur l'image pour plus de détails).

    Donc n'hésitez pas à réutiliser ce contenu libre pour créer, par exemple, des supports de formation, des présentations (Meetups), des publications sur d’autres blogs, des articles pour des magazines, et aussi un article C++17 sur Wikipédia dès que Wikipédia passera de la licence CC-BY-SA-3.0 à la CC-BY-SA-4.0 (le contenu de cette dépêche utilise la version la CC-BY-SA-4.0).

    Les auteurs

    Par respect de la licence, merci de créditer les auteurs :

    Continuer à améliorer ce document

    Malgré tout le soin apporté, il reste certainement des oublis, des ambiguïtés, des fôtes… Bien que cette dépêche restera figée sur le site LinuxFr.org, il est possible de continuer à l'enrichir sur le dépôt Git du Groupe des Utilisateurs C++ Francophone (C++FRUG). C’est donc sur ce dépôt que se trouvent les versions les plus à jour.   (ღ˘⌣˘ღ)

    La suite

    Nous venons de découvrir un changement important au niveau du langage. La dépêche suivante nous dévoilera une autre nouveauté du C++17.

    Chère lectrice, cher lecteur LinuxFr.org. Tu souhaites apporter ta pierre à cet édifice ? Rejoins‐nous dans l’espace de rédaction collaborative sur LinuxFr.org (un compte est nécessaire pour y accéder).

    À suivre…

    Lire les commentaires

  • Désolé, la Quadrature, mais tu fais fausse route (Journaux LinuxFR)

    Bonjour nal, et bon vendredi !

    Chère Quadrature, je suis quelque peu embêté par ta récente prise de position sur le délit d'entrave à l'IVG.

    Comprenons-nous bien. J'ai toujours, jusqu'ici, soutenu tes prises de position. Pas financièrement car mes finances ne me le permettent pas, mais en les défendant, sur le net, oralement, ou en votant. Jusqu'ici, je t'ai toujours trouvée raisonnable, pertinente, percutante quand c'était nécessaire.

    Mais là, permets-moi de te dire, en toute amitié, que tu fais fausse route. Prenons le temps d'expliquer le contexte, pour les ceux qui nous écoutent.
    Il existe une pratique, fort répandue chez les humains, qu'on appelle les relations sexuelles. La plupart des humains adultes la pratiquent par plaisir, certains par contrainte, certains dans le cadre de leur activité professionnelle. Un des effets secondaires de cette pratique est appelé "grossesse" . C'est un état dont la physiopathologie est bien décrite et il existe des traitements préventifs et curatifs de cet état. Par ailleurs, certains humains se satisfont de cet état et le laissent aller jusqu'à sa guérison spontanée qui survient en 10 à 40 semaines. Les traitements préventifs de la grossesse sont appelés "contraception" et sont de plusieurs types, d'efficacité variée. Le traitement curatif est appelé "interruption volontaire de grossesse" et peut prendre trois types : médicamenteux si la grossesse est diagnostiquée précocément, chirurgicale si la grossesse est diagnostiquée moins précocément, et interdit si la grossesse est diagnostiquée trop tardivement ou que le traitement est appliqué trop tard.

    Certains humains estiment que la grossesse est un événement naturel, nécessairement heureux, et militent donc pour la généralisation de la troisième modalité de traitement. Grand bien leur fasse.
    Certains humains sont un peu plus retors, et ont monté tout un paquet de sites web et d'associations très bien organisées afin, non pas de militer pour l'interdiction de l'IVG (c'est leur droit le plus strict), mais de se faire passer pour des interlocuteurs officiels auprès des femmes cherchant à avorter. En effet, pour une personne qui cherche des informations, sur l'IVG comme sur tout autre sujet, la première démarche va être de taper "IVG", "interruption volontaire de grossesse" ou "avortement" dans Google. Plus personne ne consulte son médecin traitant en première intention pour une IVG.

    La raison ? Elle est simple. Mettons-nous deux minutes dans la peau d'une femme : Au cours d'une journée de boulot des plus banale, nous sommes surprise de ne pas avoir nos règles. Nous passons à la pharmacie après le boulot et y achetons un test de grossesse (en chuchotant au comptoir). Le pharmacien est allé chercher "Alors, les tests de grossesse, voyons voir… Hé, Marie ! Tu les as rangés où les tests de grossesse ? Oui, j'ai déjà cherché, mais ils n'y sont pas ! Ah, c'est bon, j'ai trouvé ! Voilà madame, ça fera 8€". Pendant ce temps là, nous sommes passée par à peu près tous les états émotionnels possibles et avons senti sur nous le regard réprobateur de tous les autres clients de la pharmacie. C'est marrant d'ailleurs, on sent toujours le regard noir pour une grossesse non désirée, et on sent leur admiration et leur jalousie pour une grossesse désirée alors qu'ils n'ont strictement aucun moyen de faire la différence. Mais je digresse. Une fois le fameux test en main, pas question d'attendre. Nous nous précipitons dans les toilettes les plus proches et tentons de trouver un moyen d'uriner sur cette fichue bandelette sans : 1. en foutre partout, à commencer par nous-même, et 2. le faire tomber au fond de la cuvette. C'est peut-être pour ça que certains tests sont vendus par deux : ne pas sous-estimer le pouvoir de nuisance d'une cuvette de WC.

    Bien, c'est positif. Enfin, non, pas bien, c'est une nouvelle plutôt négative. Il est 19h30, nous sommes fatiguée, nous nous sentons sale (rappelons qu'on a manqué se pisser dessus), et le cabinet du docteur Tartampion est fermé. Et puis pas question d'aller le vois, le docteur Tartampion. Il est gentil, pas de problème, mais c'est bien le problème : il est trop gentil. Il nous a vu grandir, il nous a examinée, il a guéri les bobos, c'est presque autant un ami qu'un médecin et on ne raconte pas ses ébats sexuels à ses amis, c'est comme ça. En plus il connaît toute la famille, il demande toujours comment vont les autres, comment ça se passe au boulot, l'école des enfants, il poserait des questions, c'est sûr. Exit le docteur Tartampion. Il y a la gynéco (ou le gynéco, mais 90% des gynécos sont des femmes). Oui, mais la secrétaire pourra nous donner un rendez-vous dans 3 semaines. Bon, allons nous renseigner sur internet.

    Et c'est ainsi que le professionnel de santé se retrouve éjecté de la boucle. Oh, bien sûr, il y a aussi le problème du professionnel de santé anti-IVG, mais c'est un autre débat.

    Les femmes, donc, cherchent de l'info sur internet. Et elles trouvent de l'info. En effet, il y a une myriade d'associations, bien dotées en personnel (bénévole) et bien financées, dont le but est : soit de diffuser de fausses informations, soit de faire culpabiliser les femmes. Et il a bien été montré, par plusieurs études, que ce qui cause les souffrances liées à une IVG, c'est avant tout et en premier lieu la réprobation sociale. L'IVG, en soi, ne pose pas de problème majeur. Ce n'est pas douloureux, une IVG. Ça peut être salissant, certes, mais pas beaucoup plus que des règles abondantes : on n'expulse qu'un embryon de quelques millimètres (sauf quand on la fait à l'hôpital, mais à l'hôpital, on s'attend à ce que ce soit salissant et on s'adapte en conséquence). Ce qui cause toutes les souffrances, c'est quand un tiers, qui peut être l'entourage, le conjoint, ou un random péon rencontré sur internet, se permet d'émettre un jugement, jugement qui contient nécessairement une part de honte quant au fait d'avoir une vie sexuelle active (ça ne se fait pas chez les femmes. Ça se fait chez les hommes, mais pas chez les femmes. Ah, et ça ne se fait pas non plus entre hommes. Faites comme vous pouvez pour trouver une solution).

    Il y a un second problème. C'est que ces sites, non content d'exercer des pressions psychologiques, donnent de fausses infos. Ils donnent les coordonnées de médecins connus pour être anti-IVG. Ils disent que ce n'est pas remboursé, que c'est dangereux, douloureux, que ça rend stérile. Alors oui, pour nous gens diplômés, pour moi qui ai un peu étudié la médecine, nous savons que c'est faux, mais on ne peut pas s'empêcher de se demander "et si ?". Ou encore plus simple, ils mentent sur le délai légal en espérant que quand on se réveillera, il sera trop tard. Résultat, ils réussissent à faire hésiter, hésiter, et quand finalement la femme se dit qu'il faut y aller quand même, il est trop tard ! Comment ça c'est pas 16 semaines ? Mais on m'avait dit que… Ah ben non madame, c'est 12. Vous allez devoir le garder, madame. Mais vous savez, c'est beau une grossesse…

    Il existe un délit d'entrave à l'IVG. Il a été mis en place, au siècle dernier, précisément pour lutter contre les dérives des anti-IVG, qui allaient manifester devant les hôpitaux. Ce délit ne couvre pas la délivrance d'informations fausses de nature à empêcher une femme d'exercer son droit à l'IVG.

    Il existe par ailleurs un délit de diffamation. Ce délit réprime le fait de diffuser des informations inexactes, comprenant l'attribution d'un fait, susceptibles de nuire à la réputation d'une personne. Chère Quadrature, es-tu opposée au délit de diffamation ? Milites-tu pour que tout un chacun soit autorisé à diffuser des informations erronées dans le but de nuire à autrui ?

    L'IVG n'est pas une personne. C'est une pratique, un droit fondamental de la femme, et dans une moindre mesure de l'homme, parce que moi aussi ça me ferait bien chier de devoir arrêter mes études pour m'occuper d'un enfant non désiré. N'étant pas une personne, elle ne peut attaquer les groupes extrêmement organisés qui l'attaquent de toutes parts. De plus, les sites anti-IVG sont remarquablement bien foutus et bien référencés sur Google (j'ai testé : ils ne sont par contre pas du tout référencés sur DuckDuckGo. Quelle honteuse entrave à la liberté d'expression de la part de DuckDuckGo que de ne présenter que les sites du ministère de la Santé et de la Caisse d'Assurance Maladie !). Sur www.ivg.net, tout est fait pour pousser la femme enceinte à appeler : numéro vert, articles sur le besoin de soutien psychologique, propositions d'orientation vers un établissement, on est clairement dans l'arnaque. Cette désinformation a des conséquences bien réelles, et néfastes, pour les personnes touchées. La proposition de la rendre punissable ne sort pas de nulle part : ce n'est que la transposition d'un délit déjà existant (la diffamation), chère Quadrature, auquel tu n'as jamais été opposée, à un cas de figure où l'objet du dénigrement systématique n'est pas une personne et ne peut donc être défendu comme tel. Il ne s'agit pas d'interdire de militer contre l'IVG. La liberté d'expression n'est pas entravée. Ce qui est entravé, c'est la liberté de tromper sciemment autrui. Ça ne me pose pas tellement de problème qu'il soit interdit d'être mensonger quand ces mensonges amènent d'autres personnes à ne pas pouvoir exercer leurs droits. Et c'est pourquoi, à mon avis, tu te trompes de combat.

    Lire les commentaires

  • C++17 indique la disponibilité des entêtes (header) (Dépêches LinuxFR)

    Chaque jour de décembre a droit à sa surprise. Après l'ordre d'évaluation, aujourd'hui, le calendrier de l’Avent du C++ présente la Spécification Technique P0061 concernant une macro magique : #define __has_include.

    Une personne déprime de ne plus rien comprendre au C++ et son collègues le rassure que LinuxFr.org publie le calendrier de l'Avent du C++ avec des explications pédagogiques

    Sommaire

    Série de dépêches C++

    Cette dépêche fait partie de toute une série disponible également sur le dépôt Git du Groupe des Utilisateurs C++ Francophone.

    Publication Dépêche
    20 août 2016 Les coulisses du standard C++
    2 oct. 2016 Genèse du C++17
    1ᵉʳ déc. 2016 C++17 fixe l’ordre d’évaluation des expressions
    2 déc. 2016 C++17 indique la disponibilité des entêtes (header)
    à venir… … d’autres dépêches …
    en 2017 Faut-il continuer à apprendre le C++ ?

    Initialement, nous allions publier une grosse dépêche super trop longue. Puis, fin novembre, nous nous sommes ravisés et nous vous proposons plutôt une petite dépêche par jour, d’où l’idée du calendrier de l’Avent du C++.   (ღˇ◡ˇ)~♥

    Spécification Technique

    La macro __has_include est dans les cartons depuis plusieurs années. Le comité de normalisation du C++ a intégré cette fonctionnalité en amendant le TS P0061.

    La macro

    La macro __has_include() vérifie si l’en-tête est disponible pour inclusion.

    #if    __has_include(<filesystem>)
    #  include           <filesystem>
    #elif  __has_include(<experimental/filesystem>)
    #  include           <experimental/filesystem>
    #elif __has_include(<boost/filesystem.hpp>)
    #  include          <boost/filesystem.hpp>
    #else
    #  error Ne trouve aucune en-tête filesystem
    #endif

    Dépendance optionelle

    Sans cette fonctionnalité, le code source avait moins de possibilité de s'adapter automatiquement à l'environnement de compilation. Pour les dépendances optionnelles, l'outil de compilation (autotools, CMake…) devaient détecter la présence de telle ou telle dépendance et passer au compilateur des macro pour activer/désactiver des parties du code source.

    Et sans cette complexité en amont, il est difficil de proposer du code C ou C++ qui gère des dépendances optionelles : si l'entête (header) d'une dépendance est absent, le compilateur arrête la compilation car le code source tente d'inclure l'entête introuvable de cette dépendance, même si la dépendance est optionnelle.

    Chère lectrice, cher lecteur LinuxFr.org, tu as peut être une exemple pertienent en tête.
    Tu souhaites déplacer la complexité de l'outil de compilation vers le code source ?
    Fait nous part de tes idées dans les commentaires.

    L'exemple ci-dessous illustre l'utilisation de la macro __has_include() mais aurait aussi pu se baser sur la détection de macros comme WIN32, _WIN64 ou MSCVER

    #if __has_include(<windows.h>)
    #  include <windows.h>
       LONGLONG ticks1nano = []() {
         LARGE_INTEGER freq;
         QueryPerformanceFrequency(&freq);
         return freq.QuadPart / 1000'000;
       }();
       LONGLONG nanosecondes() {
         LARGE_INTEGER time;
         QueryPerformanceCounter(&time);
         return time.QuadPart/ticks1nano;
       }
    #elif __has_include(<time.h>)
    #  include <time.h>
       auto nanosecondes() {
          struct timespec ts;
          clock_gettime(CLOCK_MONOTONIC,&ts);
          return 1000'000'000 * ts.tv_sec + ts.tv_nsec;
       }
    #else
    #  error Ne trouve ni <windows.h> ni <time.h>
    #endif

    L'exemple suivant utilise également la macro __has_include().
    C'est une possibilité pour une implémentation multi-plateforme du future Networking TS.

    #if __has_include(<winsock2.h>)
    
    #include <winsock2.h>
    
    struct WindowsSocketImpl : AbstractSocket
    {
      // implémentation Windows
    };
    
    using MySocket = WindowsSocketImpl;
    
    #else
    
    #include <sys/socket.h>
    
    struct UnixSocketImpl : AbstractSocket
    {
      // implémentation Unix
    };
    
    using MySocket = UnixSocketImpl;
    
    #endif
    
    // Usage
    AbstractSocket * socket = new MySocket();

    Roue de secours

    Nous pouvons aussi imaginer l'utilisation de cette macro __has_include() pour selectionner la bibliothèque à utiliser selon la disponibilité de différentes alternatives.

    #if __has_include(<optional>)
    
    #include <optional>
    using MyOptional = std::optional;
    
    #elif __has_include(<experimental/optional>)
    
    #warning Utilise std::experimental::optional à la place de std::optional
    #include <experimental/optional>  // roue de secour
    using MyOptional = std::experimental::optional;
    
    #elif __has_include(<boost/optional.hpp>)
    
    #warning Utilise boost::optional à la place de std::optional
    #include <boost/optional.hpp>     // roue de secour secondaire
    using MyOptional = boost::optional;
    
    #else
    #  error Ne trouve ni <optional>, ni <experimental/optional>, ni <boost/optional>
    #endif

    Faut-il continuer à apprendre le C++ ?

    Panneau Please Do Not Feed the Trolls Panneau Troll barré

    Merci de nous aider à structurer et consolider les différentes idées sur cette question sur l'espace de rédaction collaboratif de LinuxFr.org : « Faut-il continuer à apprendre le C++ ? »

    Réutilisation

    Le texte de cette dépêche est protégé par le droit d’auteur la gauche d’auteur et réutilisable sous licence CC BY-SA 4.0. Les images utilisées sont aussi sous licence libre (cliquer sur l'image pour plus de détails).

    Donc n'hésitez pas à réutiliser ce contenu libre pour créer, par exemple, des supports de formation, des présentations (Meetups), des publications sur d’autres blogs, des articles pour des magazines, et aussi un article C++17 sur Wikipédia dès que Wikipédia passera de la licence CC-BY-SA-3.0 à la CC-BY-SA-4.0 (le contenu de cette dépêche utilise la version la CC-BY-SA-4.0).

    Les auteurs

    Par respect de la licence, merci de créditer les auteurs :

    Continuer à améliorer ce document

    Malgré tout le soin apporté, il reste certainement des oublis, des ambiguïtés, des fôtes… Bien que cette dépêche restera figée sur le site LinuxFr.org, il est possible de continuer à l'enrichir sur le dépôt Git du Groupe des Utilisateurs C++ Francophone (C++FRUG). C’est donc sur ce dépôt que se trouve les versions les plus à jour.   (ღ˘⌣˘ღ)

    Alors que cet article restera figé sur le site LinuxFr.org, il continuera d’évoluer sur le dépôt Git. Merci de nous aider à maintenir ce document à jour avec vos questions/suggestions/corrections. L’idée est de partager ce contenu libre et de créer/enrichir des articles Wikipédia quand la licence sera CC BY-SA 4.0.   ٩(•‿•)۶

    La suite

    La dépêche suivante nous dévoilera une autre nouveauté du C++17.

    Chère lectrice, cher lecteur LinuxFr.org. Tu souhaites apporter ta pierre à cet édifice ? Rejoins‐nous dans l’espace de rédaction collaborative sur LinuxFr.org (un compte est nécessaire pour y accéder).

    À suivre…

    Lire les commentaires

  • Devuan, bon suivi. (Journaux LinuxFR)
  • Devuan Jessie 1.0 Beta 2 (Journaux LinuxFR)
  • C++17 fixe l'ordre d'évaluation des expressions (Dépêches LinuxFR)

    Le C++ est un langage bien présent et depuis longtemps dans les logiciels libres (environnements de bureau, outils bureautiques, navigateurs web…). 2017 approche à grands pas avec la promesse d’un tout nouveau C++17.

    Pour finir l’année, voici le calendrier de l’Avent du C++ avec des dépêches pédagogiques sur ce qui nous attend en 2017. Après deux dépêches de mise-en-bouche, nous entrons enfin dans le vif du sujet avec deux Spécifications Techniques concernant l’ordre d’évaluation des expressions. Allez, c’est parti !   ᕕ(ᐛ)ᕗ

    Bjarne propose de changer le C++ pour corriger son livre qu'il tient dans ses mains

    Sommaire

    Série de dépêches C++

    Cette dépêche fait partie de toute une série disponible également sur le dépôt Git du Groupe des Utilisateurs C++ Francophone. Alors que cet article restera figé sur le site LinuxFr.org, il continuera d’évoluer sur le dépôt Git. Merci de nous aider à maintenir ce document à jour avec vos questions/suggestions/corrections. L’idée est de partager ce contenu libre et de créer/enrichir des articles Wikipédia quand la licence sera CC BY-SA 4.0.  

    Publication Dépêche
    20 août 2016 Les coulisses du standard C++
    2 oct. 2016 Genèse du C++17
    1ᵉʳ déc. 2016 C++17 fixe l’ordre d’évaluation des expressions
    à venir… … d’autres dépêches …
    en 2017 Faut-il continuer à apprendre le C++ ?

    Initialement, nous allions publier une grosse dépêche super trop longue. Puis, fin novembre, nous prenions conscience que les lecteurs apprécieraient plutôt une petite dépêche par jour, d’où l’idée de faire le calendrier de l’Avent du C++.   (ღˇ◡ˇ)~♥

    Spécifications Techniques

    Deux TS ont été amendés par le comité de normalisation du C++ afin de fixer l’ordre d’évaluation des expressions :

    • P0145 définit les changements nécessaires au standard C++ ;
    • P0400 reformule une phrase de cette précédente TS P0145.

    Anecdote

    Le livre mythique The C++ Programming Language de l’inventeur du C++, Bjarne Stroustrup contient une erreur subtile à la page 1046 du paragraphe 36.3.6 STL-like Operations (quatrième édition publiée en 2013). Sauras-tu la retrouver ? Voici l’extrait en question :

    The replace() replaces one substring with another and adjusts the string’s size accordingly. For example:

    void f()
    {
     string s = "but I have heard it works even if you don't believe in it";
     s.replace(0,4,"");                   // erase initial "but "
     s.replace(s.find("even"),4,"only");
     s.replace(s.find(" don't"),6,"");    // erase by replacing with ""
     assert(s=="I have heard it works only if you believe in it");
    }

    A replace() returns a reference to the object for which it was called. This can be used for chaining operations:

    void f2()
    {
     string s = "but I have heard it works even if you don't believe in it";
     s.replace(0,4,"").replace(s.find("even"),4,"only").replace(s.find(" don't"),6,"");
     assert(s=="I have heard it works only if you believe in it");
    }

    Pas trouvé ? Pas d’inquiétude, aucun humain n’avait trouvé cette erreur. Bien après la publication de ce livre, cette erreur a été trouvée, non pas par une nouvelle forme d’Intelligence Artificielle, mais juste par un outil d’analyse statique de code source au nez et à la barbe des pointures C++ aguerries.

    Explications

    Pour des questions de performance, le standard C++ (avant C++17) indique que c’est le compilateur qui optimise l’ordre d’évaluation du chaînage et des paramètres de fonction. Le standard utilise le terme unsequenced (séquencement non défini). Le C et le C++ partagent ensemble cette règle.

    Donc, l’expression replace(find()).replace(find()) dans la fonction f2() peut être évaluée dans des ordres différents. En théorie, la variable s pourrait donc contenir différents résultats. Et c’est aussi le cas en pratique :

    Compilateur Résultat contenu par la variable s
    GCC et MSVC I have heard it works evenonlyyou donieve in it
    LLVM/Clang I have heard it works only if you believe in it

    Détails

    Ci-dessous, la première ligne déclare et initialise un objet std::string. La seconde ligne cherche et remplace plusieurs caractères de cette std::string en utilisant le chaînage des fonctions replace.

    std::string s = "but I have heard it works even if you don't believe in it";
    s.replace(0,4,"").replace(s.find("even"),4,"only").replace(s.find(" don't"),6,"");

    Intuitivement, on s’attendrait à évaluer les arguments des fonctions comme find("even") juste avant d’appeler replace(resultat,4,"only"). Mais ce n’est pas le cas avant C++17, ces arguments peuvent être évalués dans différents ordres. Plus de détails sont donnés par Shafik Yaghmour (en Anglais).

    Le tableau ci-dessous présente sur chacune des sept lignes, un ordre d’appel possible selon les standards C++ (avant C++17) et C (en supposant que ce soit une struct string avec des pointeurs de fonction).

    1ᵉʳ appel 2ᵉ appel 3ᵉ appel 4ᵉ appel 5ᵉ appel
    find(" don't") find("even") replace(0,4,"") replace(f,4,"only") replace(f,6,"")
    find("even") find(" don't") replace(0,4,"") replace(f,4,"only") replace(f,6,"")
    find(" don't") replace(0,4,"") find("even") replace(f,4,"only") replace(f,6,"")
    find("even") replace(0,4,"") find(" don't") replace(f,4,"only") replace(f,6,"")
    replace(0,4,"") find(" don't") find("even") replace(f,4,"only") replace(f,6,"")
    replace(0,4,"") find("even") find(" don't") replace(f,4,"only") replace(f,6,"")
    replace(0,4,"") find("even") replace(f,4,"only") find(" don't") replace(f,6,"")

    C++17 n’autorise qu’une seule possibilité, la dernière du tableau, et correspond à celle de la fonction f() du livre :

    s.replace(0, 4, "");
    s.replace(s.find("even"), 4, "only");
    s.replace(s.find(" don't"), 6, "");

    Autres exemples

    Par exemple, dans l’expression f().g(h()) la fonction f() peut-être appelée avant ou après h(). Le standard C++ fait la différence entre unspecified (non-spécifié) et unsequenced (non-séquencé). Ce comportement est bien spécifié, donc jusqu’à C++14 c’est unsequenced. À partir de C++17, c’est f() avant g() (sequenced before).

    // Avant C++17, f() peut être appelée avant ou après h()
    f().g( h() ); 
    // C++17 est plus intuitif : f() est toujours appelée avant h()

    C’est aussi le cas de l’expression std::cout << f() << g() << h(); dont les trois fonctions peuvent être appelées dans n’importe quel ordre.

    // Avant C++17, le compilateur décide l’ordre d’évaluation de f(), g() et h()
    std::cout << f() << g() << h() << std::endl; 
    // C++17 fixe l’ordre intuitif : d’abord f(), puis g() et enfin h()

    Encore d’autres exemples que le C++ partage avec le C :

    std::map<int, int> m;
    m[0] = m.size();
    std::cout << m[0]; // Affiche 0 ou 1 ?
    // Clang  : 0
    // GCC    : 1
    // MSVC++ : 0
    int i = 0;
    std::cout << i << ' ' << i++; // Affiche 0 0 ou 1 0 ?
    // Clang  : 0 0
    // GCC    : 1 0
    // MSVC++ : 1 0
    int i = 0;
    i = i++ + 1;    // unsequenced
    std::cout << i; // Quelle valeur ?
    // Clang   : 1  mais avertit : multiple unsequenced modifications to 'i'
    // GCC-6.2 : 1  mais avertit : operation on 'i' may be undefined

    Ci-dessus, pour toutes les versions du C++ et du C, l’opération est unsequeced et non pas undefined comme GCC-6.2 le laisse supposer.

    int i = 0;
    i = ++i, i++, i++, ++i, ++i, ++i, i++;
    std::cout << i; // Quelle valeur ?
    // Piège, toujours 7 car c'est "sequenced before"
    // GCC-6.2 avertit : operation on 'i' may be undefined

    Notons que GCC-6.2 suppose encore que l’opération est undefined alors que dans ce dernier cas, l’opération est sequenced before quelque soit la version du C++ (et même du C).

    Conséquence

    Donc, beaucoup de codes sont potentiellement truffés de ces pièges, ce qui est également le cas quand std::future<T> est utilisé. Tout le monde se fait avoir, débutants comme experts. Et le comité de normalisation du C++ a donc amendé sans trop discuter ce TS afin de fixer l’ordre d’évaluation dans certains cas.

    Et c’est justement cet exemple du livre The C++ Programming Language qui illustre le paragraphe 5.2.2 Function call (page 107) du standard C++ (brouillon de juillet 2016).

    Nouvelle règle

    L’évaluation est :

    • De la gauche vers la droite pour les expressions suffixées. Ceci inclue les appels de fonction et la section des membres ;
    • L’affectation de la droite vers la gauche (a = b = c = d) ;
    • Les opérateurs de décalage (shift operators) de la gauche vers la droite.

    Par contre, lorsque une surcharge d’opérateur est invoquée, la priorité arithmétique est utilisée.

    Peut-être que le code généré sera moins performant, et que les standards C et C++ divergent un peu plus, mais au moins, le langage C++ devient un peu plus intuitif.
    ¯\(ツ)

    Appel à participation

    La précédente dépêche a reçu 227 commentaires, soit un volume dix fois supérieur à la dépêche elle-même. Tous ces commentaires cachent tout de même quelques joyeux trolls velus !

    Quand on pense à toute cette énergie dépensée et toutes ces heures consacrées à rédiger ces 227 commentaires ! Avec le recul nous aurions pu concentrer tout cet investissement dans une dépêche collaborative du style « Aujourd’hui, est-il pertinent de choisir le C++ pour une nouvelle application ? ».

    Panneau Please Do Not Feed the Trolls Panneau Troll barré

    Mais il n’est jamais trop tard ! Aussi nous proposons vous de rédiger la dépêche « Faut-il continuer à apprendre le C++ ? » Les nombreux commentaires de la dépêche précédente méritent d’y être copiés. Malheureusement, ceux-ci sont rarement sous licence compatible CC BY-SA 4.0. Ceci est donc un appel à tous leurs auteurs pour les copier dans cette dépêche afin de la nourrir. Ainsi, nous pourrons les structurer et proposer des réponses concises, claires et utiles à tous.

    Merci et à vos claviers !  

    Réutilisation

    Le texte de cette dépêche est protégé par le droit d’auteur la gauche d’auteur et réutilisable sous licence CC BY-SA 4.0. Les images utilisées sont aussi sous licence libre (cliquer sur l'image pour plus de détails).

    Donc n'hésitez pas à réutiliser ce contenu libre pour créer, par exemple, des supports de formation, des présentations (Meetups), des publications sur d’autres blogs, des articles pour des magazines, et aussi un article C++17 sur Wikipédia dès que Wikipédia passera de la licence CC-BY-SA-3.0 à la CC-BY-SA-4.0 (le contenu de cette dépêche utilise la version la CC-BY-SA-4.0).

    Les auteurs

    Par respect de la licence, merci de créditer les auteurs :

    Continuer à améliorer ce document

    Malgré tout le soin apporté, il reste certainement des oublis, des ambiguïtés, des fôtes… Bien que cette dépêche restera figée sur le site LinuxFr.org, il est possible de continuer à l'enrichir sur le dépôt Git du Groupe des Utilisateurs C++ Francophone (C++FRUG). C’est donc sur ce dépôt que se trouvent les versions les plus à jour.   (ღ˘⌣˘ღ)

    La suite

    Nous venons de découvrir un changement important au niveau du langage. La dépêche suivante nous dévoilera une autre nouveauté du C++17.

    Chère lectrice, cher lecteur LinuxFr.org. Tu souhaites apporter ta pierre à cet édifice ? Rejoins‐nous dans l’espace de rédaction collaborative sur LinuxFr.org (un compte est nécessaire pour y accéder).

    À suivre…

    Lire les commentaires

  • Montrez vos bobines (Dépêches LinuxFR)

    Même pour un circuit numérique, il y a une dose d’électronique d’analogique. « Malheureusement », penseront certain. Voyons les bobines, selfs ou inductances.

    Une bobine est un dipôle, qui n’a pas de sens de branchement. Sa grandeur principale se mesure en Henry (H). Elle va de quelques picoHenry (pH), à quelques Henry (H). La petite équation est u = L * di/dt.

    tores

    u(t) = L \cdot \frac {di(t)}{dt}

    Pour se rappeler de l’équation, il suffit de se souvenir que des personnes se sont amusées à brancher des bobines sur le secteur, par exemple, un transformateur 5 V mis à l’envers (un transformateur est composé de 2 bobines, ou plus, qui partagent leur champ magnétique). Ils sont morts en débranchant le système, ce qui provoque un énorme arc électrique. En effet, le courant passe d’une valeur fixe à zéro en une fraction de seconde, la dérivée du courant est très grande, ce qui produit une très grande tension qui fait « claquer » l’air, c’est-à-dire que, comme pour un éclair, l’air devient conducteur (à partir de 3,6 kV/mm sous air sec, moins avec de l’humidité ambiante).

    On peut remarquer que si un condensateur « intègre », une bobine « dérive » le courant. Il y a une dualité entre les 2 composants.

    Les bobines sont composées d’enroulement d’un fil, autour d’un cœur. La valeur d’inductance dépend du nombre de spires (de tours de fils), et de la matière du cœur.

    L’enroulement est fait en fils de cuivre, moins résistant électriquement que l’aluminium. Si le fil est fin et avec beaucoup de spires, la résistance série parasite n’est plus négligeable.

    Le matériau magnétique permet d’augmenter L, l’inductance, sans augmenter le nombre de spires, par rapport à une bobine « à air ». Mais au contraire de l’air, ces matériaux « saturent ». Arrivé à un certain niveau de courant électrique, la valeur L s’écroule, et la self se comporte comme une simple résistance. Les bobines à air ne saturent pas, mais sont bien plus grandes, pour avoir la même valeur d’inductance, et, évidemment, la résistance série parasite augmente avec la taille de la bobine.

    Pour certains circuits de précision, il peut être utile d’utiliser une grosse bobine à air pour pouvoir comparer le résultat avec la bobine définitive plus petite.

    Il existe 2 formes physiques : le plot ou le tore. Le plot peut être plus facile à placer sur une carte, mais il rayonne plus (produit plus de parasites) qu’un tore.

    Seule

    La self de choc ou d'arrêt est un moyen de filtrage de parasite. Un moteur génère toujours des tensions parasites plus ou moins fortes. Même si les alimentations sont séparées, la masse est commune. Or les parasites peuvent aussi passer par là. Mettre une bobine de choc, pour relier les masses évitent d’avoir des resets intempestifs d’un microcontrôleur, par exemple (vécu).

    La plus petite en dessous vaut environ 1 € et supporte jusqu’à un courant de 1 A.

    2chocs
    -- Deux selfs dites « de chocs », utilisées comme anti-parasites. (CC-BY 2.0 - auteur: Oskay)

    Sur certains câbles, comme les câbles USB, on peut voir un gros bloc plastique, qui a une fonction similaire.

    Réservoir d’énergie

    Le principe de certaines alimentations à découpage est de générer un signal carré, dont la valeur moyenne est la tension recherchée. Ce genre d’alimentation utilise le fait que les transistors MOS ne consomment presque pas d’énergie, quand ils sont passants ou saturés.

    Ensuite, il faut filtrer la sortie pour ne récupérer que cette moyenne, ou la « très basse fréquence », qui est la tension recherchée. Si on filtre avec un classique filtre RC, une grosse partie de l’énergie partira en chaleur dans la résistance. Un filtre LC filtre sans dissiper l’énergie (hors résistance série parasite). Les deux éléments L et C stockent l’énergie à des moments différents.

    Il est question d’éléments de puissance, les fils de la bobine doivent être assez gros pour limiter les pertes ohmiques.

    tores
    -- Self torique utilisée comme réserve d'énergie. (CC-BY 2.0 - auteur: Oskay)

    Sur l'image, le fil est doublé pour diminuer la résistance.

    J’ai peu utilisé les bobines, en dehors des selfs de choc et d'une alimentation à découpage. C’est le seul composant qui peut se faire à la main, pour avoir le meilleur résultat. Il peut être compliqué de trouver des bons cœurs magnétiques, ou de trouver le câble de 2 mm, protégé par un vernis, typique des applications dans le domaine de puissance qui intéresse un hobbyiste (1 à 100 W). Mais il est plaisant d’avoir sa propre alimentation, à une tension peu commune, pour fournir 6 V/20 A, pour des servomoteurs branchés sur une batterie 12 V, par exemple.

    En conclusion, il faut se rappeler qu’il existe plusieurs sortes de bobines qui peuvent supporter un courant maximum, avant de se transformer en résistance.

    Vous pouvez reprendre une activité normale (comme regarder les réseaux sociaux).

    Lire les commentaires

  • Liberapay, plateforme libre de dons récurrents (Dépêches LinuxFR)

    Liberapay est un service permettant de faire des dons récurrents, acceptant des dons à partir de 0.01€ par semaine, afin d'assurer aux créateurs un revenu stable tout en offrant aux contributeurs la possibilité de payer suivant leurs moyens. Liberapay se démarque des autres plateformes de ce type en se finançant sur son propre modèle, et non pas par prélèvements sur les transactions.

    Logo de Liberapay

    Sommaire

    Le financement des communs

    Les personnes qui contribuent aux communs ont besoin de soutien. Construire des logiciels libres, diffuser les savoirs libres, ces choses prennent du temps et coûtent de l'argent, non seulement pour effectuer le travail initial, mais aussi pour le maintenir dans le temps.

    Le financement des communs

    Un rapport intitulé Roads and Bridges a été publié cette année par Nadia Eghbal sur ce sujet. Il y a une traduction française, Des routes et des Ponts, en cours sur le Framablog.
    Il est consacré plus particulièrement à « l'infrastructure numérique », cette nouvelle catégorie de biens communs que l'on peut difficilement faire payer aux utilisateurs et qui n'est pas non plus financée par les pouvoirs publics comme l'est l'infrastructure routière classique. Trouver des moyens pour rémunérer ces biens communs dont fait partie le logiciel libre est important pour la santé de tout l'écosystème informatique. De façon plus générale, nous pensons que financer les gens qui enrichissent les communs est important, car ce qui fait partie des communs enrichit finalement toute la société.

    Il existe des moyens variés de rémunérer les auteurs des communs. Nous avons choisi d'encourager le don avec Liberapay. Pas un pseudo-don avec contrepartie, ni même du mécénat où le mécène associe son nom à de beaux projets ; non, nous parlons d'un vrai don, désintéressé autant que possible.

    • Il n'y a pas de contrepartie : les donateurs décident de donner pour ce qu'ils connaissent du travail de l'auteur, pour permettre à ce dernier de continuer son travail. Cela évite de perdre du temps à s'occuper de contreparties et dépenser une partie de l'argent dans des goodies pas franchement nécessaires. L'inconvénient étant que sans contrepartie, il faut vraiment être désintéressé pour donner, ce qui n'encourage pas tout le monde.
    • Anonymat : la personne qui reçoit le don ne sait pas qui lui a donné. Le donateur sait évidement à qui il donne et combien… mais il est le seul à savoir. Cela évite qu'un gros donateur puisse influencer les développements futurs. Cela évite aussi de tomber dans un salariat déguisé.
    • Stabilité : Liberapay veille aussi à fournir des revenus stables. Les dons sont hebdomadaires, récurrents et les donateurs sont encouragés à donner sur plusieurs semaines plutôt que tout en une fois. Ces dons hebdomadaires peuvent être très bas : 0,01 € par semaine minimum, soit 52 centimes par an… ceci afin d'accepter toutes les contributions, même très modestes. Un donateur ne peut pas donner plus de 100 €/semaine à une personne ; cela évite à la fois que les revenus de quelqu'un soient trop impactés si l'un de ses gros donateurs arrête de donner, et cela évite aussi que le don soit assimilé à un salaire déguisé. Si vous avez envie de donner plus, donnez aux équipes, à plus de projets… les façons de dépenser son argent ne manquent pas !

    Limites et inconvénients du don

    La première limite est celle de la communauté. Même si le fait de ne pas gérer les contreparties réduit un peu le travail, il faut quand même prendre le temps de communiquer sur ses besoins financiers, et donc d'avoir des gens à qui le dire et qui seront prêts à aider. C'est une des choses que beaucoup de petits projets libres oublient de gérer, ce qui les dessert… Pourtant, pas besoin de savoir coder pour parler du projet sur tous les réseaux sociaux et souhaiter la bienvenue à ceux qui arrivent, c'est donc un boulot qui peut être délégué à un contributeur qui n'a pas les compétences sur la partie code. Créer et animer une communauté est un travail sur lequel il faut quand même se former, mais ça tombe bien, Framabook a édité un livre sur la question : Logiciels et objets libres. Animer une communauté autour d’un projet libre par Stéphane Ribas, Patrick Guillaud et Stéphane Ubeda. Pour les anglophones, je conseille aussi Community Building on the Web: Secret Strategies for Successful Online Communities d'Amy Jo Kim ; certains passages sont un peu datés mais ça reste très pertinent sur toute la partie animation au sein d'une communauté. Il y a une tentative de résumé ici, pas finie, à retravailler, mais ça donne quelques bases quand même.

    La seconde limite est liée à la législation. Et, oui, les dons se déclarent ! Déclarer un salaire, ça va, c'est presque facile… enfin, on trouve la doc. Déclarer un don qu'on a reçu, c'est vite compliqué suivant votre statut, votre pays, la somme reçue… Il y a plein de cas particuliers et là, les informations sont assez éparpillées. Nous pouvons vous fournir quelques pistes parce que nous avons étudié la question, mais prenez aussi le temps d'aller demander aux services des impôts dans quelle case vous allez rentrer. Si vous faites déjà appel à un comptable par ailleurs, posez-lui aussi la question, c'est lui qui trouvera la meilleure façon de déclarer tout ça. S'il y a quelques juristes parmi les lecteurs et lectrices, nous serions ravis que vous nous aidiez à rédiger quelques fiches de conseils sur la question…

    Fonctionnalités de Liberapay

    Toute personne peut s'inscrire à Liberapay, qu'il s'agisse d'une personne physique ou morale. Ce sont les personnes qui vont pouvoir déposer de l'argent et en retirer sur Liberapay.

    Les personnes peuvent s'organiser en équipes, ce qui permet à un collectif sans structure légale de recevoir des dons. Chaque membre de l'équipe décide de la part qu'il prend et le logiciel répartit les dons à l'équipe entre les membres de façon automatique. Pour éviter qu'un membre décide d'une semaine à l'autre de faire passer sa part de 1 à 100, il y a une fonctionnalité qui empêche de modifier cette part au-delà d'un certain seuil d'une semaine à l'autre. Nous avons décidé de favoriser le consensus au sein des équipes : n'importe quel membre d'une équipe peut inviter d'autres personnes à rejoindre l'équipe et chaque membre décide de lui-même de la part qu'il souhaite prendre. Pour le moment, il n'y a eu aucun problème avec ça, personne ne demande plus que "sa" part ; en fait, la plupart des contributeurs n'osent pas demander une vraie part au sein des équipes où ils travaillent…

    Chaque personne et chaque équipe peuvent annoncer combien elles souhaitent recevoir par semaine ; chacun est aussi libre de dire combien il reçoit et combien il donne. Les paramètres de confidentialités peuvent être paramétrés assez finement : chacun décide, finalement, de ce qu'il veut laisser public. Par contre, au sein d'une équipe, un tableau montre la part de chacun et ce qu'il a reçu la semaine précédente.

    Paramètres du profil

    Liberapay ne prend aucune commission sur les dons : nous utilisons aussi Liberapay pour fonctionner et nous ne comptons que sur les dons. Il y a par contre quelques frais de transactions liés aux intermédiaires financiers, lorsque l'argent rentre ou sort de Liberapay (suivant votre banque et votre pays). Si vous êtes dans l'espace SEPA, il n'y aura que les frais de Mangopay, notre opérateur de paiement, qui sont très bas et uniquement au moment de donner l'argent. C'est une des raisons qui nous a motivés à demander un débit minimum de 15 € aux donateurs, afin de réduire ces frais ; l'argent est ensuite dans votre portefeuille sur Liberapay et transféré aux bénéficiaires de vos dons durant chaque Payday. Si vous décidez de donner 0,01 € par semaine à une seule personne, par exemple, vous lui assurerez un revenu durant 1 500 semaines ! L'argent collecté peut être retiré directement sur votre compte bancaire, de façon gratuite au sein de SEPA.

    Actuellement, nous acceptons les paiements par carte bancaire et virements ; nous avons prévu de mettre en place d'autres méthodes de paiements par la suite. Un de nos contributeurs souhaitait ajouter le support de bitcoin, par exemple, mais il n'a pas le temps de travailler dessus. Toutes les transactions sont actuellement en Euros ; ajouter d'autres monnaies demande du développement et ce n'est pas pour tout de suite, mais ça viendra sans doute.

    Liberapay permet de faire des promesses de dons à des utilisateurs qui n'ont pas encore rejoint le site. On peut d'ailleurs chercher ses amis contacts sur Twitter, Facebook, GitHub et Bitbucket pour le moment, peut-être sur Diaspora* ou Movim un de ces jours ! Vous pouvez aussi lier votre compte à d'autres sites web, dont votre profil Linuxfr.

    "Viens sur Liberapay, je t'offre un café là-bas !" Généré avec https://framalab.org/gknd-creator/.

    Il y a aussi des “communautés” pour regrouper les utilisateurs autour d'un point commun, par exemple un langage de programmation. Il est prévu d'ajouter le support des listes de diffusion au sein des communautés.

    Le site est résolument multilingue. L'interface est déjà traduite dans de nombreuses langues, dont l'espéranto ; les traducteurs peuvent facilement contribuer via weblate. Chaque utilisateur peut aussi écrire son message de présentation dans plusieurs langues. La langue ne doit pas être un frein à l'utilisation d'un tel service et grâce aux traducteurs, c'est accessible à un grand nombre de personnes.

    Enfin, nous proposons des "widgets" : des exemples de code à intégrer sur vos pages web pour inviter les gens à vous faire des dons et pour indiquer combien vous recevez ou donnez.

    Particularités

    Liberapay est organisé sous forme d'association collégiale à but non lucratif. Non, nous ne sommes pas une entreprise ! Nous sommes basés en France et nous suivons donc la législation française, bien que nos services soient sur un serveur aux USA (hébergement par Red Hat). Si vous nous proposez un hébergement, on prendra, car visiblement Red Hat ne va pas continuer longtemps à héberger gracieusement des projets.

    L'un de nos principes fondateurs est la neutralité. « Le service est ouvert à tous, l'association n'exclut un utilisateur que si elle en a l'obligation légale ou contractuelle. » (Article 10 des statuts de l'association). Nous ne sommes pas la police des Internets, ce n'est pas à nous de juger ce qui est bien ou mal. Nous pensons que la liberté de chacun doit être respectée, y compris celle des gens que nous n'aimons pas. Dans l'absolu, nous préférerions que l'exclusion d'un utilisateur dépende uniquement d'une décision de justice. En pratique, notre opérateur de paiement est moins neutre que nous et nous a déjà demandé virer un utilisateur ayant des convictions politiques extrémistes. Cette neutralité trouve aussi ses limites dans le respect de la loi : nous faisons ce qu'il faut pour lutter contre le blanchiment d'argent, et dans cette époque de lutte contre le terrorisme, nous répondons aux demandes des autorités. Il s'agit là uniquement de respecter nos obligations légales en tant qu'intermédiaire de paiement… Nous n'en ferons pas plus. Bon, et entre nous, pour blanchir de l'argent ou financer le terrorisme, il y a peut-être plus efficace qu'un service qui limite à 100€ par semaine les donations d'une personne à une autre. Tout ça concerne des situations extrêmes : notre volonté de neutralité était surtout motivée, à la base, par l'idée que ce n'était pas à nous de trancher entre emacs et vim, archlinux et debian, féministe ou je-m'en-foutiste.

    Nous l'avons déjà dit, mais Liberapay est financé à travers lui-même, via un compte équipe qui reçoit des dons destinés à l'entretien et l'amélioration du service.

    C'est un vrai projet libre, bien au-delà de la licence (CC0) : il est ouvert à tous et transparent. Vous pouvez contribuer, entrer dans l'équipe Liberapay, et vous rémunérer. La licence peut surprendre pour du logiciel : nous l'avons hérité du fork d'avec Gratipay et comme elle nous convient, nous n'avons rien changé.

    La petite histoire

    Liberapay est un fork de Gratipay. En 2012, Chad Whitacre a fondé Gittip aux États-Unis d'Amérique, avec comme concept de payer les individus de manière récurrente pour leurs contributions, anonymement et sans contrepartie. Une première crise en 2014 amène des changements dans la gestion de la communauté ; en 2015 une crise légale amène Gittip à se renommer Gratipay, avec un fonctionnement complètement différent. Changaco, le fondateur et développeur principal se lance alors dans le fork, suite à une conversation sur Diaspora*, dans l'optique de proposer une alternative européenne, plus proche du Gittip originel, la neutralité en plus et avec un fonctionnement plus ouvert. L'association est créée en décembre 2015 et le site est lancé en février 2016.

    À travers Liberapay, nous avons fait un certain nombre de paris assez audacieux : miser sur le don, sur le consensus, sur la neutralité… Après ces quelques mois d'existence, nous avons déjà eu affaire à des gens qui avaient une perception moins humaniste du monde, permettant de mettre à l'épreuve ces belles idées. De façon surprenante, ça marche assez bien et nous avons réussi à traverser les situations explosives sans trop de dégâts.

    Liberapay et vous

    Vous pouvez créer un compte sans forcément renseigner vos informations bancaires ; dans ce cas, nous pourrons vous tenir au courant des actualités via le mail. Il y a aussi plein de projets et de personnes qui seront ravis de recevoir vos dons (dont l'équipe de Liberapay !) ; vous pouvez aussi vous lancer dans l'aventure et encourager vos utilisateurs à vous rémunérer pour ce que vous faites.

    Liberapay a besoin de fonds, mais aussi de contributeurs :

    • Il n'y a que Changaco à plein temps qui travaille sur le code et il est loin d'être assez payé pour ça ;
    • Côté développement, intégrer un forum à Liberapay ou les listes de diffusion seraient vraiment un plus, ainsi que diverses fonctionnalités :
    • Des graphistes ! Le site web profite de Bootstrap pour ne pas être trop vilain, mais une vraie identité graphique serait tellement agréable, tout en veillant à l'accessibilité ;
    • Si vous aimez traduire, vérifiez les traductions déjà faites et contribuez à traduire dans d'autres langues ;
    • Si vous aimez le contact, communiquez sur Liberapay ! Et si vous n'êtes pas trop fâchés avec les réseaux sociaux privateurs, on veut bien un peu d'aide pour la promotion sur Facebook et Twitter…

    Lire les commentaires

  • HiFive1: Un Arduino à 320Mhz entièrement libre pour 2017 (Journaux LinuxFR)

    À l'heure où j'écris ces lignes a lieu le 5 ème workshop sur jeux d'instruction libre (ISA Risc-V au campus google à Mountain View.

    Et c'est à cette occasion qu'est présenté la carte HiFive1 composée d'un microcontrôleur Freedom Everywhere 310 (FE310) à cœur SiFive (utilisant le jeux d'instructions Risc-V). Une carte compatible Arduino mais 10 fois plus puissante et entièrement libre, jusqu'au silicium.

    La description hardware en Chisel/Verilog est disponible sur github et il est possible de simuler intégralement le modèle qui tournera sur la carte.

    Contrairement à l'open-v, le développement du HiFive1 est déjà terminé et le crowdfunding organisé n'est là que pour les précommandes.

    La société SiFive se base sur ce microcontrôleur ainsi que sur un microprocesseur Freedom U500 pour promouvoir son savoir faire et proposer à ses clients des puce «full-custom» à base de briques opensource.

    Visiblement, pour 60$ il est donc possible de se procurer le kit compatible arduino intégralement open-source qui sera disponible en février 2017.

    Lire les commentaires

  • Sortie de passbolt v1.3.0 (Dépêches LinuxFR)

    La version 1.3.0 de passbolt est sortie le 25 novembre 2016. Passbolt est un gestionnaire de mots de passe, conçu pour la collaboration en équipe, sous licence libre AGPL. Cette sortie marque notamment le début de la prise en charge d’un greffon pour le navigateur chrome.

    Logo Passbolt

    Pourquoi un greffon?

    Un greffon est nécessaire pour garantir l'intégrité de la bibliothèque OpenPGP.js, utilisée pour le chiffrement des secrets. En effet, sous Chrome et Firefox, les extensions des navigateurs sont signées pour garantir que le code javascript n’a pas été modifié. Un autre bénéfice notable du greffon : à l'exécution, le code en charge de ces opérations sensibles est isolé par le navigateur d’autres codes JavaScript tournant sur la page, ce qui permet de mitiger les risques liés à une « attaque de l'homme du milieu » ou à l’ajout de scripts malicieux sur un serveur passbolt compromis.

    Passbolt sous chrome

    Autres nouvelles fonctionnalités

    À raison d’un peu plus d’une sortie par mois en moyenne, passbolt a évolué progressivement depuis la dépêche d’avril. Ainsi en plus de la résolution des bugs reportés sur GitHub qui permet notamment d’offrir une meilleure prise en compte des différents environnements côté serveurs (MySQL version 5.7, Nginx, BSD, etc.), le logiciel a vu apparaître quelques nouvelles fonctionnalités comme :

    • des notifications par courriel pour l'édition et la suppression de mots de passe ;
    • un système de recherche instantané ;
    • le visionnage des permissions dans la barre latérale ;
    • la gestion du même compte sur plusieurs machines ;
    • la mise en place d’un gestionnaire de mise à jour en ligne de commande.

    Une attention particulière a également été portée sur les tests unitaires et Selenium qui sont désormais intégrés avec Travis et saucelabs.

    Page de statut

    Prochaines versions

    Conformément aux souhaits de la communauté de passbolt, qui s’est exprimée lors d’un sondage, la prochaine étape pour le développement concerne l'implémentation des groupes d’utilisateurs, la documentation de l'API, ainsi que l’organisation d’un audit de sécurité indépendant. Dans ce but vous pouvez nominer passbolt au programme “Secure Open Source” de Mozilla.

    Côté administratif et financement

    L’agence nationale pour la recherche et l’innovation du Luxembourg a sélectionné passbolt pour intégrer son programme d’accélération fit4start. L’équipe a rejoint la promotion automne 2016 avec à la clef une subvention de 50000 € et des conseils personnalisés pour développer l'activité autour du logiciel.

    Rendez vous au FOSDEM !

    L’équipe passbolt sera présente lors du FOSDEM en février à Bruxelles. Nous espérons vous y retrouver nombreux pour répondre à vos questions, partager vos retours d’expériences et entendre vos suggestions concernant les évolutions futures.

    Lire les commentaires

  • Cohérence des fonctions d'arrondi (Journaux LinuxFR)

    Étant très inspiré par un récent journal, je me souviens de différences de comportements entre les langages de programmation.

    J'ai moins de détails techniques croustillants à mentionner, mais pour ceux qui manipulent des chiffres et des lettres, ça peut être intéressant.

    Supposons que l'on veuille arrondir une valeur. -0.5. Facile ? Et bien en fait, pas du tout !

    round(-0.5) =

    • Python: -1
    • WolframAlpha: 0
    • PHP: -1
    • JavaScript: -0
    • Matlab: -1
    • Java: 0

    Si l'on tient compte du zéro négatif de JS, on a 3 valeurs différentes, et aucune n'est aberrante vu qu'en fait, c'est très louche, la notion d'arrondi. Une petite recherche sur Wikipédia nous donne en fait cinq solutions d'arrondis pour lever l’ambiguïté ou diminuer les erreurs accumulées d'arrondis en arrondis. Plutôt que de se perdre dans les détails, on va regarder les arrondis uniquement dans le domaine de l'informatique :

    • Arrondi vers moins l'infini
    • Arrondi vers plus l'infini
    • Arrondi vers zéro
    • Arrondi au plus loin de zéro
    • Arrondi au nombre pair : si à 0.5 près alors arrondi selon le bit de poids faible donc statistiquement 50% du temps au supérieur et 50% à l'inférieur

    Le comportement recommandé est le dernier car statistiquement, les erreurs d'arrondis des .5 ne se cumulent pas mais s'annulent. En pratique, on obtient :

    • round(11.5) = 12
    • round(12.5) = 12
    • round(-11.5) = -12
    • round(-12.5) = -12

    On comprend donc mieux le nom d'arrondi vers le nombre pair. Cet arrondi s'appelle aussi arrondi bancaire.

    J'espère que vous avez appris quelque chose et qu'un bête arrondi n'a en fait rien de bête même si c'est utilisé quotidiennement à grande échelle.

    Dans la même veine, vous pouvez découvrir en anglais les innombrables subtilités des nombres flottants.

    Je laisse la main à quelqu'un d'autre dans la série "Cohérences" :)

    Lire les commentaires

  • Des "basheries" (Journaux LinuxFR)

    Sommaire

    Salut,

    Voici un journal qui répertorie les quelques raccourcis et commandes que j'ai découverts au fil du temps et de balades sur le net (blogs, forums, wiki, man bash, etc.). J'essaie de faire une liste ici de ceux qui me semblent vraiment utiles pour l'utilisation quotidienne du terminal par un utilisateur lambda. Je fais partie de cette catégorie, je ne suis ni un programmeur, ni un utilisateur averti, je fais de la recherche en sciences humaines et sociales et de l'édition. Aujourd'hui, je n'utilise quasiment plus qu'un navigateur web et un terminal (vim, mutt, pandoc, etc.). Dans mon domaine, on voit de plus en plus de gens s'intéresser à des outils comme vim, mais ils sont rebutés par l'utilisation du terminal lui-même (avant même celle de vim). Voilà donc quelques astuces qui facilitent grandement l'utilisation d'un terminal utilisant le shell unix bash.

    Des raccourcis utiles

    • Ctrl + a : Pour aller au début de la ligne
    • Ctrl + e : Pour aller à la fin de la ligne
    • Ctrl + b : Pour se déplacer d'un caractère vers l'arrière (flèche gauche)
    • Ctrl + f : Pour se déplacer d'un caractère vers l'avant (flèche droite)
    • Alt + b : Pour se déplacer d'un mot vers l'arrière
    • Alt + f : Pour se déplacer d'un mot vers l'avant
    • Ctrl + xx : Pour passer de la position du curseur au début de la ligne et revenir à la position où se trouvait le curseur

    • TAB : Pour compléter automatiquement les noms de fichiers/dossiers/commandes

    • Ctrl + d : Pour effacer le caractère sur lequel se trouve le curseur

    • Ctrl + h : Pour effacer le caractère précédant le curseur (la fonction classique du retour arrière)

    • Alt + d : Pour effacer le mot suivant le curseur

    • Alt + retour arrière : Pour effacer le mot précédant le curseur

    • Ctrl + l : Pour nettoyer l'écran (l'équivalent de la commande clear)

    • Alt + t : Pour échanger la place du mot où se trouve le curseur avec celui le précédant

    • Ctrl + t : Pour échanger la place des deux caractères précédant le curseur

    • Ctrl + w : Pour couper le mot précédant le curseur

    • Ctrl + k : Pour couper la partie de la ligne suivant le curseur

    • Ctrl + u : Pour couper la partie de la ligne précédant le curseur

    • Ctrl + y : Pour coller la dernière chose coupée

    • Ctrl + _ : Pour annuler la dernière modification (undo)

    • Ctrl + j : Pour créer une nouvelle ligne

    • Ctrl + c : Pour arrêter la commande en cours et créer aussi une nouvelle ligne

    • Ctrl + r : Pour rechercher une commande précédente dans l'historique

    • Ctrl + g : Pour quitter la recherche dans l'historique

    • Ctrl + p : Commande précédente (flèche haut)

    • Ctrl + n : Commande suivante (flèche bas)

    • Ctrl + x + e : Pour lancer un traitement de texte (nano par ex.) pour écrire une longue commande.

    La dernière commande

    • !! : Pour répéter la dernière commande
      Notamment très utile quand on oublie de mettre sudo avant une commande.
      $ apt install apt (qui donne une erreur parce qu'on a oublié sudo)
      $ sudo !!

    • alt + . : Pour ajouter le dernier argument de la dernière commande
      $ vim todo.txt
      $ mv [alt + .]todo.txt ~/tmp

    • !$ : Egalement utile pour ajouter le dernier argument de la dernière commande

    • !* : Pour reproduire tous les arguments de la dernière commande
      C'est utile si vous faites une erreur du genre :
      $ vim cd ~/downloads
      $ !*
      ce qui donnera
      $ cd ~/downloads

    • !foo : Pour réutiliser la dernière commande en commençant par foo (on peut aussi faire foo !!)

    • !:- : Pour réutiliser la dernière commande sans le dernier argument
      Un exemple:
      $ ping -c 3 linuxfr.org
      $ !:- framasoft.org
      Ce qui donnera
      $ ping -c 3 framasoft.org

    • A ces commandes, vous pouvez ajouter à la fin :p (par ex. !*:p) pour afficher la commande sans qu'elle se lance.

    Astuces au quotidien

    • $ cp ~/.vimrc{,.old}
      Qui correspond à
      $ cp ~/.vimrc ~/.vimrc.old
      Ca marche aussi pour supprimer une extension par ex. pour transformer "blabla.txt" en "blabla"
      $ mv blabla{.txt,}
      Ou pour utiliser l'extension markdown à la place du .txt :
      $ mv blabla{.txt,.md}

    • ..
      Qui correspond au dossier parent de celui dans lequel on se trouve. Par ex. : cd .. emmène au dossier parent de celui dans lequel on se trouve. Cela peut aussi être utile pour copier un fichier cp foo.txt ..

    • .
      Cela correspond au dossier dans lequel on se trouve. Par ex.: cp ~/downloads/foo.txt .

    • cd -
      Qui emmène au dernier dossier dans lequel on se trouvait

    • En cas de coquille, on peut corriger la commande précédente erronée ainsi:
      mvi todo.txt
      ^mvi^vim

    • Pour appliquer une action (supprimer, copier, etc.) sur de nombreux fichiers qui ont des noms similaires, on peut utiliser l'astérisque. Par ex.:
      $ ls
      Fichier1.txt
      Fichier2.txt
      Fichier3.txt
      Fichier4.txt
      $ rm Fichier* (cela supprimera tous les fichiers commençant par "Fichier")
      ou
      $ rm *.txt (cela supprimera tous les fichiers ayant l'extension ".txt")

    • Pour renommer rapidement une série de fichiers, on peut utiliser rename ainsi :
      $ ls
      Fichier1.txt
      Fichier2.txt
      Fichier3.txt
      Fichier4.txt
      $ rename 's/Fichier/texte/' *.txt
      $ ls
      texte1.txt
      texte2.txt
      texte3.txt
      texte4.txt

    • Pour changer les extensions de plusieurs fichiers (en utilisant toujours rename, il est possible d'utiliser d'autres méthodes bien évidemment, avec find par ex.) :
      rename 's/\.txt$/\.md/' *.txt

    • ls -thor
      Pour invoquer le pouvoir du marteau ! Et accessoirement lister de façon complète et lisible les fichiers d'un dossier en fonction de leur date de modification (de la plus ancienne à la plus récente). Il n'y aura pas les fichiers cachés dans la liste. Pour cela il faut invoquer les écritures saintes ls -torah.

    • Pour supprimer tous les fichiers dans un dossier sauf un type de fichier (pdf et zip par ex.)
      $ rm !(*.pdf|*.zip)

    Toutdoux liste

    Une commande utile (un peu dangereuse) si vous maintenez un fichier ~/faire.txt (le fameux todo.txt, que je maintiens personnellement selon une méthode "Getting things done" à ma sauce). Je maintiens aussi un fichier ~/lecture.txt (le sujet de l'exemple ci-dessous) dans lequel j'ai une liste de livres/articles à lire (utile pour mon boulot, notamment avant de me rendre à la bibliothèque).
    Pour ajouter une ligne à un fichier
    $ echo "- Luciano Floridi, the fourth revolution, Oxford University Press, 2014" >> ~/lecture.txt
    Cela ajoute une ligne à la fin de ce fichier contenant ce qui se trouve entre guillemets (en passant cet auteur peut vous intéresser).
    C'est une méthode un peu dangereuse, parce que si on ne met qu'un ">" à la place de 2 ">", on écrase le fichier.

    Je peux donc lancer rapidement un terminal (j'ai un raccourci pour cela) et faire un less lecture.txt pour voir la totalité de la liste.
    Je peux aussi faire un head -5 lecture.txt pour afficher les 5 premières lignes, ou les 5 dernières avec tail -5 lecture.txt.

    Mais encore une fois, attention à ne pas faire $ echo "blabla" > lecture.txt ! Cela supprimera le contenu du fichier et ne laissera que "blabla".

    Le partage facile d'un dossier au sein d'un réseau

    Pour un partage facile d'un dossier avec une personne utilisant le même réseau, on peut lancer une commande créant un serveur depuis le dossier à partager :
    python3 -m http.server
    Ca fonctionne aussi avec python2 : python -m SimpleHTTPServer
    Pour préciser le port il suffit d'ajouter le numéro à la fin de la commande : python3 -m http.server 8042
    Et d'autres langages peuvent faire la même chose bien sûr
    Avec ruby par ex.:
    ruby -run -e httpd . (le port sera indiqué au lancement de la commande mais c'est possible de le préciser avec -p par ex.: ruby -run -e httpd . -p 8042)

    A suivre

    Je m'attarde ici sur bash, mais cela devrait fonctionner mosso grodo avec les autres shell aussi (zsh notamment). Et je vise ici les astuces qui ne nécessitent pas de modifier .bashrc. Par ex., j'utilise certaines modifications de mon .bashrc comme :

    alias ll='ls -alF'
    alias la='ls -A'
    alias l='ls -CF'

    Quelques autres idées me viennent pour de futurs journaux, si ça vous intéresse : 1) un journal sur bashrc pour rendre la vie de l'utilisateur lambda plus facile 2) un journal sur un vimrc pour "non-programmeur", qui souhaite utiliser vim comme traitement de texte principalement 3) un journal sur des scripts bash utiles au quotidien pour un utilisateur lambda 4) un journal sur une automatisation (évitant notamment le danger du ">", faisant des sauvegardes, etc.) de ma liste de tâches. Il existe de nombreux programmes "todo list", mais je n'en ai trouvé aucun qui me satisfasse entièrement.
    Enfin… A suivre…

    Je vous laisse aussi ajouter d'autres raccourcis, commandes et astuces qui peuvent être utiles à un utilisateur standard selon vous (s'il y a des fautes, n'hésitez pas non plus).
    Cette liste n'est vraiment pas exhaustive. Elle représente ce que j'utilise le plus. Il y a de nombreux autres raccourcis et astuces sur la toile.

    Bonne bidouille !

    Lire les commentaires

  • Conférence LinuxFr(.org), mais refaire ? (Dépêches LinuxFR)

    L’événement Capitole du Libre 2016 a eu lieu le week-end des 19 et 20 novembre. Les différents supports de conférences, photos et vidéos seront bientôt mis en ligne par l'organisation (voir par exemple). Alors en attendant je vais vous parler de la conférence que j'y ai donnée.

    Benoît Sibaud devant le premier slide (photo de Wanda, organisation CDL)

    Son sujet : « le site LinuxFr.org existe depuis plus de 17 ans. Profitons-en pour une petite rétrospective tendance « Et si ? » Au fil des années, le site LinuxFr.org et l'association LinuxFr ont connu de multiples changements. Cela concerne les évolutions techniques (matériel et logiciel) bien sûr. Mais cela comprend aussi des changements législatifs (ce qui est permis/interdit, ce qu'il faut modérer, etc.). Le public n'est plus le même et la façon de lire le site non plus. Les thématiques ont évolué, par exemple de l'ordi perso vers les services en ligne et les mobiles. Le coût d'un tel site a changé en termes financiers (domaine, certificat, etc.) ou en tracas juridiques (plaintes et menaces). Les bénévoles du site se sont succédé. Pourrait-on refaire LinuxFr.org ? Le faudrait-il ? Que faudrait-il changer ? Et que faudra-t-il changer ? »

    Sommaire

    Benoît Sibaud devant le slide « Geekscottes »(photo de Wanda, organisation CDL)

    La conférence à Capitole du Libre

    Le support de conférence est disponible en PDF et en source HTML reveal.js (archive tar.xz). Ainsi que quelques photos prises par Wanda pour l'organisation ou par tankey depuis la salle. Merci aussi à Benoît Salles pour le gazouillage en direct.

    Sommaire de la conférence : c'est quoi LinuxFr.org ? pourquoi ce sujet plutôt qu'un autre ? le nom, l'association, les services aux adhérents ou aux visiteurs, le modèle économique, l'équipe, les serveurs, l'hébergement, les logiciels, les questions techniques, les licences, l'audience, la modération, le juridique / législatif et les chatons.

    Un mini-hackathon le jeudi 8 décembre 2016 à Paris

    Le mini-hackathon évoqué durant la conférence aura lieu le 8 décembre dans le cadre des Jeudi contribution au libre organisés par Parinux : en attendant d'organiser un événement dédié, commençons par profiter de la logistique d'un événement déjà en place et régulier. Et voyons aussi combien de gens viennent participer pour aider sur le code, l'écriture de contenus, les feuilles de style CSS, le graphisme ou l'administration système du site.

    Les questions hors conférence à Capitole du Libre

    Hors caméra/micro (de mémoire), quelques questions posées (les réponses données ici sont rédigées et ne correspondent pas forcément exactement à ce qui a été dit à chaud et en direct) :

    • Question : est-ce que tu es satisfait de venir à Capitole du Libre, avec une audience plus ou moins restreinte ?
    • Réponse : sur Capitole du Libre, il y a 13 autres conférences en parallèle et je ne m'attendais donc pas à faire salle comble. D'autant moins en sachant que je serais dans l'amphi de la plénière (capacité 400 places) :-). Dans les différentes conférences LinuxFr.org que j'ai pu faire (seul ou avec Bruno Michel par exemple), aux RMLL un peu partout ou aux Ubuntu Party à Paris, le public est toujours de quelques dizaines de personnes (globalement entre 20 et 50). Les visiteurs nous connaissent déjà pour la plupart, ce qui ne les incitent pas forcément à venir voir si notre conférence est palpitante ou non. Mais c'est intéressant de s'adresser à ceux qui ne connaissent pas encore le site et d'échanger sur la vie du site avec les autres. Et c'est aussi gratifiant de voir des gens satisfaits et reconnaissants.

    • Question : ça fait 16 ans que tu es dans l'équipe, est-ce que parfois tu n'as pas envie d'arrêter / passer à autre chose ?

    • Réponse : comme tout le monde je passe par des hauts et des bas niveau motivation, avec des hauts après les rencontres physiques et les réalisations techniques, et des bas après le xe spammeur de la journée, la ne intervention de modération pour calmer le jeu, la dernière accusation de diffamation reçue et le dernier commentaire péremptoire nous expliquant que ce que l'on fait est trop nul et qu'il existe une solution simple et magique. Des fois je me dis « L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes. (B. Russell) » (voir aussi l'effet Dunnin-Kruger, merci au dernier qui en a parlé ici récemment). Et d'autres fois je me dis « tant qu'il y aura des nouveaux, il y a aura des questions de nouveaux, des erreurs de débutants et des comportements de néophytes », et tant mieux qu'il y ait des nouveaux qui viennent, soyons inclusifs, accueillants et compréhensifs (et j'ajoute alors « vous allez finir par vous aimer les uns les autres, bordel de merde ! ». L'autre point, qui est d'ailleurs la conclusion de la conférence, c'est que le site LinuxFr.org est une chose plutôt rare actuellement, et qu'il serait difficile de le refaire ex-nihilo, il serait donc dommage de le laisser disparaître et il est donc important de continuer (au moins jusqu'à ce qu'une relève vienne dire aux vieux de l'équipe qu'il est temps de rentrer recompiler son noyau).

    • Question : la tribune est-elle problématique ?

    • Réponse : les échanges y sont limités aux utilisateurs authentifiés, éphémères (une quantité limitée de messages stockés) et non archivés (pas de stockage long-terme ni d'indexation par les moteurs de recherche), ce qui réduit grandement les risques de recevoir des mises en demeure. Certains sites externes archivent les échanges sur la tribune, mais cela relève alors de leur propre responsabilité. Pour le reste, la présence de quelques modérateurs sur la tribune suffit à régler les rares problèmes résiduels, notamment grâce à la possibilité d'en priver temporairement un compte d'accès. Globalement la tribune est donc peu problématique.

    • Question : comment as-tu reçu la mise en demeure / comment réagit-on dans ce cas ?

    • Réponse : sereinement sur le fond, mais agacé par la forme (directement un recommandé parlant de prison et demandant de l'argent). Nous en avons discuté en interne, avons évalué le contenu en question et avons choisi de publier la lettre (et le courrier de signalement au barreau de Paris par la suite). L'inspiration venait notamment de Chilling Effects (devenu depuis Lumen) et son utilisation par Google pour les notices DMCA notamment : pour rendre public et garder trace d'une demande de suppression, la demande est publiée.

    • Question : est-ce que l'on va refaire une dépêche sur les dons aux associations comme les années précédentes ?

    • Réponse : oui clairement. D'ailleurs si des gens veulent aider voire lancer la dépêche en reprenant celle de l'année passée, tant mieux. Et suite à la conférence sur la plateforme de dons récurrents Liberapay, une dépêche est en préparation sur le sujet, et Liberapay sera évoqué dans la dépêche sur les dons.

    Petite synthèse des échanges sur le sondage « La modération a posteriori des contenus et commentaires problématiques sur LinuxFr.org »

    Ce sondage montre un résultat inattendu (pour moi) : en excluant les réponse humoristiques, il semble que les répondants soient très largement satisfaits de la modération a posteriori (si tant est qu'un résultat de sondage DLFP soit non-inepte à 23,22% près).

    Les demandes :

    • plus de transparence sur la modération a posteriori, quantitativement (nombre d'opérations) et qualitativement (sur quels comptes) : sur le premier point, oui il faudrait (ajout dans l'entrée de suivi), sur le second point, il semble délicat et contreproductif de créer un mur de la honte. À noter que les rétrospectives de la quinzaine que je publie en journal rendent la modération plus transparente en termes de volumétrie (les « dont 5 masqués depuis » ou « dont 3 fermés depuis », mais pas les privations de commentaire et/ou de tribune), ainsi que par la nature des échanges sur la liste moderateurs@ ou la tribune de modération.
    • le retour des commentaires anonymes : sans solide argumentation nouvelle et compte-tenu des problèmes passés, aucune raison de revenir en arrière
    • faut-il ou non indiquer raison et modérateur dans les cas de modération a posteriori ? Voir l'entrée de suivi concernée
    • une modération moins « laxiste », mais sans dire comment l'obtenir
    • une proposition de modification des règles de modération pour indiquer le comportement attendu/souhaitable
    • le rappel de l'existence du kill-file sauce Usenet
    • l'ajout d'un bouton de signalement de contenu/commentaire problématique (voir l'entrée de suivi)
    • une gestion particulière des comptes postant par défaut à -10, par exemple une fermeture automatique du compte, un masquage automatique avec clic nécessaire pour démasquer, un captcha, etc. : en fait ça concerne assez peu de monde (3 comptes au moment du sondage, dont deux ont été fermés suite à ce sondage (voir ce commentaire notamment) et une autre demande de purge en réaction).
    • le filtrage par IP : rarement nécessaire, pour quelques spammeurs et quelques obsessionnels

    Petite synthèse des échanges sur le sondage « Comment vous inciter à contribuer plus souvent à LinuxFr.org ? »

    Le sondage contient diverses propositions :

    • des demandes de nouveau contenu (avec toujours la question « comment les susciter dans l'espace de rédaction ? ») :
      • des tests de distribution ;
      • des tutoriels ;
      • une nouvelle catégorie du genre annonce, sortie logicielle ;
      • des vidéos ;
      • des podcasts ;
      • etc.
    • des contenus plus courts : comment les susciter dans l'espace de rédaction ? (la crainte de « la page blanche » et de « ne pas être à la hauteur » revient régulièrement dans les retours sur le site ou les stands) ;
    • un signalement des meilleurs articles de la presse/des autres sites, et inversement le signalement de nos meilleurs articles à d'autres sites ;
    • promouvoir plus de journaux en dépêches, plus rapidement ;
    • ne pas oublier les dépêches compilant les sujets les plus intéressants : revues de presse de l'April, meilleurs journaux du mois, Agenda(s) du Libre ;
    • de la ludification (voir entrée de suivi) ;
    • moins de commentaires reproche et de notes décourageantes ;
    • la possibilité de rester « anonyme » en apparence tant que la note est négative ou pendant un certain temps ;
    • une identité plus « informatique libre » que linuxfr ;
    • un petit bouton par type de contenu qui crée une dépêche à partir d’un modèle avec quelques paragraphes pré-remplis ;
    • des demandes pour revoir la notation des commentaires (déjà plein de demandes dans le suivi sur ce sujet, plus ou moins argumentées) ;
    • des brouillons pour les journaux (entrée de suivi).

    Remerciements

    Et pour finir, merci à l'excellente équipe d'organisation de Capitole du Libre. Merci à ceux qui ont tenu le stand LinuxFr.org à Paris Open Source Summit pour les remarques/suggestions/corrections sur la présentation, et merci à tankey< pour son accueil sur Toulouse.

    Lire les commentaires

  • AG du L@bx 2016 (Journaux LinuxFR)

    Cher journal,
    L'association le L@bx organise sont AG le vendredi 2 décembre
    Le L@bx à 6 ans, et comme dans beaucoup d'association on retrouve un peu toujours les mêmes têtes ( dont la mienne ) au CA.
    il est bon d'avoir du sang neuf des nouvelle idées. Le labx est un hackerspace, un lieu d'expérimentation, donc venez vous expérimenter dans un CA :)

    L'AG se déroulera le vendredi 2 décembre 2016 à 20h30
    au 62 rue fiéffé
    33000 Bordeaux

    quelques liens :
    * nos statuts
    * notre charte qui doit être votée
    * l'ordre du jours

    Lire les commentaires

  • Cohérence des fonctions de tri (Journaux LinuxFR)

    Sommaire

    Nous allons discuter d'un point très simple, l’implémentation de la fonction max dans de nombreux langages. Nous allons voir que cette fonction est plus complexe qu'il n'y parait et que son implémentation différente entre de nombreux langages peut poser quelques problèmes.

    Introduction

    Que se passe-t-il quand on calcule le minimum ou le maximum de deux éléments identiques ?

    Dit autrement, soit x = max(a, b) si a == b, quelle est la valeur de x, a ou b ? L’intérêt peut sembler limité, mais il a ses applications quand on commence à calculer des minimums / maximums en utilisant une fonction de comparaison, comme il est possible dans de nombreux langages de programmation.

    Dit autrement, en supposant que l'on ait une fonction max(a, b, key) implémentée comme ceci en python :

    def min(a, b, key):
        if key(a) < key(b):
               return b
        if key(a) > key(b):
               return a
        if key(a) == key(b):
               return ???? # a ou b ?

    Le choix de renvoyer a ou b peut être important, comme je vais vous le montrer dans l'étude de cas qui suit.

    Petit problème

    Soit une liste l contenant N valeurs et des fonctions de pondération sur ces valeurs getWeightA et getWeightB. Le poids A ne dépend que d'une valeur alors que le poids B dépend aussi d'un paramètre qui change régulièrement.

    De nombreuses fois P, je veux pouvoir récupérer un élément dans la liste, celui qui a le plus grand poids B et en cas d'égalités, celui qui a le plus grand poids A.

    Une première solution (en python) serait :

    for _ in range(P):
        param = ...
        def k(e):
            return (getWeightB(e, param), getWeightA(e))
    
        item = max(l, key=k)

    Cependant cette solution réalise N * P appels à getWeightA et getWeightB. Les appels à getWeightA étant indépendants de param, on aimerait éviter de calculer ceux-là à chaque itération. D'autant que dans mon cas, il s'agit d'une fonction de complexité importante ;)

    Une seconde solution, mettant en cache la valeur de poids A serait la suivante :

    # calcul du cache
    l = [(k, getWeightA(k)) for k in l]
    
    # ...
    
    for _ in range(P):
        param = ...
        def k(e):
            return (getWeightB(e[0], param), e[1])
    
        item = max(l, key=k)[0]

    Cette solution a l'avantage de ne faire que N appels à getWeightA qu'une fois lors de l'initialisation, puis N * P appels à getWeightB. Elle est donc potentiellement plus efficace, mais consomme plus de mémoire.

    Je vous propose une dernière solution, qui permettra de lancer le débat et l'observation qui font l’intérêt de ce journal :

    # transformation de la liste (*)
    l = list(sorted(l, key=getWeightA, reverse=True))
    
    # ...
    
    for _ in range(P):
        param = ...
    
        def k(e):
            return getWeightB(e, param)
    
        # récuperation du max (**)
        item = max(l, key=k)

    Cette solution utilise deux astuces. En premier lieu (*)nous trions en sens inverse la liste initiale selon le poids A. Grâce à la Schwartzian transform utilisée par python dans la fonction sorted, ce tri est réalisé en O(N log N) avec seulement N appels à getWeightA. Cette fonction prend un peu de mémoire pour son initialisation, mais cette mémoire sera libérée avant la boucle.

    La seconde astuce (**) apparaît plus loin, où on cherche le maximum selon le poids B. Cette recherche du maximum prend en compte le poids A de façon simple, en renvoyant le premier maximum selon le poids B. Comme la liste est déjà triée inversement selon le poids A, ce premier maximum selon B est aussi le maximum selon A pour toutes les valeurs équivalentes de B.

    On obtient donc un algorithme à la complexité équivalente au précédant, mais consommant moins de mémoire, si on omet l'initialisation en O(N log N), on suppose que P > log N.

    J'ai souvent utilisé cette astuce dans ma vie de développeur, et hier soir, j'ai utilisé de nouveau cette astuce et je me suis planté.

    Pourquoi ? À cause de la supposition que la fonction max renvoie le premier maximum. Ce n'est pas (toujours) documenté / normalisé, donc c'est susceptible de changer, d’être aléatoire ou incohérent entre différent langages / librairies. C'est ce que nous allons observer.

    Observation

    En python (CPython 3.5.2) :

    >>> l = [("hello", 10), ("this", 10), ("is", 10), ("the", 10), ("end", 10), ("of", 10), ("the", 10), ("world", 10)]
    >>> key = lambda x : x[1]
    >>> min(l, key=key)
    ('hello', 10)
    >>> max(l, key=key)
    ('hello', 10)

    Ici les fonctions min et max renvoient le minimum de la liste l, en utilisant le second élément de chaque tuple. Toutes ces clés sont identiques, donc le résultat est arbitraire. Ici l’implémentation renvoie le premier de la liste dans les deux cas. Des essais d’implémentation Ruby et C++ donnent le même comportement.

    Comparons maintenant avec Haskell (GHC 8.0.1) :

    >>> import Data.List
    >>> import Data.Ord
    
    >>> l = [("hello", 10), ("this", 10), ("is", 10), ("the", 10), ("end", 10), ("of", 10), ("the", 10), ("world", 10)]
    >>> key = comparing snd
    >>> minimumBy key l
    ("hello",10)
    >>>> maximumBy key l
    ("world",10)

    Ici on observe quelque chose de différent, parmi toutes les valeurs possibles, le minimum est la première et le maximum est la dernière.

    Donc l'astuce discutée plus haut n'est pas valable (directement) en Haskell, ce qui m'a valu hier quelques heures de debug.

    Documentation

    Que disent les documentations pour l'usage de max(a, b) si a == b ?

    • C++ confirme que cela renvoie a
    • Haskell L'horreur à trouver, mais confirme que cela renvoie b
    • Python ne dit rien (l'implémentation dit a)
    • Rust confirme que cela renvoie b
    • Ruby ne dit rien (l'implémentation dit a)

    On vois donc que certains langages font des choix différents.

    Discussion

    Alors des deux comportements, lequel est le meilleur ?

    En toute logique, si on prend le premier élément d'une liste triée, c'est censé être la même chose que le minimum de la liste (et réciproquement pour le maximum). C'est comme cela qu'est implémenté le Tri par sélection.

    Haskell, Rust, confirment cela :

    >>> minimumBy key l == head (sortBy key l)
    True
    >>> maximumBy key l == last (sortBy key l)
    True

    Cependant Python, C++, Ruby, se "trompent" :

    >>> min(l, key=key) == list(sorted(l, key=key))[0]
    True
    >>> max(l, key=key) == list(sorted(l, key=key))[-1]
    False

    Conclusion

    Les langages de programmation ont une sémantique différente en ce qui concerne le tri et le comportement de la fonction max.

    Personnellement je préfère la sémantique implémentée entre autres dans Haskell puisque c'est la seule qui garantit que certaines lois fondamentales sont conservées.

    Au final ce n'est pas forcement grave, mais il ne faut pas écrire d'algorithme supposant une sémantique ou une autre et il faut documenter son code quand on fait ce genre de supposition. C'est ce que je n'avais pas fait, et je me suis fait avoir.

    Et vous, vous feriez vous avoir ? Comment votre outil gère-t-il ce cas ?

    Lire les commentaires

  • Le Google Code In 2016 est lancé (Journaux LinuxFR)

    Bonjour,

    Le Google Code-In 2016 a démarré hier soir.

    Il s'agit d'un concours organisé par Google pour les 13-17 ans, le but étant de leur faire découvrir l'informatique et le logiciel libre. Les participants doivent compléter des tâches proposées par plusieurs projets libres (17 projets cette année). Les gagnants (2 par projet) participeront à un voyage à San Francisco avec visite des locaux de Google et diverses conférences.

    ça se passe par ici:
    https://codein.withgoogle.com

    Lire les commentaires

  • Revue de presse de l'April pour la semaine 47 de l'année 2016 (Dépêches LinuxFR)

    La revue de presse de l'April est régulièrement éditée par les membres de l'association. Elle couvre l'actualité de la presse en ligne, liée au logiciel libre. Il s'agit donc d'une sélection d'articles de presse et non de prises de position de l'association de promotion et de défense du logiciel libre.

    Sommaire

    [ZDNet France] Logiciel libre et l’Education nationale: la route est longue mais la coupe est pleine?

    Par Louis Adam, le vendredi 25 novembre 2016. Extrait:

    Sur son blog, l’association Framasoft a publié un long texte faisant état d’un changement de stratégie à l’égard de l’Education nationale. Face au manque de considération du ministère à l’égard du logiciel libre, Framasoft annonce son intention de prendre ses distances.

    Lien vers l'article original: http://www.zdnet.fr/actualites/logiciel-libre-et-l-education-nationale-la-route-est-longue-mais-la-coupe-est-pleine-39845214.htm

    Et aussi:

    [Next INpact] Hadopi: comment Juppé et Fillon cèdent aux ayants droit

    Par Marc Rees, le mercredi 23 novembre 2016. Extrait:

    L’échéance de la présidentielle est systématiquement un pont d’or pour les différents lobbys, tous secteurs confondus. Dans le domaine des industries culturelles, la règle est confirmée au regard des programmes portés par les deux candidats de la primaire de droite, spécialement sur le front de la Hadopi.

    Lien vers l'article original: http://www.nextinpact.com/news/102236-hadopi-comment-juppe-et-fillon-cedent-aux-ayants-droit.htm

    [Developpez.com] Des programmeurs avouent avoir écrit du code non éthique et parfois illégal

    Par Coriolan, le mardi 22 novembre 2016. Extrait:

    Avec la multiplication des scandales qui impliquent des programmeurs qui ont agi sans éthique de travail ou hors du champ de la loi, beaucoup commencent à se demander ce qu’il faudrait faire pour changer la donne. Que devraient faire les programmeurs quand on leur demande d’accomplir des tâches non éthiques ou illégales? Qu’est ce qu’il faudrait faire pour protéger le programmeur dans ces cas? Et faudrait-il prévoir des formations d’éthique pour éviter des agissements contraires à la loi dans le futur? Bref, une panoplie de questions qui hantent les programmeurs de tous les coins du globe.

    Lien vers l'article original: http://www.developpez.com/actu/106861/Des-programmeurs-avouent-avoir-ecrit-du-code-non-ethique-et-parfois-illegal-en-raison-des-requetes-de-plus-en-plus-contraignantes-de-leurs-employeurs

    [Les Echos] 1.000 nouveaux emplois dans le secteur de l’Open Source en 2017

    Par Julia Lemarchand, le lundi 21 novembre 2016. Extrait:

    Les entreprises du logiciel libre et de l’open source se portent très bien. Au point de prévoir une croissance de 25% de leurs effectifs en France pour l’an prochain.

    Lien vers l'article original: http://start.lesechos.fr/rejoindre-une-entreprise/actu-recrutement/1-000-nouveaux-emplois-dans-le-secteur-de-l-open-source-en-2017-6564.php

    Et aussi:

    [Le Temps] La lutte contre l’obsolescence programmée s’organise

    Par Andrée-Marie Dussault, le lundi 21 novembre 2016. Extrait:

    Les stratégies pour combattre le fléau qui menace l’environnement et nos portefeuilles se multiplient. Qualité, réparabilité et compatibilité réémergent à l’ordre du jour

    Lien vers l'article original: https://www.letemps.ch/sciences/2016/11/21/lutte-contre-lobsolescence-programmee-sorganise

    Lire les commentaires

  • Devuan a deux ans (Journaux LinuxFR)

    Bonsoir journal,

    Aujourd'hui, cela fait deux ans et un jour que le célèbre fork de la distribution Debian par des ADMINS UNIX VETERANS a été annoncé avec fracas suite au refus de voir le célèbre init systemd inclu de base dans Debian, après un débat et une votation.
    La distribution Devuan Jessie 1.0 semble toujours en Beta comme indiqué sur le site.
    Utilisez vous cette distribution ? si oui, en êtes vous satisisfait. L'avez vous deployé en production sans trop de difficulté, est ce que le suivi des corrections et de sécurité est à la hauteur de Debian

    Lire les commentaires

  • "Libre, chiche !" un communiqué du Synpell et de Minga (Journaux LinuxFR)

    Communiqué commun du Syndicat Professionnel des Éditeurs de Logiciels Libres et de l'association Minga sur l'urgence d'organiser les professionnels du libre en syndicat professionnel :

    Même si nous ne sommes pas tous des informaticiens, mais des usagers des technologies numériques pas toujours bien cohérents entre les idées que nous défendons et les moyens technologiques que nous utilisons, nous partageons la conviction de Richard Stallman (initiateur du mouvement des logiciels libres) quand il rappelle que toutes les libertés sont interdépendantes, y compris la liberté informatique.

    Comme la communauté des logiciels libres, nous prenons très au sérieux cette exigence de liberté, d’intégrité professionnelle, et nous en assumons les risques.

    Face à la montée en puissance d’un modèle économique et politique anti-démocratique (ex: État d'urgence vs État de droit, collusions médias/grands groupes, concentration des données et des contenus sur la toile et dans l'économie, etc.) qui a l’ambition de gouverner nos choix (en terme de services mais aussi d’objets manufacturés, par des algorithmes), nous souhaitons échanger entre libristes pour partager nos problématiques pratiques dans l'optique que chacun et tous montent en compétences.

    Ambitieusement démocrates, par la diversité de nos métiers, nous aspirons à être mieux armés, plus audacieux et davantage en lien entre éditeurs de logiciels libres pour assurer ensemble une meilleure maîtrise de nos métiers respectifs.

    Rencontrons-nous !

    Minga & le Synpell (Syndicat Professionnel des Éditeurs de Logiciels Libres)

    Lire les commentaires

  • De la confiance dans le monde OpenPGP (Journaux LinuxFR)

    Sommaire

    Introduction

    La confiance est l’un des concepts à la fois les plus importants et les plus mal compris d’OpenPGP. Derrière ce terme peuvent se cacher en réalité deux notions bien distinctes, illustrées par les propositions suivantes :

    • Alice est confiante que la clef 0xB4902A74 appartient à Bob ;
    • Alice fait confiance à Bob quand celui-ci lui dit que la clef 0x4B493BB7 appartient à Charlie.

    La première proposition fait référence à la validité de la clef 0xB4902A74, tandis que la seconde fait référence à la confiance proprement dite qu’Alice accorde à Bob.

    Note

    Malheureusement, les auteurs et développeurs anglophones utilisent souvent le mot trust pour parler de la validité, et d’ownertrust pour parler de la confiance proprement dite, ce qui contribue probablement à la confusion entourant ces deux notions.

    Dans cet article, nous verrons ce que recouvrent précisément ces deux notions, comment elles interagissent, et comment les manipuler avec GnuPG.

    Rappelons au préalable qu’une clef publique OpenPGP est, au minimum, l’association d’une clef brute1 et d’une ou plusieurs identités (User ID) représentant le propriétaire de la clef (c’est-à-dire, celui qui possède ou contrôle la clef privée correspondante).

    La validité

    On peut distinguer deux sortes de “validité” : la validite d’une clef et la validité d’une identité.

    La validité d’une clef

    Une clef OpenPGP peut être

    • révoquée, si son propriétaire (ou un révocateur désigné mandaté par lui) a publié un certificat de révocation ;
    • expirée, si la période de validité annoncée dans l’auto-signature la plus récente de la clef est dépassée.

    Dans les deux cas, la clef dans son ensemble est invalide. Cette invalidité est absolue : elle est intrinsèque à la clef et ne dépend d’aucun autre facteur (notamment, elle ne dépend pas de ce que peut penser un utilisateur donné).

    Si la clef n’est ni révoquée ni expirée, alors sa validité est celle de la plus valide de ses identités.

    La validité d’une identité

    La validité d’une identité d’une clef est une mesure de la certitude que l’on a que cette identité et cette clef sont bien associées, ou en d’autres termes, que la clef appartient bien au propriétaire désigné par l’identité.

    Elle peut prendre plusieurs valeurs discrètes :

    • Invalide : Je suis sûr que la clef n’*appartient *pas à son propriétaire proclamé.
    • Inconnue : Je n’ai aucune certitude quant à l’appartenance de la clef.
    • Marginalement valide : J’ai des raisons de penser que la clef appartient bien à qui elle prétend sans pour autant en être sûr.
    • Pleinement valide : Je suis sûr que la clef appartient bien à son propriétaire proclamé.

    Une identité n’est jamais valide ou invalide en elle-même : sa validité s’évalue toujours relativement à un utilisateur donné. Une même identité peut être pleinement valide pour une personne et à validité inconnue pour une autre, si ces deux personnes ont des certitudes différentes quant à l’appartenance de la clef.

    Une identité peut aussi être révoquée par le propriétaire de la clef. Dans ce cas, l’identité est inconditionnellement invalide.

    Note

    Il ne faut pas confondre la révocation d’une clef avec la révocation d’une identité : une clef révoquée est complètement inutilisable, tandis qu’une clef dont une des identités est révoquée reste utilisable tant qu’au moins une autre de ses identités n’est pas invalide.

    À quoi sert la validité ?

    La validité répond à deux questions différentes selon que l’on veuille chiffrer un message ou vérifer une signature.

    Lorsqu’on veut chiffrer un message, la validité définit si la clef du destinataire est utilisable, selon les règles suivantes :

    • une clef expirée ou révoquée est inconditionnellement inutilisable2 ;
    • il est similairement impossible de chiffrer un message à destination d’une identité révoquée ou invalide ;
    • une confirmation sera demandée avant de pouvoir chiffrer un message à destination d’une identité dont la validité est inconnue ;
    • un avertissement sera affiché lors du chiffrement d’un message à destination d’une identité qui n’est que marginalement valide ;
    • seule une identité pleinement valide associée à une clef non-expirée et non-révoquée est utilisable sans condition ni avertissement.

    Lorsqu’on veut vérifier une signature, la validité de la clef signante définit le crédit que l’on peut accorder à la signature :

    • si la clef est expirée, la signature n’est valable que si elle est antérieure à la date d’expiration ;
    • si la clef est révoquée parce qu’elle a été compromise, ou sans qu’une raison explicite ne soit donnée, la signature n’est pas valable ;
    • si la clef est révoquée mais que le certificat de révocation précise explicitement que la clef a été remplacée ou simplement retirée du service (c’est-à-dire, rien qui laisse supposer que la clef a été compromise), la signature est valable si elle est antérieure à la révocation ;
    • si la clef ne contient aucune identité pleinement valide, la signature reste valable, mais un message rappellera qu’il existe une incertitude sur le propriétaire de la clef et donc sur le signataire du message.

    Afficher la validité

    La commande --list-keys de GnuPG permet d’afficher la validité des identités d’une clef :

    alice$ gpg --list-keys bob
    pub   rsa2048 2015-06-05 [SC]
          F336DF59EADFF278C40DBD7A21321A16B4902A74
    uid           [  full  ] Robert <bob@example.com>
    uid           [ unknown] Bob du 92 <bob92@provider.example>
    sub   rsa2048 2015-06-05 [E]
    

    Cette clef a deux identités associées : une pleinement valide (full), l’autre à validité inconnue (unknown).

    Note

    Les versions de GnuPG antérieures à la 2.1 n’affichent pas, par défaut, la validité. Il faut ajouter l’option --list-options show-uid-validity sur la ligne de commande ou dans le fichier de configuration de GnuPG.

    La validité est également affichée dans l’éditeur de clef :

    alice$ gpg --edit-key bob
    pub  rsa2048/21321A16B4902A74
         created: 2015-06-05  expires: never       usage: SC
         trust: marginal      validity: full
    sub  rsa2048/E32EF7E899E238AD
         created: 2015-06-05  expires: never       usage: E
    [  full  ] (1). Robert <bob@example.com>
    [ unknown] (2)  Bob du 92 <bob92@provider.example>
    

    En plus de la validité de chaque identité, l’éditeur de clef affiche aussi la validité de la clef dans son ensemble. Ici, la clef est complètement valide (validity: full), puisqu’elle n’est ni révoquée, ni expirée, et que l’une des deux identités associées est complètement valide.

    Il n’y a pas de commande ou d’option pour modifier la validité. En effet — et c’est là le point central de cet article —, la validité d’une identité n’est pas décidée manuellement par l’utilisateur, mais déterminée automatiquement3 via un modèle de confiance.

    Les modèles de confiance

    Un modèle de confiance est un ensemble de règles permettant de déterminer la validité d’une identité. Formellement, on peut l’assimiler à une fonction associant à chaque identité, une valeur de validité parmi celles listées plus haut (inconnue, marginale, complète, ou invalide).

    Une caractéristique distinctive d’OpenPGP, par rapport notamment à X.509/SMIME, est l’absence de modèle de confiance imposé ou même seulement défini par le standard. Ce n’est pas un oubli de la part des auteurs, mais bien au contraire une volonté affichée d’être le plus “générique” et de laisser les implémenteurs libres de développer les modèles de confiance de leur choix.4

    Les modèles de confiance proposés par GnuPG (sélectionnables via l’option --trust-model) sont les suivants :

    • la confiance systématique (--trust-model always) ;
    • la confiance directe (--trust-model direct) ;
    • la toile de confiance, en version “simple” (--trust-model classic) et en version “étendue”5 (--trust-model pgp) ;
    • le modèle Trust On First Use,6 utilisé seul (--trust-model tofu) ou conjointement avec la toile de confiance (--trust-model tofu+pgp).

    Le choix du modèle de confiance est une décision locale : chaque utilisateur peut utiliser le modèle qu’il préfère, sans incidence sur l’interopérabilité (deux personnes utilisant des modèles de confiance différents peuvent toujours communiquer).

    Je ne m’étendrai pas sur les deux premiers modèles, qui sont les plus simples à comprendre mais qui sont aussi les moins utiles, sauf dans certaines conditions particulières.

    Dans le modèle de “confiance systématique”, toutes les clefs sont toujours considérées pleinement valides.7 Ce modèle est de fait à éviter absolument dans le cas général des communications à travers l’Internet, où les fausses clefs ne sont pas rares. Il peut toutefois avoir un intérêt dans un environnement strictement contrôlé, dans lequel on peut être sûr qu’il ne circule que des clefs authentiques (mais a-t-on vraiment besoin d’OpenPGP dans un tel environnement ?).

    À l’opposé, le modèle de “confiance directe” confie à l’utilisateur le soin de décider lui-même, directement, de la validité de chaque clef. C’est donc, par définition, une exception au principe énoncé plus haut selon lequel la validité est calculée automatiquement par le modèle de confiance et non assignée manuellement par l’utilisateur.

    Note

    Ce modèle peut sembler attrayant, en particulier pour ceux que la complexité de la toile de confiance effraie. Néanmoins, les modèles plus récents de type TOFU, décrits plus loin, sont une meilleure alternative.

    Par défaut, GnuPG utilise le modèle pgp, la toile de confiance étendue.

    La toile de confiance

    C’est le modèle de confiance traditionnellement associé à OpenPGP, au point d’en ignorer souvent que ce n’est qu’un des modèles possibles.

    Il est, hélas, assez souvent mal compris et donc trop souvent mal utilisé.

    La bonne compréhension de ce modèle nécessite d’introduire deux notions supplémentaires, qui étaient inutiles jusqu’à présent.

    Notion de certification

    Une certification est une signature sur le couple {clef brute, identité} (on parlera, très souvent, de signature de clef), par laquelle le signataire atteste (“certifie”) que cette clef brute et cette identité sont associées.

    Formellement, l’ensemble formé d’une clef brute, d’une identité, et d’au moins une certification constitue un certificat OpenPGP. Ce terme est néanmoins rarement employé, l’usage ayant consacré l’expression clef publique OpenPGP à la place (entraînant hélas un risque de confusion avec le concept mathématique de clef publique, que je désigne dans ce document par clef brute justement pour éviter toute ambiguïté.).

    Attributs de certification

    Une certification peut être qualifiée par plusieurs attributs, dont certains peuvent affecter l’interprétation qui doit être faite de cette certification.

    Une certification est toujours qualifiée par un niveau (certification level) qui traduit la rigueur avec laquelle le signataire a vérifié l’identité du propriétaire de la clef. Le niveau 0 (certification “générique”) correspond à une absence d’engagement : en certifiant à ce niveau, le signataire ne donne délibérément aucune information. Le niveau 1 correspond en principe à une absence de vérification : en certifiant à ce niveau, le signataire annonce qu’il n’a pas particulièrement vérifié l’identité du propriétaire. En certifiant au niveau 2 ou au niveau 3, le signataire annonce qu’il a procédé à des vérifications plus rigoureuses.

    Note

    Malheureusement, le standard OpenPGP ne définit pas précisément ce que peuvent être les vérifications pour chaque niveau. Chaque utilisateur peut ainsi donner à chaque niveau la signification de son choix, ce qui en pratique fait perdre beaucoup d’intérêt à la notion même de niveau de certification puisque deux utilisateurs peuvent avoir une opinion différente de ce qu’est une certification “rigoureuse”.

    À titre d’exemple, je définis la limite entre les certifications de niveau 2 et 3 comme suit : si j’ai rencontré le propriétaire de la clef en personne, je certifie au niveau 2 ; s’il m’a en plus présenté une pièce d’identité officielle, je certifie au niveau 3. Mais ce n’est que ma politique : une certification de niveau 3 émise par un autre utilisateur peut avoir une signification différente.

    En pratique, la plupart des certifications sont de niveau 0. C’est le niveau de certification par défaut avec GnuPG. Compte tenu de l’absence de signification universellement reconnue des différents niveaux de confiance, il est tout-à-fait raisonnable de s’en tenir à ce niveau 0 et d’ignorer jusqu’à l’existence même des niveaux supérieurs.

    Le signataire peut ajouter à sa certification une URL pointant vers un document supposé expliquer sa politique de signature (il peut notamment décrire la signification qu’il donne aux différents niveaux de certification). Cet attribut est purement informatif et à destination de l’utilisateur : GnuPG n’en fait aucun usage lui-même.

    Une certification peut être marquée comme locale. Une telle certification n’est valable que dans le trousseau de celui qui l’a émise et sera automatiquement omise lorsque la clef sera exportée.

    Enfin, une certification peut être marquée comme irrévocable. Normalement, toute certification peut être annulée (révoquée) a posteriori par son émetteur, simplement en publiant une signature de révocation (qui concrètement prend la même forme qu’une certification, c’est-à-dire une signature sur le couple {clef brute, identité}, mais signifie que toute certification antérieure sur le même couple, émise par la même clef, doit être considérée comme nulle). Si la certification initiale est marquée irrévocable, alors toute signature de révocation ultérieure sera ignorée.

    Notion d’auto-certification

    Chaque identité porte toujours au moins une auto-certification, c’est-à-dire une certification émise par la propre clef brute à laquelle l’identité est associée.

    Si elle est sans valeur, comme on le verra, lors du calcul de la validité, elle permet surtout au propriétaire de la clef d’exprimer certaines préférences par l’intermédiaire d’attributs spécifiques aux auto-certifications :

    • la durée de validité de la clef ;
    • un éventuel révocateur désigné, sous la forme de l’empreinte d’une clef tierce habilitée à émettre des certificats de révocation pour cette clef ;
    • les algorithmes de chiffrement, de condensation et de compression utilisables pour communiquer avec le propriétaire de cette clef, par ordre de préférence.

    Une fois émise, une (auto-)certification n’est pas modifiable. Pour changer l’un des attributs ci-dessus (par exemple pour repousser la date d’expiration de la clef, ou pour mettre à jour les algorithmes préférés), il faut émettre une nouvelle auto-certification, qui dans les faits annulera toute auto-certification antérieure. Seule l’auto-certification la plus récente est prise en compte quand il y en a plusieurs.

    Notion de confiance

    La confiance proprement dite (ownertrust) est une valeur associée par l’utilisateur à une clef publique qui définit le crédit à accorder aux certifications émises par cette clef.

    Comme pour la validité définie plus haut, la confiance peut prendre plusieurs valeurs discrètes :

    • aucune confiance : Ne jamais accorder aucun crédit aux certifications émises par cette clef.
    • confiance inconnue ou indéterminée : Ignorer les certifications émises par cette clef.
    • confiance marginale : Tenir compte des certifications seulement dans une certaine mesure (voir plus loin).
    • confiance complète : Accorder toute leur valeur aux certifications.
    • Confiance ultime : Valeur spéciale normalement réservée aux clefs “locales”, c’est-à-dire les clefs dont la partie privée est disponible.

    Dans le modèle de la toile de confiance simple, la confiance est toujours explicitement assignée par l’utilisateur. Chaque clef ajoutée au trousseau se voit assignée par défaut une confiance inconnue, et ce jusqu’à ce que l’utilisateur décide de la changer explicitement.

    L’assignation de la confiance se fait via la commande trust de l’éditeur de clefs de GnuPG.

    Dans l’exemple que nous avons vu plus haut, la clef de Bob, telle qu’elle figure dans le trousseau d’Alice, a une confiance marginale (trust: marginal).

    Règles de la toile de confiance

    On peut maintenant poser le principe de fonctionnement de la toile de confiance, telle qu’elle est implémentée par GnuPG.

    Pour déterminer la validité d’une identité, on commence par retirer toutes les certifications inexploitables portées par cette identité. Précisément, on retire les certifications :

    • émises par des clefs inconnues, c’est-à-dire qui ne figurent pas dans le trousseau local ;
    • émises par des clefs invalides ou à validité inconnue (ce qui élimine entre autres l’auto-certification émise par la clef même que l’on cherche à valider) ;
    • émises par des clefs révoquées ;
    • dont le niveau de certification est supérieur à zéro mais inférieur au paramètre --min-cert-level (qui vaut 2 par défaut, ce qui signifie que les certifications de niveau 1 sont ignorées) ;
    • révoquées par leur signataire, sauf si la certification initiale était marquée non-révocable.

    Pour chaque certification restante, on regarde ensuite la confiance assignée à la clef émettrice. S’il y a…

    • au moins 1 certification émise par une clef à confiance ultime, l’identité est complètement valide ;
    • au moins n certifications émises par des clefs à confiance complète (avec n = 1 par défaut, modifiable avec l’option --completes-needed), l’identité est complètement valide ;
    • au moins m certifications émises par des clefs à confiance marginale (avec m = 3 par défaut, modifiable avec l’option --marginals-needed), l’identité est complètement valide ;
    • entre 1 et n − 1 certification(s) émise(s) par des clefs à confiance complète, ou entre 1 et m − 1 certification(s) émises par des clefs à confiance marginale, l’identité est marginalement valide ;
    • aucune certification émise par une clef à confiance au moins marginale, l’identité est à validité inconnue.

    Un exemple

    Considérons un instant la clef d’Alice :

    alice$ gpg --list-keys alice
    pub   rsa4096 2015-06-05 [SC] [expires: 2018-06-04]
          318D1F0158F237EB64797C0C5C5CE0D82EADF7D4
    uid           [ultimate] Alice <alice@example.org>
    

    S’agissant d’une clef dont la partie privée est disponible (puisque nous sommes sur le système d’Alice), elle est intrinsèquement ultimement valide et de confiance.

    Note

    Dans toutes les captures d’écrans qui suivent, pour gagner à la fois en place et en clarté, les sous-clefs seront systématiquement omises.

    Maintenant, imaginons qu’Alice vient juste d’obtenir la clef publique de Bob. Elle l’importe dans son trousseau et y jette un œil :

    alice$ gpg --import bob.asc
    gpg: key 21321A16B4902A74: public key "Robert <bob@example.com>" imported
    gpg: Total number processed: 1
    gpg:               imported: 1
    alice$ gpg --list-keys --with-sig-check bob
    gpg: 2 good signatures
    pub   rsa2048 2015-06-05 [SC]
          F336DF59EADFF278C40DBD7A21321A16B4902A74
    uid           [ unknown] Robert <bob@example.com>
    sig!3        21321A16B4902A74 2015-06-05  Robert <bob@example.com>
    uid           [ unknown] Bob du 92 <bob92@provider.example>
    sig!3        21321A16B4902A74 2015-10-07  Robert <bob@example.com>
    

    Cette clef a deux identités (Robert <bob@example.com> et Bob du 92 <bob92@provider.example>), chacune porteuse d’une auto-certification (émise par la clef 0xB4902A74, c’est-à-dire cette clef). En l’absence d’autres certifications, ces deux identités sont de validité inconnue.

    Imaginons à présent qu’Alice est personnellement certaine qu’il s’agit bien de la clef de Bob (par exemple, Bob lui a confirmé l’empreinte de vive voix). Elle va donc certifier (signer) sa clef :

    alice$ gpg --edit-key bob
    pub  rsa2048/21321A16B4902A74
         created: 2015-06-05  expires: never       usage: SC  
         trust: unknown       validity: unknown
    [ unknown] (1). Robert <bob@example.com>
    [ unknown] (2). Bob du 92 <bob92@provider.example>
    

    Alice sélectionne la première identité, correspondant à la seule adresse de Bob dont elle soit sûre, puis la certifie :

    gpg> 1
    pub  rsa2048/21321A16B4902A74
         created: 2015-06-05  expires: never       usage: SC  
         trust: unknown       validity: unknown
    [ unknown] (1)* Robert <bob@example.com>
    [ unknown] (2)  Bob du 92 <bob92@provider.example>
    
    gpg> sign
    
    pub  rsa2048/21321A16B4902A74
         created: 2015-06-05  expires: never       usage: SC  
         trust: unknown       validity: unknown
     Primary key fingerprint: F336 DF59 EADF F278 C40D  BD7A 2132 1A16 B490 2A74
    
         Robert <bob@example.com>
    
    Are you sure that you want to sign this key with your
    key "Alice <alice@example.org>" (5C5CE0D82EADF7D4)
    
    Really sign? (y/N) y
    
    gpg> save
    

    Note

    Ici, en utilisant la commande sign, Alice a opté pour une signature « normale », sans fioritures : niveau de certification 0, exportable, révocable.

    Jetons à présent à nouveau un œil comme précédemment sur la clef de Bob :

    alice$ gpg --list-keys --with-sig-check bob
    gpg: 3 good signatures
    pub   rsa2048 2015-06-05 [SC]
          F336DF59EADFF278C40DBD7A21321A16B4902A74
    uid           [  full  ] Robert <bob@example.com>
    sig!3        21321A16B4902A74 2015-06-05  Robert <bob@example.com>
    sig!         5C5CE0D82EADF7D4 2016-11-26  Alice <alice@example.org>
    uid           [ unknown] Bob du 92 <bob92@provider.example>
    sig!3        21321A16B4902A74 2015-10-07  Robert <bob@example.com>
    

    Si rien n’a changé pour l’identité « Bob du 92 » (qui n’a toujours que sa seule auto-certification et est donc toujours de validité inconnue), l’identité de « Robert », elle, porte désormais la certification d’Alice. La clef d’Alice étant de confiance ultime, cette identité est donc pleinement valide, en application des règles de la toile de confiance vues précédemment.

    Remarquez qu’Alice n’a jamais directement modifié la validité de la clef de Bob. Je me permets d’insister parce que c’est la notion centrale de cet article : la validité est toujours calculée automatiquement par GnuPG, jamais directement assignée par l’utilisateur. C’est en jouant sur la confiance que l’on affecte la validité, selon des modalités qui varient selon le modèle de confiance utilisé.

    Poursuivons l’exemple. Alice obtient à présent la clef de Charlie. Comme précédemment, elle l’importe et l’examine :

    alice$ gpg --import charlie.asc
    gpg: key 3800CBA74B493BB7: public key "Charlie <charlie@example.net>" imported
    gpg: Total number processed: 1
    gpg:               imported: 1
    alice$ gpg --list-keys --with-sig-check charlie
    gpg: 2 good signatures
    pub   rsa2048 2015-06-05 [SC]
          3172310F9C0C11AEA1B057433800CBA74B493BB7
    uid           [ unknown] Charlie <charlie@example.net>
    sig!3        3800CBA74B493BB7 2015-06-05  Charlie <charlie@example.net>
    sig!         21321A16B4902A74 2016-11-26  Robert <bob@example.com>
    

    La clef de Charlie n’a qu’une identité, laquelle porte deux certifications : l’auto-certification de rigueur, et une certification émise par Bob. Pourquoi cette identité est-elle considérée « de validité inconnue » ?

    Parce que Alice n’a jamais assigné de valeur de confiance à la clef de Bob ! GnuPG lui a donc attribué, par défaut, une confiance inconnue, qui dans le modèle de la toile de confiance ne confère aucun crédit aux certifications émises par cette clef. Allons éditer la clef de Bob pour changer ça :

    alice$ gpg --edit-key bob
    pub  rsa2048/21321A16B4902A74
         created: 2015-06-05  expires: never       usage: SC  
         trust: unknown       validity: full
    sub  rsa2048/E32EF7E899E238AD
         created: 2015-06-05  expires: never       usage: E   
    [  full  ] (1). Robert <bob@example.com>
    [ unknown] (2)  Bob du 92 <bob92@provider.example>
    
    gpg> trust
    
    Please decide how far you trust this user to correctly verify other users' keys
    (by looking at passports, checking fingerprints from different sources, etc.)
    
      1 = I don't know or won't say
      2 = I do NOT trust
      3 = I trust marginally
      4 = I trust fully
      5 = I trust ultimately
      m = back to the main menu
    
    Your decision? 3
    
    pub  rsa2048/21321A16B4902A74
         created: 2015-06-05  expires: never       usage: SC  
         trust: marginal      validity: full
    sub  rsa2048/E32EF7E899E238AD
         created: 2015-06-05  expires: never       usage: E   
    [  full  ] (1). Robert <bob@example.com>
    [ unknown] (1)  Bob du 92 <bob92@provider.example>
    Please note that the shown key validity is not necessarily correct
    unless you restart the program.
    
    gpg> quit
    

    Alice a donc assigné une confiance marginale à la clef de Bob. Voyons ce que cela change sur la validité de la clef de Charlie :

    alice$ gpg --list-keys --with-sig-check charlie
    gpg: 2 good signatures
    pub   rsa2048 2015-06-05 [SC]
          3172310F9C0C11AEA1B057433800CBA74B493BB7
    uid           [marginal] Charlie <charlie@example.net>
    sig!3        3800CBA74B493BB7 2015-06-05  Charlie <charlie@example.net>
    sig!         21321A16B4902A74 2016-11-26  Robert <bob@example.com>
    

    Avec une certification émise par une clef à confiance marginale, et avec les paramètres par défaut de la toile de confiance, la clef de Charlie est désormais marginalement valide.

    Chaîne de certification et profondeur

    Le dernier exemple permet d’illustrer le concept de chaîne de certification, dont nous avons besoin pour expliquer une dernière règle du modèle de la toile de confiance, celle de la profondeur maximale de la chaîne de certification.

    Dans cet exemple, Alice a certifié la clef de Bob, qui a lui-même certifié la clef de Charlie. Cette dernière se trouve ainsi à l’extrémité d’une chaîne remontant jusqu’à la clef d’Alice par l’intermédiaire de celle de Bob.

    Comme nous regardons tout ceci depuis le point de vue d’Alice, sa clef est le point de départ de la chaîne. Elle est associée à une profondeur nulle. La clef de Bob, directement certifiée Alice, a une profondeur de 1 ; celle de Charlie, certifiée par Bob, a une profondeur de 2. Si Charlie certifiait la clef de David (et en supposant qu’Alice attribue une confiance explicite à la clef de Charlie, ce qu’elle n’a pas encore fait dans notre exemple), celle-ci aurait une profondeur de 3, et ainsi de suite.

    La règle de la profondeur maximale dit simplement que la profondeur associée à une clef ne peut pas dépasser 5 (valeur par défaut, modifiable par l’option --max-cert-depth), ou autrement dit, qu’une chaîne de certification ne peut pas compter plus de 6 maillons.

    Ainsi, si David certifiait la clef de Fanny qui elle-même certifiait la clef de Gordon qui lui-même certifiait la clef de Helen, cette dernière serait quoi qu’il arrive trop éloignée de la clef d’Alice (profondeur de 6) pour être considérée valide, même si Alice faisait explicitement confiance à David, Fanny et Gordon.

    Note

    Dans les faits, il est extrêmement rare qu’une clef ne soit pas validée à cause de cette profondeur maximale. Les chaînes de certifications s’arrêtent généralement avant de heurter cette limite, par défaut de confiance explicite (plus on s’éloigne d’Alice, moins il y a de chance qu’elle connaisse suffisamment bien les personnes impliquées pour pouvoir assigner un niveau de confiance à leurs clefs).

    La toile de confiance étendue

    Jusque là, ce que nous avons vu était la toile de confiance simple (si, si…). Voyons à présent ce que recouvre la toile de confiance étendue.

    La toile de confiance étendue fonctionne comme la toile de confiance simple, mais prend en compte un type particulier de certifications qu’on appelle les trust signatures.

    Note

    La toile de confiance étendue est le modèle de confiance par défaut de GnuPG. Toutefois, si vous n’utilisez pas (et n’avez jamais émis) de trust signatures, alors dans les faits vous n’utilisez que la toile de confiance simple… comme la quasi-totalité des utilisateurs de GnuPG.

    Notion de trust signature

    Une trust signature est semblable à une certification simple comme décrit plus haut (c’est-à-dire une signature sur un couple {clef brute, identité}), mais avec deux paramètres supplémentaires :

    • une profondeur n, indiquant que la clef portant cette trust signature est habilitée à émettre elle-même des trust signatures de profondeur n − 1 (une profondeur de zéro rend la trust signature strictement équivalente à une certification simple) ;
    • une valeur de confiance à assigner à la clef portant cette trust signature ; en principe cette valeur peut s’étendre de zéro à 255, mais en pratique il n’y a que deux possibilités : toute valeur inférieure à 120 est interprétée comme assignant une confiance marginale, et toute valeur supérieure ou égale à 120 est interprétée comme assignant une confiance complète.

    C’est dans ce second paramètre que réside la différence entre la toile de confiance simple et la toile de confiance étendue : les certifications de la toile de confiance simple ne servent qu’à déterminer la validité d’une identité, l’assignation de la confiance étant du seul ressort de l’utilisateur ; les trust signatures de la toile de confiance étendue déterminent à la fois la validité d’une identité et la confiance assignée à la clef associée.

    Impact des trust signatures

    Pour illustrer l’impact des trust signatures sur la toile de confiance, reprenons à nouveau l’exemple d’une chaîne de certification allant de Alice à David en passant par Bob et Charlie.

    Fig1

    En absence de trust signatures, du point de vue d’Alice seule la clef de Bob est valide (puisqu’elle est certifiée par une clef à confiance ultime, la sienne). Même si Bob a certifié la clef de Charlie, cette dernière restera à validité inconnue tant que Alice n’aura pas explicitement exprimé sa confiance envers Bob. (Il en va de même, a fortiori, pour la clef de David.)

    Notez que chez lui, Bob fait peut-être confiance à Charlie, auquel cas la clef de David serait valide à ses yeux. Mais c’est sans intérêt pour Alice, qui n’a de toute façon aucun moyen de savoir quelle confiance Bob accorde à Charlie. Bob est le seul à savoir ça (même Charlie l’ignore) : dans la toile de confiance simple, la confiance est toujours une valeur locale, jamais partagée avec les autres membres de la toile.

    Imaginons à présent que Alice a certifié la clef de Bob, non avec une certification simple, mais avec une trust signature de profondeur 2 et de confiance 120 : la clef de Bob est alors non seulement valide, mais se voit aussi automatiquement attribué une confiance complète. Si, de son côté, Bob a certifié la clef de Charlie avec une trust signature de profondeur 1 et de confiance 120, alors pour Alice, la clef de Charlie est valide et se voit aussi assigné automatiquement une confiance complète. Du coup, la clef de David, certifiée par Charlie, devient valide aux yeux d’Alice, même si elle ne s’est jamais prononcée elle-même sur la confiance à accorder à Charlie.

    Notez que si Alice avait certifié la clef de Bob avec une certification simple, ou avec une trust signature de profondeur 1, la trust signature de Bob sur la clef de Charlie aurait été ignorée, ou plus exactement, traitée comme une certification simple, et aucune confiance n’aurait été automatiquement assignée à la clef de Charlie.

    Cela signifie qu’il n’y a aucun risque d’utiliser la toile de confiance étendue par erreur. Même si tous les correspondants d’Alice émettaient des trust signatures à tout-va, celles-ci ne seront prises en compte par Alice que si elle décide elle-même d’entrer à son tour dans le jeu de la toile de confiance étendue, en émettant des trust signatures sur les clefs de ses correspondants. Si elle souhaite au contraire continuer à décider elle-même, seule, de la confiance à accorder à chacun, il lui suffit de ne jamais émettre que des certifications simples… ce que fait déjà GnuPG par défaut.

    Note

    En pratique, personne n’émet de trust signatures. Sérieusement. En plus de dix ans d’utilisation de GnuPG, je n’en ai jamais vu une seule dans la nature. C’est pourquoi, bien que la toile de confiance étendue soit le modèle de confiance par défaut de GnuPG, dans les faits tout le monde utilise la toile de confiance simple (où les trust signatures peuvent exister mais sont traitées comme des certifications simples : leur valeur de confiance est ignorée, et elles ne servent qu’à calculer la validité).

    Limitation du champ des trust signatures

    Outre la profondeur et la valeur de confiance, une trust signature peut se voir adjoindre un troisième paramètre : une expression rationnelle qui limite les identités pour lesquelles la clef portant cette trust signature est autorisée à émettre elle-même des trust signatures.

    Par exemple, imaginons que Alice certifie la clef de Bob avec une trust signature associée à l’expression rationnelle <[^>]+@example.net>$. Dans ce cas, les trust signatures émises par Bob ne seront considérées comme légitimes que si elles sont appliquées sur des identités dont l’adresse e-mail est dans le domaine example.net. Si Bob certifie une identité Charlie <charlie@nimportequoi.example>, sa certification sera ignorée.

    Ce mécanisme est analogue à l’extension Name Constraints du monde X.509, qui limite les domaines pour lesquels une autorité de certification est habilitée à émettre des certificats.

    Note

    L’implémentation de cette fonctionnalité dans GnuPG est plus restrictive que ne le permet le RFC 4880. GnuPG ne permet que d’exprimer une contrainte sur le domaine de l’adresse e-mail (comme dans l’exemple ci-dessus) ; il n’est pas possible de spécifier librement une expression rationnelle arbitraire.

    Le modèle Trust On First Use

    Pourquoi un nouveau modèle de confiance ?

    Le modèle de confiance Trust On First Use (TOFU) a été introduit dans GnuPG 2.1.10, en décembre 2015. C’est la première introduction d’un nouveau modèle de confiance depuis les débuts de GnuPG.

    La raison d’être de ce modèle part d’un constat qui ne surprendra guère les utilisateurs de GnuPG (ou de toute autre implémentation d’OpenPGP) : la toile de confiance est trop complexe à appréhender. Beaucoup d’utilisateurs (y compris parfois des utilisateurs de longue date) ne la comprennent pas réellement, ou ne comprennent pas toutes ses subtilités, et en conséquence ne l’utilisent pas correctement. Et même pour les connaisseurs, elle est souvent trop pénible à utiliser.

    Le modèle de la « confiance à la première utilisation » est, sur le papier, moins « puissant » que la toile de confiance ; il est vulnérable, par définition, à une tentative d’usurpation lors du premier contact. Mais il est plus facile à appréhender et à utiliser. Il offre ce que certains auteurs anglophones appellent de la better-than-nothing security.

    L’introduction de ce modèle de confiance (qui n’est pas encore le modèle par défaut — c’est toujours la toile de confiance étendue, pour l’instant — mais qui est appelé à le devenir) s’inscrit dans le cadre d’une ré-orientation des objectifs de GnuPG dans l’ère post-Snowden. Depuis ses débuts, GnuPG a été conçu pour répondre aux besoins d’utilisateurs faisant face à un niveau de menace élevé — le genre d’utilisateurs pour qui la difficulté d’accès du logiciel n’était pas forcément rédhibitoire, ou était un prix à payer acceptable. Désormais, à l’ère de la surveillance de masse, les développeurs de GnuPG considèrent que GnuPG doit être facile d’accès par défaut, pour les utilisateurs « ordinaires » souhaitant échapper à cette surveillance.8

    Note

    L’idée n’est absolument pas de « castrer » GnuPG, de le rendre inutile à ceux qui font face à un niveau de menace élevé — notamment, ceux qui font face à des attaques ciblées et non pas à la simple surveillance de masse. C’est juste que, par défaut, GnuPG ne sera pas configuré pour eux.

    Principe

    GnuPG conserve une trace de toutes les associations {adresse e-mail, clef} qu’il rencontre (une telle association est appelée un binding dans la description du modèle), et associe à chacune d’elles une politique TOFU, parmi les cinq suivantes : unknown, auto, good, bad, et ask.

    Chaque politique (à part la politique ask) correspond à une valeur possible de validité : unknown correspond à une validité inconnue, auto à une validité marginale, good à une validité complète, et bad correspond à une invalidité. Lorsque le modèle est interrogé pour déterminer la validité d’une identité, il renvoie la valeur de validité correspondant à la politique associé au binding concerné. (Si la politique est ask, GnuPG demande en direct à l’utilisateur ce qu’il doit faire avec cette clef.)

    À la réception d’un premier message signé par bob@example.com, le binding {bob@example.com, 0xB4902A74} est ajouté à la base de données TOFU, associé à la politique par défaut qui est auto. Cela confère automatiquement une validité marginale à cette clef.

    L’utilisateur peut à tout moment changer la politique associée à un binding. Par exemple, si Alice est sûre qu’il s’agit bien de la clef de Bob, elle peut lui assigner la politique good, conférant à sa clef une validité complète.9

    À la réception d’un nouveau message de bob@example.com, GnuPG vérifie si la clef utilisée est la même que celle figurant dans le binding précédemment enregistré. Si c’est bien le cas, il n’y a pas de conflit, et GnuPG affiche que le message provient d’une clef marginalement valide. Si la clef est différente, l’utilisateur est alerté de l’existence d’un conflit.

    Choix de la politique TOFU par défaut

    La politique TOFU par défaut est celle appliquée implicitement lorsqu’un binding est ajouté à la base de données TOFU. Par défaut, cette politique par défaut est auto (comme on l’a vu ci-dessus), mais elle est modifiable avec l’option --tofu-default-policy. Et le choix de cette politique par défaut change profondément le comportement du modèle.

    Trois politiques peuvent être définies comme la politique TOFU par défaut : good, unknown, et auto.

    Avec good comme politique par défaut, on choisit un modèle « optimiste », dans lequel toute clef nouvellement rencontrée est implicitement considérée comme complètement valide. C’est en quelque sorte, le « vrai TOFU », le TOFU proprement dit.

    À l’inverse, avec unknown comme politique par défaut, on choisit un modèle « pessimiste » voire « paranoïaque ». Il n’y a aucune validité implicite, toute clef nouvellement rencontrée est à validité inconnue et le reste jusqu’à ce que l’utilisateur assigne explicitement une politique good ou auto. C’est ce qui se rapproche le plus du modèle de confiance « directe » que j’avais rapidement abordé en présentant les différents modèles de confiance, avec en plus la détection des conflits.

    Enfin, avec auto comme politique par défaut, on choisit un modèle intermédiaire, dans lequel toute clef nouvellement rencontrée est considérée comme marginalement valide.

    Le modèle TOFU+PGP

    Le modèle TOFU+PGP, comme son nom l’indique, est une combinaison du modèle de la toile de confiance étendue et du modèle TOFU.

    Pour déterminer la validité d’une identité, les deux modèles sont interrogés successivement ; l’identité est valide si ① elle est valide dans au moins un des deux modèles, et ② elle n’est invalide dans aucun des deux modèles.

    Ce modèle est particulièrement intéressant lorsque la politique TOFU par défaut est unknown. Dans ce cas, seule la toile de confiance assigne des valeurs de validité positives (validité marginale ou complète), et le modèle TOFU ne sert alors qu’à détecter les conflits.


    1. Traduction libre du terme anglais key material, désignant au sens strict la partie purement mathématique d’une clef cryptographique (par exemple, le couple {module, exposant} pour une clef RSA). Concrètement, c’est le contenu d’un paquet OpenPGP de type Public-Key Packet

    2. Et GnuPG ne fournit aucun moyen de passer outre — même l’option --expert, qui autorise certaines actions normalement déconseillées, ne permet pas d’utiliser une clef expirée ou révoquée. 

    3. C’est pourquoi on parle aussi parfois de calculated trust pour désigner la validité. 

    4. Cette volonté apparaît à plusieurs reprises dans le standard OpenPGP. En fait, ce standard peut être compris comme une “PKI en kit”, un ensemble de briques permettant d’élaborer une infrastructure de clef publique, davantage que comme une infrastructure de clef publique prête à l’emploi. 

    5. Les qualificatifs “simple” et “étendue” sont une invention de l’auteur, ils ne figurent pas dans les documentations de GnuPG. Nous verrons plus loin la différence entre les deux modèles. 

    6. Introduit dans GnuPG 2.1.10, sorti en décembre 2015. 

    7. Hors le cas des clefs expirées ou révoquées, qui sont toujours inconditionnellement invalides quel que soit le modèle de confiance. 

    8. Werner Koch, développeur principal de GnuPG, a exprimé cette idée lors de la rencontre annuelle des développeurs Debian de 2015 (DebConf 2015). L’enregistrement de son intervention est disponible, de même que ses diapositives

    9. Néanmoins, dans le modèle TOFU, la distinction entre la validité complète et la validité marginale est moins pertinente que dans le modèle de la toile de confiance, et Alice pourrait simplement laisser la politique par défaut. 

    Lire les commentaires

Travailler donc pour la gloire, et qu'un solide gain
Ne soit jamais l'objet d'un illustre écrivain.
-+- Nicolas Boileau, Art poétique -+-