Linuxfr.org

La version 1.6 de darktable est sortie ce 7 décembre 2014. Pour rappel, darktable est un logiciel d'édition de photos spécialisé dans les images RAW.

Cette nouvelle version n'apporte rien de révolutionnaire du point de vue de l'utilisateur, mais plusieurs petites améliorations sympathiques pour la convivialité, un nouveau module « suppression de la frange » (defringe) similaire au module « aberrations chromatiques » et un joli travail d'amélioration général du code et des performances.

• lien n°1 : Site officiel de darktable
• lien n°2 : Changements dans la version 1.6 de darktable
• lien n°3 : Carafife : tuto vidéo en français
• lien n°4 : dtstyle : styles darktable à télécharger et appliquer sur vos photos
• lien n°5 : Entretien LinuxFr.org avec Johannes Hanika pour darktable
• lien n°6 : Visualisation du développement de la version 1.6 en vidéo
• lien n°7 : Téléchargement de la version 1.6.0 (.tar.xz)
• lien n°8 : Manuel utilisateur en français
• lien n°9 : Article Wikipédia sur darktable

Sommaire

• Nouvelles fonctionnalités
• Export d’images
• Dans la chambre noire
  • Nouvelle opération « suppression de la frange » (defringe)
  • Mode automatique pour le module « niveaux » (levels)
  • Possibilité de désactiver la balance des blancs
  • Nouveau mode de reconstruction des couleurs pour le module « récupération des hautes lumières »
  • Meilleur outil dt-curve-tool pour créer une courbe de base (basecurve) depuis une paire d'images RAW/JPG
  • Limites flexibles (soft boundaries) sur les curseurs
  • Troncature de gamut sur le profil de couleur d'entrée
  • Gestion des couleurs
• API de script en Lua
• Améliorations de performances
• Améliorations internes
• Nouveaux appareils photos pris en charges

Une particularité de darktable est sa nature non-destructrice : l'image originale n'est jamais modifiée, mais l'utilisateur choisit un certain nombre de transformations à faire sur l'image et darktable applique ces transformations pour l'affichage à l'écran et l'export. L'utilisateur peut, par exemple, rectifier l'exposition, recadrer l'image, puis modifier la balance des blancs et ensuite décider de désactiver le module « exposition » : darktable ré-appliquera la balance des blancs et le recadrage.

Une autre particularité de darktable est de ne pas transiger avec la qualité : tous les calculs sont faits avec des nombres flottants 32 bits par canal et par pixel. darktable fait tout son possible pour garder de bonnes performances (utilisations des instructions spécifiques des processeurs modernes, OpenCL pour utiliser le GPU de la carte graphique si possible…), mais reste très exigeant en ressources (4 Go de RAM et un système 64 bits sont un minimum).

La suite de la dépêche est une traduction étoffée des notes de versions.

Nouvelles fonctionnalités

• Une nouvelle vue « diaporama » pour visualiser les images de la collection courante en plein écran. Oui, ça parait évident, mais ça manquait sur les versions précédentes !

• La vue « carte » (affichage des images géolocalisées sur fond OpenStreetMap) permet de n'afficher que les images de la collection courante sur le fond de carte ;

• Gestion des moniteurs haute résolution (alias « retina » pour les Macs) ;

• Paquets pour Mac OS X signés ;

• L'outil darktable-cli peut maintenant fonctionner sans serveur X ;

• Prise en charge des notes audio enregistrées par certains appareils photos ;

• Un mode « aperçu persistant », variante du mode « aperçu » qui permettait d'avoir temporairement une vue plein écran de l'image courante. Le mode « aperçu » (activé par la touche Z ou CTRL + Z pour avoir en plus la détection des zones de netteté) revient à la table lumineuse dès qu'on relâche la touche qui l'a activé. Le mode « aperçu persistant » reste activé jusqu'à ce qu'on appuie une deuxième fois sur la touche. Il n'a pas de raccourci par défaut, mais on peut l'activer dans les préférences globales (onglet « raccourcis », « vues », « table lumineuse ») ;

• Une option pour écraser le fichier de destination s'il existe dans le module « exportation » ;

• La possibilité de recharger au lancement de darktable les fichiers .xmp. Ces fichiers sont enregistrés à côté des images sur le disque et indiquent les modifications que darktable doit apporter à l'image. Ces fichiers .xmp viennent en doublon d'une base de données (située dans ~/.config/darktable/library.db). Recharger les .xmp peut être utile si on travaille sur les mêmes images depuis plusieurs machines ;

• Gestion des très grandes images (index plus grand que 32 bits). On peut maintenant éditer des images TIFF de 26 770 × 13 385 et, en théorie, des images de n'importe quelle taille peuvent être gérées. Ne pas essayer sur une petite configuration ou une machine 32 bits !

• Les réglages automatiques du module « correction des objectifs » (basé sur la bibliothèque Lensfun) peuvent maintenant être copiés-collés d'une image à l'autre. Avec les versions précédentes, si l'utilisateur avait activé ce module sur une image, les paramètres détectés automatiquement (objectif, focale, ouverture, distance de mise au point) étaient appliqués à l'identique sur les autres images quand on copiait-collait l'historique ou qu'on créait un style. Avec darktable 1.6, le module détecte si l'utilisateur a fait des changements dans l'interface graphique. S'il a laissé les valeurs par défaut (auto-détectées), alors darktable se comporte comme on pourrait s'y attendre : un copier-coller ou une application de style fait la détection automatique des paramètres avec les métadonnées de l'image cible.

Export d’images

• Lecture et écriture du format TIFF réécrit (gestion du 32 bits, de la compression) ;

• L'export JPEG permet de spécifier la résolution dans les méta-données du fichier généré (défaut à 300 points par pouces) ;

• Gestion des mots de passe avec libsecret pour parler aux gestionnaires de mots de passe de vos environnements de bureau préférés ;

• Utilisation de HTTPS pour l'export Flickr (nécessaire depuis juin 2014 pour parler aux API Flickr).

Dans la chambre noire Nouvelle opération « suppression de la frange » (defringe)

darktable possédait déjà deux outils pour réduire les aberrations chromatiques :

• le module « correction des objectifs », qui utilise une base de données des défauts connus des objectifs et applique la transformation inverse sur l'image pour réaligner les différentes couleurs ;
• et le module « aberrations chromatiques », qui travaille sur l'image RAW avant matriçage (et donc n'est pas applicable sur des images autres que RAW).

Le module « defringe » repère les franges de couleurs, et reconstruit une couleur moins saturée à partir des pixels voisins sur ces franges. Il fonctionne quel que soit le format d'image et quel que soit l'objectif utilisé. Le résultat est assez convaincant :

Cette transformation est appliquée par darktable après le module de correction des objectifs, donc il peut permettre de rectifier quelques aberrations qui seraient restées après celui-ci.

Mode automatique pour le module « niveaux » (levels)

Le mode par défaut de l'outil « niveaux » montre à l'utilisateur un histogramme et demande à l'utilisateur de placer trois points sur cet histogramme : le noir, le gris, et le blanc :

darktable ajuste ensuite la luminosité de chaque pixel afin que le point noir choisi soit effectivement noir (tout ce qui est à gauche de ce point dans l'histogramme est tronqué en noir également), que le point blanc (et tout ce qui est à droite dans l'histogramme) soit blanc et que le gris soit gris.

Avec darktable 1.6, on peut maintenant passer en mode « automatique » et spécifier un pourcentage de pixels au lieu d'un point sur l'histogramme. Par exemple, si on souhaite que 10 % de la surface de l'image soit noire, on peut placer le curseur de noir à 10 % :

On peut utiliser cet outil pour changer assez facilement la luminosité des parties sombres ou des parties claires de l'image. Par exemple, en plaçant le curseur de noir à 30 %, on assombrit les parties sombres, sans toucher aux parties claires (version transformée à droite de l'image) :

Possibilité de désactiver la balance des blancs

Le module de balance des blancs applique un coefficient multiplicateur sur chaque canal de couleur. On peut maintenant le désactiver.

Nouveau mode de reconstruction des couleurs pour le module « récupération des hautes lumières »

Les zones d'images surexposées posent plusieurs problèmes lors du développement de fichiers RAW. Chaque canal (rouge, vert, bleu) peut arriver à dépasser le maximum et être tronqué. Si seulement un ou deux des canaux sont tronqués, les couleurs en sortie du capteur ne correspondent plus aux couleurs réelles. Si tous les canaux sont tronqués, il n'y a plus d'information de couleur du tout, la zone de l'image est blanche (ou pas, selon le réglage de la balance des blancs).

darktable doit donc reconstruire les zones d'images surexposées. Par défaut, il considère que si l'un des canaux de couleur est tronqué, l'image est blanche (ou grise) à cet endroit. Quand les pixels autour de la zone surexposée sont colorés, le résultat n'est pas forcément très bon :

La version 1.6 a maintenant un mode « reconstruire les couleurs » dans le module récupération des hautes lumières qui permet de faire mieux, en regardant la couleur et la structure des pixels non-surexposés avoisinants :

Il ne faut pas attendre de miracle (il manque de l'information dans l'image…), mais c'est un outil de plus pour récupérer des photos qui auraient pu être ratées.

Meilleur outil dt-curve-tool pour créer une courbe de base (basecurve) depuis une paire d'images RAW/JPG

cf. http://www.darktable.org/2013/10/about-basecurves/ pour quelques explications sur l'outil.

Limites flexibles (soft boundaries) sur les curseurs

On pouvait déjà faire un clic droit sur les curseurs des différents modules pour faire un réglage fin (à la souris, ou au clavier). Si l'utilisateur entre une valeur au clavier qui dépasse de l'intervalle initialement prévu, alors l'échelle du curseur s'adapte :

Troncature de gamut sur le profil de couleur d'entrée

L'essentiel des transformations de darktable sont faites dans l'espace de couleur Lab (un canal L pour la lumière, deux canaux a et b pour la couleur). Dans certains cas (pixels sombres et très saturés), il peut arriver que le canal L soit négatif, ce qui pose problème dans la suite des transformations. Par exemple, sur cette image extraite du manuel utilisateur, on peut distinguer un anneau de pixels noirs autour du cercle bleu :

Le module « profil de couleur d'entrée » (qui fait la conversion depuis les couleurs de l'image d’origine vers l'espace Lab) a maintenant un mode « troncature de gamut » qui permet de rester dans un espace de couleur plus réduit où ces problèmes n'apparaissent pas :

Un autre exemple assez parlant : https://lwn.net/Articles/623216/.

Gestion des couleurs

• Les conversions de couleurs sont plus rapides (via l'utilisation d'OpenMP pour paralléliser les opérations) ;

• Gestion native du profil linéaire Rec2020 (utilisé par le standard de télévision UHDTV) ;

• Gestion des profils ICC intégrés à l'image pour les images PNG et TIFF.

API de script en Lua

• Copie, déplacement, réinitialisation et effacement d'images ;

• Gestion des barres de progressions ;

• Manipulation limitée de bibliothèques et de vues dans l'interface graphique ;

• Importation/exportation de styles ;

• Un système de callback permettant d'appeler un script Lua après un changement dans l'interface (mode de groupage, vue active, changement d'affichage) ;

• Manipulation des snapshots ;

• Gestion de plus de types de préférences ;

• API versionnée (darktable.configuration.check_version pour savoir quelle version de l'API est utilisée) ;

• darktable.modules a été supprimé.

Améliorations de performances

• Beaucoup d'améliorations de vitesse en utilisant du code SSE pour les opérations sur les images ;

• Accélération en particulier des modules « Balance des blancs », « inverser », des exports EXR et PFM, de l'algorithme de dématriçage « AMaZE » (toujours lent, mais moins qu'avant).

Améliorations internes

• Introspection des paramètres de modules ;

• Correction de warnings émis par clang/address-sanitizer/… ;

• Simplification du code utilisé pour l'auto-orientation des images RAW ;

• Migration vers rawspeed terminé pour le chargement des images RAW ;

• Corrections de bugs.

Nouveaux appareils photos pris en charges

• Prise en charge des capteurs de type x-trans, utilisés par certains appareils Fujifilm. Ces capteurs utilisent une disposition de pixels non-standard, qui demandent une adaptation de l'algorithme de dématriçage ;

• Des dizaines de nouveaux boîtiers pris en charge, des profils pour le module de réduction du bruit… Cf. les notes de version détaillées pour une liste complète.

Télécharger ce contenu au format Epub

Lire les commentaires

Une vulnérabilité (CVE-2014-9390) a été annoncée hier soir concernant le logiciel de gestion de versions le plus en vogue en ce moment, j'ai nommé Git, ainsi que sur Mercurial, autre logiciel de la même catégorie. Elle a déjà été corrigée, je vous invite donc à mettre à jour vos installations.

Github, le service d'hébergement de dépôt Git lui aussi très en vogue, a de son côté annoncé avoir vérifié tous les dépôts présents sur ses serveurs à la recherche d'exploitations de cette vulnérabilité. Mesure de sécurité supplémentaire, il refuse désormais les push exploitant cette faille.

NdM : Merci à RoM1 et Sébastien Douche pour les précisions apportées dans la dépêche. La faille a été trouvée par le créateur de Mercurial, Matt Mackall, et Augie Fackler. La vulnérabilité se décline en trois parties :

• la sensibilité à la casse dans Git, déjà corrigé dans Mercurial en 2008 ;
• l’expansion des noms courts sous Windows (PROGRA~1 → Program Files), déjà corrigé dans Mercurial ;
• la découverte récente de la façon non documentée dont Darwin (Apple) s’amuse avec HFS+ à ignorer certains caractères spéciaux et qui peut créer de nouvelles collisions de nom (cf la correction chez Mercurial, qui a permis la correction côté Git).

• lien n°1 : Annonce de Github
• lien n°2 : Annonce du correctif Git
• lien n°3 : Annonce du correctif Mercurial
• lien n°4 : Référence CVE-2014-9390

Cette vulnérabilité concerne le fichier .git/config qui définit les paramètres du dépôt de travail[1]. Elle fonctionne sur les systèmes de fichiers non sensibles à la casse, comme les systèmes de fichiers de Microsoft (FAT ou NTFS) ou celui d'Apple (HFS+).

Son fonctionnement est très simple. Sur ces systèmes de fichiers, si on clone un dépôt Git contenant un fichier .Git/config, ce fichier viendra alors écraser le fichier .git/config. À partir de là, on peut imaginer une pléthore d'exploitation (ce travail est laissé au lecteur).

Cette faille soulève la question de la gestion des divers systèmes de fichiers qui gèrent chacun différemment les noms de fichiers. L'annonce du correctif indique qu'en plus du simple cas de la casse, certains systèmes de fichiers peuvent avoir d'autres cas de collision, comme par exemple git~1/config qui sous Windows se verra traité comme .git/config.

La solution pour une interopérabilité maximale est de se réduire au plus grand sous-ensemble commun, et c'est désormais ce que fait Git par défaut (comportement paramétrable cependant).

[1] Par « dépôt de travail » on entend un dépôt qui n'est pas bare (non créé avec git init --bare), et donc dans lequel on peut effectivement travailler.

Télécharger ce contenu au format Epub

Lire les commentaires

FAImaison, fournisseur d'accès à Internet Nantais, vous propose un « ApéroMaison » le 18 décembre 2014 à 19h au Café Flesselles (3 allée Flesselles à Nantes). Cette rencontre vous permettra d'échanger de façon informelle et conviviale à propos d'Internet et de ses usages, et de découvrir FAImaison en dehors des réunions hebdomadaires.

L’événement est ouvert à tous, l'entrée libre et gratuite.

• lien n°1 : FAImaison
• lien n°2 : Annonce sur l'Agenda du Libre
• lien n°3 : Le Flesselles sur OSM

Télécharger ce contenu au format Epub

Lire les commentaires

À la demande générale de deux personnes, dans cette dépêche je me propose de vous présenter l’application cryptographique « OpenPGP » pour cartes à puce au format ISO 7816. Une carte à puce dotée d’une telle application vous permet d’y stocker et de protéger vos clefs OpenPGP privées.

• lien n°1 : Présentation de la carte OpenPGP

Sommaire

• Présentation
  • Les clefs cryptographiques
  • Sécurité de la carte
  • Données stockées sur la carte
    • Les champs à usage défini
    • Les « champs privés » ou à usage indéfini
• Le matériel
  • La carte à puce
  • Le lecteur de cartes
• Les logiciels
  • Les pilotes de lecteurs de carte
  • Le middleware PCSC-Lite
  • GnuPG
    • À propos des versions de GnuPG
    • Comment GnuPG accède au lecteur de carte
    • Le pilote CCID interne
    • L’agent GnuPG
      • GnuPG 2.0.x
      • GnuPG 2.1.x
• Préparer la carte
  • Changer les PIN
  • Modifier les données de la carte
  • Les clefs privées
    • Créer une sous-clef d’authentification
    • Transférer les sous-clefs sur la carte
• Signer ou déchiffrer des messages OpenPGP
  • Le mode « PIN forcé » pour les signatures
• S’authentifier auprès d’un serveur SSH
• Utiliser un certificat X.509
  • Créer un certificat X.509
  • S’authentifier auprès d’un serveur web
  • Signer des documents OpenDocument
  • Signer des messages S/MIME
  • Utiliser la carte comme token PKCS #15
• Miscellanées
  • Communiquer avec Scdaemon et la carte
  • Ré-initialiser une carte bloquée

Présentation

La carte OpenPGP a été imaginée par les développeurs à l’origine de GnuPG et est spécialement conçue pour fonctionner avec ce dernier. Son utilisation est aussi transparente que possible et avoir vos clefs privées sur une carte OpenPGP ne change fondamentalement rien à la manière d’utiliser GnuPG : la seule différence est qu’à chaque fois que GnuPG aura besoin d’accéder à une de vos clefs privées, au lieu de vous demander la phrase de passe protégeant la clef sur votre disque dur, il vous demandera le PIN de la carte.

Outre la signature et le déchiffrement de messages OpenPGP, les autres usages possibles de la carte incluent :

• la signature ou le déchiffrement de messages S/MIME ;
• l’authentification auprès d’un serveur SSH ;
• l’authentification auprès d’un serveur TLS ;
• et probablement d’autres qui restent à imaginer ou à mettre en œuvre.

Les clefs cryptographiques

La carte OpenPGP permet de stocker jusqu’à trois clefs privées, une pour chaque type d’utilisation : une clef de (dé)chiffrement, une clef de signature et une clef d’authentification.

Le rôle majeur de la carte est de protéger ces clefs privées. Lorsqu’elles sont stockées sur la carte, il est par conception impossible de les en extraire, elles ne peuvent qu’être utilisées « sur place ».

Ainsi, toutes les opérations cryptographiques nécessitant l’une de ces clefs sont réalisées directement sur la carte elle-même : l’ordinateur envoie à la carte les données à déchiffrer 1 , signer ou authentifier et il reçoit le résultat de l’opération en retour, sans jamais avoir entraperçu les clefs.

Note

Faire réaliser les opérations cryptographiques par la carte ne les rend pas plus rapides, pour au moins trois raisons :

• il est peu probable que le processeur de la carte, même s’il est spécialisé, soit plus véloce que votre CPU ;

• l’échange de données entre l’ordinateur et la carte introduit un délai non négligeable ;

• la carte ne réalise en réalité qu’une partie du travail, le reste restant à la charge de l’ordinateur (précisément, entre autres, pour limiter le volume de données à transférer entre les deux appareils) ; par exemple, pour déchiffrer un message OpenPGP, la carte n’est responsable que du déchiffrement de la clef de session symétrique (soit seulement 16 octets pour une clef AES 128 bits) — le déchiffrement du corps du message est fait par l’ordinateur, une fois qu’il a obtenu de la carte la clef de session déchiffrée.

Bref, il ne faut pas compter sur la carte pour accélérer les opérations cryptographiques, ce n’est pas son but.

Pour l’instant, les clefs de la carte ne peuvent être que des clefs RSA — d’autres types de clefs, notamment à base de courbes elliptiques dont la prise en charge arrive dans GnuPG 2.1, seront probablement possibles à l’avenir. La spécification garantit une taille minimale pour chaque clef de 1024 bits et n’impose pas de taille maximale. En pratique, toutes les implémentations courantes devraient permettre des clefs de 2048 bits et certaines permettent des clefs de 4096 bits (c’est notamment le cas de l’implémentation de référence de ZeitControl — voir plus loin).

Sécurité de la carte

La carte OpenPGP est protégée par deux ou (optionnellement) trois codes PIN, désignés PW1 ou « PIN utilisateur » (User PIN, parfois appelé seulement « PIN », par opposition au suivant), PW3 ou « PIN administrateur » (Admin PIN) et RC (Resetting Code, optionnel).

Les opérations de la carte peuvent être classées en fonction du PIN nécessaire pour les réaliser :

• aucun PIN n’est nécessaire pour lire les données de la carte ;
• le PIN utilisateur est demandé pour toute opération exploitant les clefs privées (signature, déchiffrement, authentification) et pour changer le PIN utilisateur lui-même ;
• le PIN administrateur est demandé pour presque toutes les écritures sur la carte (modification des informations stockées sur la carte, importation ou génération de clefs privées, changement d’un PIN autre que le PIN utilisateur).

À chaque PIN est associé un compteur d’essai (Retry Counter), qui est décrémenté à chaque saisie incorrecte du PIN. Tant que le compteur est supérieur à zéro, il suffit de saisir le PIN correct pour remettre le compteur à trois. Lorsque le compteur tombe à zéro, la vérification du PIN correspondant n’est plus possible et toutes les opérations dépendantes de cette vérification sont interdites. Dans ce cas, il faut enregistrer un nouveau PIN pour remettre le compteur à trois.

Concrètement, cela signifie ① que trois saisies erronées consécutives du PIN utilisateur entraînent un blocage de la carte (puisque toutes les opérations cryptographiques nécessitent de vérifier le PIN utilisateur), ② que la carte peut être débloquée en changeant le PIN utilisateur, après avoir saisi le PIN administrateur, ③ qu’après trois saisies erronées consécutives du PIN administrateur, la carte est irréversiblement bloquée (puisqu’il faudrait changer le PIN administrateur pour remettre son compteur d’essai à trois, or cela nécessite de vérifier le PIN administrateur, ce qui n’est justement pas possible si son compteur est à zéro).

Note

Certaines implémentations prévoient néanmoins la possibilité de ré-initialiser complètement une carte dont les compteurs d’essai des PIN utilisateur et administrateur sont tous les deux à zéro. La ré-initialisation efface toutes les données de la carte, restaure les PIN utilisateur et administrateur par défaut et remet leur compteur à trois.

Et le Resetting Code ? S’il est défini, il peut être utilisé à la place du PIN administrateur pour ré-initialiser le PIN utilisateur et donc débloquer la carte. Peu pertinent pour une utilisation individuelle, le RC est surtout utile dans les situations où la carte est délivrée par une autorité à un utilisateur qui n’est pas supposé en modifier le contenu et à qui on ne veut donc pas révéler le PIN administrateur, mais que l’on veut tout de même autoriser à débloquer sa carte tout seul. (Le RC est donc assimilable au code « PUK » utilisé pour débloquer une carte SIM.) Par défaut, aucun Resetting Code n’est défini et son compteur d’essai est à zéro.

Le PIN utilisateur doit faire au minimum 6 caractères, le PIN administrateur et le Resetting Code au minimum 8. La taille maximale n’est pas définie dans la spécification (elle est de 32 caractères pour chaque PIN sur l’implémentation de référence de ZeitControl). Il est possible d’utiliser n’importe quel caractère UTF-8 et non pas seulement des chiffres, mais un code non-numérique ne pourra pas être saisi sur le clavier intégré à certains lecteurs de carte.

Dans la suite de ce document, « PIN » sans précision désignera implicitement le PIN utilisateur. Lorsqu’il sera question du PIN administrateur, il sera toujours désigné explicitement.

Données stockées sur la carte

Outre les clefs privées, la carte OpenPGP contient un certain nombre de champs (“Data Objects” ou DO, dans le jargon des cartes à puce) pour stocker des données supplémentaires.

Les champs à usage défini

Ce sont des champs dont l’usage est explicitement défini dans la spécification de la carte OpenPGP. Toutefois, GnuPG n’utilise pas lui-même la plupart de ces champs — il permet de les consulter et les modifier, mais c’est à l’utilisateur ou à d’autres programmes exploitant la carte de leur trouver une utilisation.

Ces champs sont :

• le nom du détenteur de la carte ;
• son sexe ;
• ses préférences linguistiques : une liste de 1 à 4 codes de langue au format ISO 639-1 ;
• son « identifiant » : la spécification mentionne la possibilité qu’un système d’authentification basée sur la carte OpenPGP utilise ce champ pour savoir sur quel compte connecter l’utilisateur une fois qu’il a saisi son PIN, mais je ne connais pas de systèmes qui le font ;
• un certificat : typiquement, un certificat X.509, mais n’importe quel autre format est possible (GnuPG traite ce champ comme un simple blob binaire) ;
• une URL vers la clef publique de l’utilisateur : GnuPG s’en sert pour rapatrier automatiquement la clef publique en question, ce qui permet d’avoir rapidement un trousseau opérationnel lorsque vous êtes amenés à travailler sur une machine qui n’est pas la vôtre ;
• jusqu’à trois « empreintes de clefs de confiance » (“CA Fingerprints”) : des empreintes SHA-1 de clefs considérées valides et auxquelles il est fait une confiance absolue — là encore, GnuPG ne se sert pas de ces champs et je ne connais aucun exemple concret d’utilisation.

Les « champs privés » ou à usage indéfini

En plus des champs ci-dessus, la version 2.0 de la spécification définit 4 champs inutilisés, de 254 octets chacun, dont l’usage est entièrement et officiellement laissé à la discrétion de l’utilisateur : les “Private Use DOs” 1 à 4.

La différence entre ces 4 champs réside dans le PIN demandé pour y accéder en lecture ou en écriture :

private # . Lecture . Écriture Private DO 1 . aucun PIN . PIN utilisateur Private DO 2 . aucun PIN . PIN administrateur Private DO 3 . PIN utilisateur . PIN administrateur Private DO 4 . PIN administrateur . PIN administrateur

(On notera que ces conditions s’écartent quelque peu du principe général énoncé plus haut selon lequel la lecture de la carte ne demande pas de PIN et l’écriture demande le PIN administrateur.)

Ces champs sont vides par défaut, il appartient à chacun d’imaginer l’usage qu’il peut en faire. (La carte fournie par la FSFE à ses adhérents contient, dans le Private DO 2, le numéro, le nom et l’adresse électronique en @fsfe.org de l’adhérent.)

Le matériel La carte à puce

La « carte OpenPGP » est juste une spécification ; tout le monde peut l’implémenter sur le support de son choix.

Actuellement, l’implémentation la plus répandue est réalisée sur la carte BasicCard de ZeitControl, une carte à puce programmable en BASIC. Elle est distribuée par Kernel Concepts. La Free Software Foundation Europe fournit également à tous ses nouveaux fellows un exemplaire personnalisé de cette carte, aux couleurs de la FSFE et sérigraphié au nom de l’adhérent.

Gnuk est une implémentation de la carte OpenPGP pour microcontrôleur STM32F103, permettant notamment de réaliser un token USB — un périphérique qui apparaît, aux yeux de l’ordinateur, comme un lecteur de cartes à puce classique contenant une carte unique insérée en permanence. Le FST-01 est un exemple d’un tel token basé sur Gnuk, il est disponible auprès de Seeed Bazaar.

Le CryptoStick est un autre token USB formé d’une carte OpenPGP physique (celle de ZeitControl, a priori) embarquée dans un boîtier USB. Le projet envisage aussi de créer une version basée sur Gnuk.

Il existe aussi plusieurs implémentations ciblant des Java Cards (cartes à puce programmables en Java). La YubiKey NEO en contient une, désactivée par défaut — Yubico fournit les instructions pour l’activer.

Le lecteur de cartes

À moins d’opter pour un token USB comme le FST-01, le CryptoStick ou la YubiKey, un lecteur de cartes à puce est évidemment nécessaire pour utiliser une carte OpenPGP.

Il existe une grande variété de lecteurs, voici les principaux points à considérer pour choisir le sien.

Port série, port PCMCIA ou port USB ? La plupart des lecteurs aujourd’hui sont des lecteurs USB — et, faute d’expérience de l’auteur avec les autres types de lecteurs, ce sont les seuls dont il sera question dans cet article.

Clavier intégré ? Un petit nombre de lecteurs contiennent un clavier intégré permettant de saisir le PIN directement sur le lecteur (par exemple le SPR 332 de SCM Microsystems). L’intérêt en termes de sécurité est que dans ce cas, le PIN ne passe jamais par l’ordinateur et n’est pas susceptible d’être enregistré par un éventuel keylogger ou autre logiciel malveillant. Attention, le clavier ne comprend la plupart du temps que des chiffres, interdisant la saisie d’un PIN qui ne serait pas entièrement numérique ; certains de ces lecteurs limitent aussi la longueur maximale du PIN, qui peut être plus courte que ce qu’autorise la carte OpenPGP.

Prise en charge de l’Extended APDU ? Les APDU (Application Protocol Data Unit) sont les messages échangés entre la carte à puce et son lecteur. Ils peuvent être short (les données transmises sont limitées à 256 octets) ou extended (données limitées à 65536 octets). Pour importer une clef de 1024 bits sur la carte OpenPGP, le lecteur doit prendre en charge les extended APDU.

Un autre point important est bien sûr la prise en charge du lecteur sous votre système. La question des pilotes sera abordée dans la section suivante, mais disons tout de suite que sous GNU/Linux, vous vous simplifierez probablement la tâche en choisissant un lecteur conforme à la norme CCID (Chip/Card Interface Device). Le pilote ccid prend en charge une grande partie de ces lecteurs et ses développeurs tiennent à jour des listes des lecteurs pris en charge ou non — et indiquent en plus pour chaque lecteur les problèmes potentiels comme l’absence de gestion des extended APDU.

L’auteur de ces lignes a choisi pour sa part le SCR 3500 SmartFold de SCM Microsystems (maintenant Identive), un petit lecteur compact et aisément transportable. Il fait partie des lecteurs qui « devraient fonctionner » (should work readers) avec le pilote ccid et je confirme qu’il fonctionne bien. Pour ce que ça vaut, j’en suis satisfait, même si je le trouve un peu trop fragile pour l’utilisation nomade à laquelle sa taille le destine.

Les logiciels

En règle générale, l’utilisation de cartes à puce nécessite une pile logicielle à trois niveaux : un pilote pour le lecteur de cartes, un middleware exposant une API standard d’accès aux cartes à puce (permettant aux applications de faire abstraction du matériel et des pilotes) et les applications utilisatrices.

Les pilotes de lecteurs de carte

Le pilote ccid déjà évoqué ci-dessus prend en charge un grand nombre de lecteurs USB compatibles avec la norme CCID. Cela inclut également les tokens USB comme le CryptoStick, les tokens basés sur Gnuk ou le YubiKey NEO, qui sont tous compatibles CCID.

Il existe également des pilotes plus spécifiques pour des modèles précis de lecteurs. Pour les utilisateurs de Debian (et dérivés), le paquet virtuel pcsc-ifd-handler en fournit commodément une liste.

Des modèles non-pris en charge par les pilotes libres disposent parfois d’un pilote propriétaire fourni par le constructeur. C’est le cas par exemple des lecteurs de la gamme HID Omnikey, dont les pilotes sont disponibles sur www.hidglobal.com/drivers.

Libre ou non, le pilote d’un lecteur USB doit être installé dans un dossier appelé _nom-du-pilote_.bundle, lui-même situé dans le dossier /usr/local/pcsc/drivers (par défaut — ce dossier est configurable à la compilation de PCSC-Lite, vous pouvez consulter la page de manuel de pcscd(8) pour connaître le chemin effectif sur votre système). Vous pouvez bien sûr ignorer cette étape si le pilote est fourni dans les paquets de votre distribution.

Le middleware PCSC-Lite

PCSC-Lite est une implémentation libre pour systèmes Unix-like (y compris Mac OS X) de l’API Windows SCard, introduite dans Windows XP/Windows Server 2003 et normalisée par la suite sous le nom de spécification PC/SC.

PCSC-Lite comprend deux composants : un démon (pcscd) qui gère le lecteur et communique avec la carte et une bibliothèque (libpcsclite.so), qui expose l’API PC/SC aux programmes qui lui sont liés.

Le paquet de PCSC-Lite fourni par votre distribution devrait faire le nécessaire pour que le démon pcscd soit automatiquement lancé au démarrage. Si ce n’était pas le cas, consultez la documentation de votre système pour savoir comment ajouter le script shell / le job Upstart / l’unité Systemd / le truc lanceur de machins appropriés à votre système.

À son lancement, le démon pcscd détecte automatiquement les lecteurs de carte présents sur le système. En revanche, si vous connectez votre lecteur série ou PCMCIA après le lancement du démon, celui-ci ne le détectera pas automatiquement, il faudra utiliser pcscd --hotplug pour l’inciter à rescanner ; ceci n'est pas nécessaire pour les lecteurs USB (cf commentaire.

Sinon il est possible d'utiliser une règle Udev semblable à la suivante (à ajouter dans /etc/udev/rules.d/90-local.rules, ou l’équivalent pour votre distribution) :

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="04e6", ATTR{idProduct}=="5410", RUN+="/usr/sbin/pcscd --hotplug"

où 04e6 et 5410 identifient le fournisseur et le modèle de votre lecteur, respectivement (les valeurs données ici correspondent au SCR 3500 de l’auteur, vous pouvez trouver celles correspondants à votre modèle avec lsusb -v par exemple).

Si pcscd tourne sous un compte utilisateur dédié non-privilégié (ce qui est recommandé), il faut de plus s’assurer que ledit compte possède les droits sur le lecteur de carte. Le plus simple pour cela est de compléter la règle Udev ci-dessus en ajoutant les clefs suivantes (en supposant ici que pcscd tourne sous le compte utilisateur scard) :

[…], OWNER="scard", MODE="600" GnuPG

GnuPG est bien entendu la principale application utilisatrice de la carte OpenPGP et c’est la seule qui sera abordée dans cet article. Sachez néanmoins que d’autres applications peuvent exploiter cette carte. En effet, quoique développée spécifiquement pour les besoins de GnuPG, la carte OpenPGP est compatible avec le standard PKCS#15, qui définit une manière commune de stocker et d’accéder à des données cryptographiques sur une carte à puce. En fait, on peut voir la carte OpenPGP comme une carte PKCS#15, avec quelques spécificités propres à OpenPGP en plus. (Réciproquement, GnuPG peut aussi exploiter des cartes PKCS#15 standards en plus de « sa » carte OpenPGP.)

À propos des versions de GnuPG

Il existe actuellement trois variantes de GnuPG : la branche 1.x, dite « classique », dont la dernière version à l’heure où ces lignes sont écrites est la 1.4.18 ; la branche 2.0.x dite « stable » (dernière version : 2.0.26) ; et la nouvelle version 2.1.1 dite « moderne » qui vient tout juste de sortir le 16 décembre 2014.

Toutes les variantes permettent d’utiliser la carte OpenPGP, mais GnuPG 1.x seul ne permet que les opérations « de base » (éditer le contenu de la carte, déchiffrer et signer des messages OpenPGP). Les usages plus avancés qui seront décrits plus loin et, notamment, l’utilisation de la clef d’authentification, nécessitent les outils auxiliaires apportés par la branche 2.x, en particulier l’agent GnuPG (gpg-agent). GnuPG 2.x est donc conseillé pour exploiter tout le potentiel de la carte OpenPGP.

Note

Incidemment, avec la sortie de GnuPG 2.1.0 il semble clair que GnuPG 1.x n’a probablement pas beaucoup d’avenir sur le bureau. Entre autres indices :

• Les algorithmes à base de courbes elliptiques, qui viennent de faire leur entrée dans GnuPG 2.1, ne seront pas pris en charge par GnuPG 1.x.
• GnuPG 2.1 introduit un nouveau format de stockage des trousseaux de clefs incompatible avec celui des précédentes versions. Auparavant, il était possible d’utiliser conjointement GnuPG 1.x et GnuPG 2.0.x avec un trousseau commun, puisque les deux versions utilisaient le même format. Désormais, si la cohabitation de GnuPG 1.x et GnuPG 2.1 est toujours possible, les deux versions utiliseront chacune un trousseau distinct et les modifications faites avec GnuPG 1.x ne seront pas répercutées sur le trousseau de GnuPG 2.1 et inversement.
• Werner Koch lui-même explique qu’il maintient GnuPG 1.x principalement pour les besoins des anciennes plates-formes et des serveurs.

Dans le reste de ce document, je supposerai l’utilisation de GnuPG 2.x, en faisant lorsque c’est nécessaire la distinction entre 2.0 et 2.1. Les captures de sortie standard seront issues de GnuPG 2.0.26, mais sauf mention contraire, tous les exemples seront applicables à GnuPG 2.1.

Si vous tenez à utiliser GnuPG 1.x, sachez que vous pouvez l’utiliser conjointement avec l’agent GnuPG de la branche 2.x. Dans ce cas, certains des « usages avancés » vous seront accessibles, notamment l’authentification SSH. En revanche, si vous tenez à utiliser GnuPG 1.x seulement (sans agent), vous ne pourrez pas faire usage de la clef d’authentification (en tout cas pas avec GnuPG).

Comment GnuPG accède au lecteur de carte

Les applications de GnuPG 2.x (gpg2 et gpgsm) n’accèdent jamais directement au lecteur de carte, dont ils sont séparés par plusieurs niveaux d’indirection. Elles interagissent seulement avec l’agent GnuPG, un démon qui gère les clefs secrètes et les phrases de passe pour l’ensemble du système GnuPG 2.x.

L’agent GnuPG lui-même délègue la gestion des cartes à puce à un autre démon, Scdaemon (SmartCard Daemon). C’est lui seul qui s’occupe de détecter le lecteur de carte et de communiquer avec la carte qu’il contient. Il utilise un protocole ad-hoc pour recevoir ses instructions de l’agent GnuPG.

Scdaemon dispose de deux options pour accéder au lecteur de carte. Dans le cas général, il utilise le middleware PCSC-Lite que nous avons vu précédemment. Mais il peut aussi utiliser un petit pilote CCID interne, qui lui permet de communiquer directement avec les lecteurs USB compatibles sans passer par un intermédiaire.

GnuPG 1.x, de son côté, peut utiliser l’agent GnuPG (ce qu’il fait automatiquement par défaut, s’il détecte qu’un agent est en cours d’exécution), auquel cas tout se passe comme avec GnuPG 2.x. Mais il peut aussi se passer des démons auxiliaires et communiquer seul avec le lecteur de carte.

Le pilote CCID interne

Comme évoqué à l’instant, GnuPG (toutes versions confondues) contient un petit pilote générique pour les lecteurs compatibles CCID. Ses développeurs décrivent ce pilote comme “un pilote limité […] à utiliser en dernier recours quand rien d’autre ne fonctionne ou que l’on tient à avoir un système minimal pour des raisons de sécurité”.2

Si votre lecteur de carte est pris en charge par le pilote interne, vous pouvez être tenté de simplifier la pile logicielle en vous passant du middleware PCSC-Lite. Gardez toutefois à l’esprit que le pilote interne est spécifique à GnuPG : si vous prévoyez d’utiliser votre lecteur pour d’autres applications (ne serait-ce que pour explorer, par curiosité, le contenu de votre carte bancaire, de votre carte vitale ou de votre carte de transports en commun, par exemple avec Cardpeek), vous aurez besoin de PCSC-Lite de toute façon.

Pour utiliser PCSC-Lite, il suffit que le démon de PCSC-Lite soit démarré : GnuPG tentera d’accéder au lecteur avec son pilote interne, échouera puisque le lecteur sera déjà monopolisé par pcscd et se rabattra, automatiquement, sur PCSC-Lite (vous pouvez éventuellement désactiver explicitement le pilote interne, en ajoutant l’option disable-ccid dans le fichier de configuration de scdaemon, $GNUPGHOME/scdaemon.conf).

Inversement, pour utiliser le pilote interne, assurez-vous que PCSC-Lite n’est pas installé (ou, a minima, que son démon n’est pas démarré) et que votre propre compte utilisateur, sous l’identité duquel tourne GnuPG, a accès au lecteur de carte.

L’agent GnuPG

L’agent GnuPG (gpg-agent) est indispensable au bon fonctionnement de GnuPG 2.x. et à l’exploitation de toutes les fonctionnalités de la carte OpenPGP. GnuPG 2.1.0 a introduit quelques changements importants dans la façon d’utiliser l’agent, il est donc utile de profiter de cet article pour les aborder.

GnuPG 2.0.x

L’agent GnuPG 2.0.x peut être soit lancé au démarrage d’une session utilisateur, soit à la demande sitôt qu’un composant de GnuPG en a besoin.

Pour démarrer l’agent en même temps que votre session graphique, ajoutez simplement la ligne suivante à votre fichier ~/.xprofile :

eval $(gpg-agent --daemon)

Puis redémarrez votre session. L’agent sera lancé en même temps et écoutera sur une socket Unix au nom aléatoire et la variable GPG_AGENT_INFO sera définie dans l’environnement, pour permettre aux composants de GnuPG de trouver l’agent en cours d’exécution.

Notez que votre gestionnaire de paquets s’est peut-être déjà chargé de ça pour vous — c’est au moins le cas sur Debian, où le paquet gnupg-agent ajoute un script /etc/X11/Xsession.d/90gpg-agent à cet effet.

Si vous préférez que l’agent soit démarré seulement quand il est nécessaire plutôt que systématiquement au début de la session, il doit être configuré pour utiliser une socket au nom constant et prédéfinie ($GNUPGHOME/S.gpg-agent). Cela se fait soit à la compilation, en passant l’option --enable-standard-socket au script configure, soit à l’exécution en ajoutant l’option use-standard-socket dans le fichier de configuration de l’agent ($GNUPGHOME/gpg-agent.conf). Une fois l’agent configuré ainsi, la ligne ci-dessus dans le fichier ~/.xprofile n’est plus nécessaire, le premier programme de GnuPG 2.0.x ayant besoin de l’agent en invoquera automatiquement un s’il ne détecte pas la socket « standard ».

Le démarrage à la demande a toutefois l’inconvénient que seuls les composants de GnuPG 2.x sont capables de démarrer l’agent ainsi. GnuPG 1.x par exemple ne peut pas le faire et même si vous ne prévoyez d’utiliser que GnuPG 2.x, gardez à l’esprit que certains frontends graphiques (comme Enigmail par exemple) font par défaut appel à GnuPG 1.x. Vous devez donc soit modifier la configuration de ces frontends, pour qu’ils appellent gpg2 au lieu de gpg, soit forcer tout de même l’agent à démarrer au début de la session pour que gpg puisse le trouver.

Une autre raison de forcer le démarrage de l’agent en début de session est si vous prévoyez de l’utiliser comme agent SSH (ce qui est nécessaire pour utiliser la carte OpenPGP pour s’authentifier auprès d’un serveur SSH, comme nous le verrons plus loin) : cela permet de s’assurer que l’agent sera toujours disponible pour les clients SSH (qui ne sont évidemment pas conçus pour lancer un agent GnuPG à la demande).

GnuPG 2.1.x

L’agent de GnuPG 2.1.x utilise toujours une socket standard et peut donc toujours être lancé à la demande sans qu’aucune configuration particulière ne soit nécessaire.

Toutefois, pour les mêmes raisons que ci-dessus, il reste pertinent de forcer le démarrage de l’agent en début de session : pour être sûr que GnuPG 1.x et les programmes SSH soient capables de le trouver quand ils en ont besoin. Pour cela, ajoutez la ligne suivante dans votre fichier ~/.xprofile :

gpg-connect-agent /bye export GPG_AGENT_INFO=$HOME/.gnupg/S.gpg-agent:0:1

La première ligne force le démarrage de l’agent (gpg-connect-agent est un utilitaire permettant de communiquer avec l’agent GnuPG ; comme les autres composants de GnuPG 2.1.0, il lance automatiquement un nouvel agent s’il n’en détecte pas un déjà en cours d’exécution). La deuxième définit la variable GPG_AGENT_INFO au bénéfice de GnuPG 1.x (vous pouvez vous en passer si vous ne prévoyez pas du tout d’utiliser GnuPG 1.x, que ce soit directement ou via un frontend).

Si vous prévoyez d’utiliser l’agent GnuPG comme agent SSH, ajoutez en plus la ligne suivante, au bénéfice des clients SSH :

export SSH_AUTH_SOCK=$HOME/.gnupg/S.gpg-agent.ssh Préparer la carte Changer les PIN

La carte peut vous être fournie soit avec des PIN par défaut, qui sont alors 123456 pour le PW1 et 12345678 pour le PW3, soit avec des PIN personnalisés qui doivent alors vous être communiqués (c’est le cas par exemple si vous obtenez la carte auprès de la Free Software Foundation Europe). Dans tous les cas, vous devriez changer ces PIN au plus tôt.

Insérez la carte dans le lecteur et lancez l’éditeur de carte de GnuPG, qui vous accueille en listant le contenu des principaux DO de la carte :

$ gpg2 --card-edit Application ID ...: D2760001240102000005000012340000 Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: 00001234 Name of cardholder: [not set] Language prefs ...: de Sex ..............: [not set] URL of public key : [not set] Login data .......: [not set] Signature PIN ....: forced Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 0 Signature key ....: [not set] Encryption key ...: [not set] Authentication key: [not set] gpg/card>

(Lorsque vous voudrez juste afficher le contenu de la carte, vous pourrez obtenir la même sortie avec la commande non-interactive gpg2 --card-status.)

Vous êtes alors dans le menu d’édition de carte de GnuPG, signalé par l’invite gpg/card>. Lorsque vous arrivez dans ce menu, la plupart des commandes d’édition ne sont pas immédiatement disponibles, il faut les demander explicitement avec la commande admin :

gpg/card> admin Admin commands are allowed.

Vous pouvez à présent accéder au menu relatif aux différents PIN :

gpg/card> passwd 1 - change PIN 2 - unblock PIN 3 - change Admin PIN 4 - set the Reset Code Q - Quit

Changez successivement le PIN administrateur (option 3 — le PIN administrateur actuel, celui par défaut, vous sera alors demandé), puis le PIN utilisateur (option 1).

Attention

Souvenez‐vous que que la carte impose une longueur minimale pour chaque code PIN. Un code PIN utilisateur de moins de 6 caractères sera refusé, de même qu’un PIN administrateur de moins de 8 caractères. Les longueurs maximales, non définies par la spécification, sont, quant à elles, indiquées par la ligne Max. PIN lengths dans la sortie ci‐dessus (dans l’ordre PIN utilisateur, Reset Code, PIN administrateur).

Modifier les données de la carte

Pendant que vous êtes dans le menu d’édition, vous pouvez remplir les différents champs de données concernant le porteur de la carte (je supposerai par la suite que vous vous appelez Alice, par souci de la tradition) :

gpg/card> name Cardholder's surname: Smith Cardholder's given name: Alice gpg/card> lang Language preferences: fr gpg/card> sex Sex ((M)ale, (F)emale or space): F gpg/card> url URL to retrieve public key: http://example.net/~alice/pgp.asc gpg/card> login Login data (account name): alice

Vous pouvez aussi écrire dans les champs privés avec la commande privatedo, même si celle-ci n’apparaît pas dans le menu de l’éditeur de carte. Par exemple, pour écrire dans le Private DO 1 :

gpg/card> privatedo 1 Private DO data: lorem ipsum dolor sit amet

Même chose à partir d’un fichier :

gpg/card> privatedo 1 < fichier

Quand vous avez modifié ce que vous vouliez, quittez l’éditeur pour revenir à l’invite de commande du shell :

gpg/card> quit Les clefs privées

Avant de pouvoir utiliser la carte pour des opérations cryptographiques, il faut y stocker des clefs privées.

Les clefs peuvent être générées directement sur la carte, auquel cas GnuPG récupère les clefs publiques correspondantes et les importe dans le trousseau public. Attention, dans ce cas la carte contient les seuls exemplaires existants des clefs privées, aucune sauvegarde n’est possible puisque, par conception, on ne peut pas extraire les clefs privées de la carte.

L’autre option consiste à générer les clefs, comme d’habitude, sur son ordinateur, puis à importer les clefs privées sur la carte. Elles sont alors supprimées du trousseau privé et remplacées par des stubs dont la seule fonction est d’indiquer à GnuPG que les vraies clefs privées sont sur une carte à puce.

C’est cette option que nous allons voir à présent — après tout si vous vous êtes procuré une carte OpenPGP, c’est que vous êtes probablement déjà utilisateur de GnuPG et vous avez donc probablement déjà un jeu de clefs.

Dans le reste de ce document, nous utiliserons comme exemple le trousseau suivant :

$ gpg2 --list-keys alice pub 4096R/6FA9FD8B 2014-08-06 [expires: 2017-08-05] uid [ultimate] Alice <alice@example.net> sub 2048R/129E3125 2014-08-06 [expires: 2015-08-06] sub 2048R/E293CCFC 2014-08-06 [expires: 2015-06_06]

Nous avons ici une clef maître RSA de 4096 bits et deux sous-clefs RSA de 2048 bits chacune — une de chiffrement et une de signature, même si cela n’apparaît pas dans ce listing. Seules ces deux sous-clefs sont utilisées quotidiennement, la clef maître ne sert qu’à modifier le jeu de clefs (ajouter ou révoquer des identités ou des sous-clefs) ou pour signer les clefs d’autres utilisateurs.

Créer une sous-clef d’authentification

Nous allons d’abord ajouter une troisième sous-clef RSA de 2048 bits qui servira aux fonctions d’authentification que nous verrons plus loin.

Note

Si vous ne prévoyez pas de faire usage des fonctions d’authentification, vous pouvez passer directement à la section suivante, où nous transférerons toutes les sous-clefs sur la carte. Si vous changez d’avis par la suite, vous pourrez toujours ajouter une sous-clef d’authentification à tout moment.

Lancez l’éditeur de clefs de GnuPG sur votre trousseau (notez l’option --expert dans la ligne de commande ci-dessous : elle vous donne accès aux options avancées de création de clefs) :

$ gpg2 --expert --edit-key alice Secret key is available. pub 4096R/6FA9FD8B created: 2014-08-06 expires: 2017-08-05 usage: CS trust: ultimate validity: ultimate sub 2048R/129E3125 created: 2014-08-06 expires: 2015-08-06 usage: E sub 2048R/E293CCFC created: 2014-08-06 expires: 2015-08-06 usage: S [ultimate] (1). Alice <alice@example.net>

Note

Contrairement au précédent, ce listing fait apparaître les rôles attribuées à chaque clef : E pour le chiffrement (Encrypt), S pour la signature et C pour la signature de clefs (Certify — « signer une clef » revient à certifier qu’elle appartient bien à qui elle prétend appartenir).

gpg> addkey Key is protected You need a passphrase to unlock the secret key for user: "Alice <alice@example.net>" 4096-bit RSA key, ID 6FA9FD8B, created 2014-08-06 Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) Your selection?

Choisissez (8) RSA (set your own capabilities).

Possible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: Sign Encrypt (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection?

Choisissez successivement (S), (E) et (A) pour désactiver les fonctions de signature et de chiffrement et activer la fonction d’authentification, puis (Q) pour quitter ce sous-menu. Le reste de la procédure est classique pour une génération de sous-clef :

RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = keys does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) Key expires at Wed 20 Sep 2017 18:31:56 PM CEST Is this correct? (y/N) Really create? (y/N) We need to generate a lot of random bytes. It is a good idea to perform some other actions (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. pub 4096R/6FA9FD8B created: 2014-08-06 expires: 2017-08-05 usage: CS trust: ultimate validity: ultimate sub 2048R/129E3125 created: 2014-08-06 expires: 2015-08-06 usage: E sub 2048R/E293CCFC created: 2014-08-06 expires: 2015-08-06 usage: S sub 2048R/EC8E794D created: 2014-09-21 expires: 2017-09-20 usage: A [ultimate] (1). Alice <alice@example.net> Transférer les sous-clefs sur la carte

Nous pouvons à présent transférer les trois sous-clefs sur la carte OpenPGP. Notez qu’il est tout-à-fait possible d’y transférer la clef maître (dans le slot réservé à la clef de signature, puisque la clef maître peut généralement signer en plus de pouvoir certifier), mais cet usage est généralement déconseillé.

Note

Si vous ne l’avez pas déjà fait après avoir créé vos clefs, vous devriez envisager de sauvegarder votre trousseau privé actuel avant de procéder au transfert. Souvenez-vous, le transfert des clefs privées sur la carte les supprime du trousseau sur l’ordinateur. Si vous voulez pouvoir restaurer vos sous-clefs en cas de perte de la carte, vous aurez besoin de cette sauvegarde :

$ gpg2 --armor --output my-private-keys.asc --export-secret-key alice

Stockez le fichier résultant dans un endroit sûr, hors-ligne (au même endroit que là où vous avez stocké le certificat de révocation de la clef maître).

Assurez-vous que votre carte est dans le lecteur et relancez l’éditeur de clefs (pas l’éditeur de carte — c’est contre-intuitif mais logique : transférer une clef existante sur une carte est une modification du trousseau) :

$ gpg2 --edit-key alice Secret key is available. pub 4096R/6FA9FD8B created: 2014-08-06 expires: 2017-08-05 usage: CS trust: ultimate validity: ultimate sub 2048R/129E3125 created: 2014-08-06 expires: 2015-08-06 usage: E sub 2048R/E293CCFC created: 2014-08-06 expires: 2015-08-06 usage: S sub 2048R/EC8E794D created: 2014-09-21 expires: 2017-09-20 usage: A [ultimate] (1). Alice <alice@example.net>

Basculez en mode d’affichage des clefs privées :

gpg> toggle sec 4096R/6FA9FD8B created: 2014-08-06 expires: 2017-08-05 ssb 2048R/129E3125 created: 2014-08-06 expires: never ssb 2048R/E293CCFC created: 2014-08-06 expires: never ssb 2048R/EC8E794D created: 2014-09-21 expires: never (1) Alice <alice@example.net>

Sélectionnez la première sous-clef (la clef de chiffrement)…

gpg> key 1 sec 4096R/6FA9FD8B created: 2014-08-06 expires: 2017-08-05 ssb* 2048R/129E3125 created: 2014-08-06 expires: never ssb 2048R/E293CCFC created: 2014-08-06 expires: never ssb 2048R/EC8E794D created: 2014-09-21 expires: never (1) Alice <alice@example.net>

… et envoyez-là vers la carte à puce :

gpg> keytocard Signature key ....: [none] Encryption key ...: [none] Authentication key: [none] Please select where to store the key: (2) Encryption key Your selection?

La première sous-clef n’ayant que la capacité de chiffrer, vous n’avez pas d’autre choix ici que de la stocker dans le slot réservé à la clef de chiffrement.

You need a passphrase to unlock the secret key for user: "Alice <alice@example.net>" 2048-bit RSA key, ID 129E3125, created 2014-08-06

Saisissez comme demandé la phrase de passe qui protège actuellement votre clef privée sur votre disque dur.

sec 4096R/6FA9FD8B created: 2014-08-06 expires: 2017-08-05 ssb* 2048R/129E3125 created: 2014-08-06 expires: never card no: 0005 00001234 ssb 2048R/E293CCFC created: 2014-08-06 expires: never ssb 2048R/EC8E794D created: 2014-09-21 expires: never (1) Alice <alice@example.net>

Notez la mention card no: qui indique que la sous-clef se trouve sur la carte portant le numéro de série 0005 00001234.

Déselectionnez la première sous-clef puis répétez la procédure avec la seconde (la clef de signature) :

gpg> key 1 sec 4096R/6FA9FD8B created: 2014-08-06 expires: 2017-08-05 ssb 2048R/129E3125 created: 2014-08-06 expires: never card no: 0005 00001234 ssb 2048R/E293CCFC created: 2014-08-06 expires: never ssb 2048R/EC8E794D created: 2014-09-21 expires: never (1) Alice <alice@example.net> gpg> key 2 sec 4096R/6FA9FD8B created: 2014-08-06 expires: 2017-08-05 ssb 2048R/129E3125 created: 2014-08-06 expires: never card no: 0005 00001234 ssb* 2048R/E293CCFC created: 2014-08-06 expires: never ssb 2048R/EC8E794D created: 2014-09-21 expires: never (1) Alice <alice@example.net> gpg> keytocard Signature key ....: [none] Encryption key ...: 934E E224 AF04 3996 6264 B4D1 7DAC 67E9 129E 3125 Authentication key: [none] Please select where to store the key: (1) Signature key (3) Authentication key Your selection?

Stockez cette clef dans le slot (1), réservé à la clef de signature. Le slot réservé à la clef d’authentification vous est aussi proposé car une clef capable de signer peut aussi servir à authentifier (l’authentification est un cas particulier de signature, où vous signez un défi posé par celui qui vous demande de vous authentifier).

You need a passphrase to unlock the secret key for user: "Alice <alice@example.net>" 2048-bit RSA key, ID E293CCFC, created 2014-08-06 sec 4096R/6FA9FD8B created: 2014-08-06 expires: 2017-08-05 ssb 2048R/129E3125 created: 2014-08-06 expires: never card no: 0005 00001234 ssb* 2048R/E293CCFC created: 2014-08-06 expires: never card no: 0005 00001234 ssb 2048R/EC8E794D created: 2014-09-21 expires: never (1) Alice <alice@example.net>

Répétez une dernière fois la procédure pour transférer la sous-clef d’authentification dans le slot prévu à cet effet, puis, quittez l’éditeur de clefs en enregistrant vos modifications — sinon les sous-clefs auront bien été transférées sur la carte, mais ne seront pas effacées de votre trousseau privé sur votre disque dur !

Signer ou déchiffrer des messages OpenPGP

Le fait que vos clefs privées soient désormais sur une carte à puce ne change à peu près rien à votre manière d’utiliser GnuPG tous les jours pour signer ou déchiffrer des messages OpenPGP. Et ce, indépendamment du programme que vous utilisez en avant-plan (que ce soit GnuPG directement en ligne de commande, un frontend graphique comme GNU Privacy Assistant, un greffon pour client de messagerie comme Enigmail, etc.).

Au moment de signer ou déchiffrer un message, l’agent GnuPG, au lieu de vous demander la phrase de passe protégeant le trousseau privé, vous demandera d’insérer votre carte dans le lecteur si elle n’y est pas déjà, puis vous demandera le PIN. En arrière-plan, le fonctionnement de GnuPG sera quelque peu différent (puisqu’il devra déléguer une partie du travail à la carte au lieu de le faire lui-même), mais ça ne sera pas visible pour vous (à part un éventuel clignotement de la diode témoin d’activité de votre lecteur de carte).

Le seul changement important réside dans le fait qu’une fois votre PIN saisi une première fois, il ne vous sera plus jamais demandé tant que vous ne retirez pas la carte du lecteur. Inutile d’aller jouer avec l’option --default-cache-ttl de l’agent GnuPG, ce n’est pas lui qui garde votre PIN en cache : c’est la carte OpenPGP elle-même qui reste dans un état « PIN vérifié » tant que la connexion entre la carte et Scdaemon est maintenue.

Pour contraindre ponctuellement la carte à vous redemander le PIN, il faut provoquer une réinitialisation de la connexion, soit en retirant physiquement la carte du lecteur, soit en envoyant une commande SCD RESET à l’agent GnuPG :

$ gpg-connect-agent 'SCD RESET' /bye Le mode « PIN forcé » pour les signatures

La carte peut être configurée pour exiger systématiquement le PIN avant toute opération utilisant la clef de signature, indépendamment du fait que le PIN a déjà été vérifié ou non. C’est le mode forced PIN, dont l’état (enclenché ou non) est visible lorsque GnuPG affiche le contenu de la carte :

$ gpg2 --card-edit […] Signature PIN ....: not forced […]

Ici, la carte est en mode normal, le PIN ne sera exigé que s’il n’a pas encore été vérifié depuis l’insertion de la carte. La commande forcesig permet de basculer entre le mode normal et le mode « PIN forcé » :

gpg/card> forcesig gpg/card> list […] Signature PIN ....: forced […] gpg/card> quit

Cette option ne concerne que les opérations de signature. Pour le déchiffrement ou l’authentification, le PIN ne sera jamais exigé s’il a déjà été vérifié une première fois et que la carte n’a pas été réinitialisée entre-temps.

S’authentifier auprès d’un serveur SSH

Dans ce que j’appelle les « usages avancés » de la carte OpenPGP, l’authentification SSH est probablement l’un des plus intéressants.

Il faut pour cela remplacer l’agent SSH fourni en standard avec OpenSSH (ssh-agent) par l’agent GnuPG. Ajoutez simplement l’option enable-ssh-support dans le fichier de configuration de l’agent GnuPG $GNUPGHOME/gpg-agent.conf. Puis, comme évoqué ci-avant, assurez-vous que ledit agent est bien démarré systématiquement en début de session et que la variable d’environnement SSH_AUTH_SOCK est définie et pointe vers la socket spécialement créée à l’intention des clients SSH.

Note

Si vous utilisiez précédemment ssh-agent, assurez-vous aussi qu’il n’est plus démarré au début de votre session.

L’agent GnuPG s’utilise comme l’agent SSH standard et vous pouvez toujours interagir avec lui avec l’outil classique ssh-add. Vos clefs SSH pré-existantes sont toujours utilisables de la même façon qu’auparavant. Par exemple, pour charger votre clef par défaut (~/.ssh/id_rsa) dans l’agent, procédez comme d’habitude :

Pour utiliser la clef d’authentification que vous avez générée un peu plus tôt et transférée sur votre carte OpenPGP, vous n’avez rien d’autre à faire que d’insérer la carte dans le lecteur : l’agent GnuPG détectera automatiquement la présence d’une clef d’authentification et la rendra accessible aux clients SSH. Vous pouvez le vérifier en demandant à l’agent de lister les « identités » disponibles :

$ ssh-add -l 2048 77:e5:34:2f:8d:1c:7a:de:89:b5:13:a2:f1:2c:77:bf cardno:000500001234 (RSA)

Il ne vous reste plus qu’à exporter votre clef publique sous une forme utilisable dans un fichier ~/.ssh/authorized_keys, ce que vous pouvez faire soit avec ssh-add encore (seulement quand la carte est dans le lecteur) :

$ ssh-add -L ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDWuoVgdIK8pmN5DJl5kymyI+em+uIfzPCuls7DVOfd C2oz0sXkuvdqMvIGmUW80uRFWetdXO2ltF78dABPjUGtfXUdjjsD6WEuP6j0JeH2w2l2j7f3icwDVmNN OdwwE6sFmW0YgNNPRr5leGaoA9OMo5klF5BTyn2iFCgK0QV3zL1pk7E3x8oSA0COC2Jn0P5Pc2foEqSn Dtaq+KTJKA3Sng5R+khWL6Ux5/F7VKPOzIBaJm+wQ16LW4pitVbPMYxrNWO44X+2GpJ6IXBw/ixZK8rE qysSPJz7jfUZ8HPJvAnnEwHWOpYfksZU/dXTnQ4C2btpMDZeoQsnRnxTx4Mh cardno:000500001234

Soit avec l’outil (non-documenté) gpgkey2ssh, qui prend en paramètre
l’identifiant de la sous-clef d’authentification :

$ gpgkey2ssh EC8E794D ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDWuoVgdIK8pmN5DJl5kymyI+em+uIfzPCuls7DVOfd C2oz0sXkuvdqMvIGmUW80uRFWetdXO2ltF78dABPjUGtfXUdjjsD6WEuP6j0JeH2w2l2j7f3icwDVmNN OdwwE6sFmW0YgNNPRr5leGaoA9OMo5klF5BTyn2iFCgK0QV3zL1pk7E3x8oSA0COC2Jn0P5Pc2foEqSn Dtaq+KTJKA3Sng5R+khWL6Ux5/F7VKPOzIBaJm+wQ16LW4pitVbPMYxrNWO44X+2GpJ6IXBw/ixZK8rE qysSPJz7jfUZ8HPJvAnnEwHWOpYfksZU/dXTnQ4C2btpMDZeoQsnRnxTx4Mh COMMENT

Une fois la clef publique connue du serveur, vous pouvez vous y connecter comme d’habitude, avec n’importe quelle commande SSH (ssh, scp, etc.) ou n’importe quel programme utilisant SSH en arrière-plan (git push par exemple). L’agent GnuPG vous demandera votre PIN si nécessaire ; s’il a déjà été vérifié plus tôt, vous serez automatiquement connecté sans avoir à saisir quoi que ce soit.

Note

Remarquez que du point de vue du serveur SSH, il ne se passe rien de spécial. Tout ce qu’il voit est une banale authentification par clef — le fait que la partie privée de la clef soit, côté client, stockée sur une carte à puce, est indifférent pour le serveur. Tout ce qui lui importe est que la partie publique figure dans la liste des clefs autorisées.

Utiliser un certificat X.509

À partir de chacune des clefs privées de la carte OpenPGP, il est possible de créer un certificat X.509. Un tel certificat permet d’utiliser la carte pour, entre autres usages, s’authentifier auprès d’un serveur TLS, signer ou chiffrer des messages S/MIME, ou encore signer des documents OpenDocument.

Créer un certificat X.509

GnuPG 2.x fournit l’outil gpgsm pour créer, manipuler et utiliser des certificats X.509. Mettez votre carte dans le lecteur et appelez gpgsm pour créer une nouvelle demande de certificat :

$ gpgsm --armor --output certificat.csr --gen-key Please select what kind of key you want: (1) RSA (2) Existing key (3) Existing key from card Your selection? Serial number of the card: D2760001240102000005000012340000 Available keys: (1) 39820691E60A775AF9B979F4A960B23A2FC8892A OPENPGP.1 (2) BE3918CCCC237E42AF6D15869DCAE291276C5548 OPENPGP.2 (3) 386F81432E2C864085885251EB5D6D0B875D1E91 OPENPGP.3 Your selection?

Les empreintes affichées ici ne correspondent pas aux empreintes traditionnelles de GnuPG (celles que gpg2 affiche avec l’option --fingerprint) : ce sont des keygrips. Un keygrip est calculé sur une clef « brute » et permet donc d’identifier une clef indépendamment du format du certificat qui la contient — un certificat OpenPGP et un certificat X.509 utilisant la même clef auront deux empreintes différentes, mais le même keygrip.

Malheureusement, avec GnuPG 2.0.x, il n’y a aucun moyen simple à ma connaissance d’obtenir le keygrip d’une clef OpenPGP et donc de savoir à quelle clef correspondent chacun des keygrips ci-dessus (GnuPG 2.1 a une option --with-keygrip pour ça). À la place, vous devez vous référer aux noms des slots de la carte OpenPGP, sachant que le premier (OPENPGP.1) correspond à la clef de signature, le second à la clef de chiffrement et le troisième à la clef d’authentification.

Le choix de la clef conditionnera les usages possibles du futur certificat : il sera utilisable seulement pour signer avec la clef OPENPGP.1, seulement pour chiffrer avec la clef OPENPGP.2, pour signer et s’authentifier avec la clef OPENPGP.3. Il n’est pas possible d’utiliser la carte pour produire un certificat utilisable à la fois pour signer/authentifier et pour chiffrer.

Dans cet exemple, nous choisirons la troisième clef pour obtenir un certificat utilisable pour la signature et l’authentification.

Possible actions for a RSA key: (1) sign, encrypt (2) sign (3) encrypt Your selection?

La clef d’authentification ne permet pas de chiffrer, donc la seule option pertinente ici est la seconde, (2) sign. Ce menu ne sert qu’à déterminer la valeur de l’extension X509v3 Key Usage de la demande de certificat — même si vous choisissez (1) sign, encrypt, ça ne changera rien au fait que la clef sous-jacente ne permet pas de chiffrer, même si le certificat proclamera le contraire.

Vous devez ensuite renseigner le sujet du futur certificat :

Enter the X.509 subject name: CN=alice,O=Example Corp,DC=example,DC=net Enter email addresses (end with an empty line): alice@example.net Enter DNS names (optional; end with an empty line): Enter URIs (optional; end with an empty line): Parameters to be used for the certificate request: Key-Type: card:OPENPGP.3 Key-Length: 1024 Key-Usage: sign Name-DN: CN=Alice,O=Example Corp,DC=example,DC=net Name-Email: alice@example.net Really create request? (y/N) Now creating certificate request. This may take a while ... gpgsm: about to sign CSR for key: &386F81432E2C864085885251EB5D6D0B875D1E91 gpgsm: certificate request created Ready. You should now send this request to your CA.

Vous récupérez la demande de certificat dans le fichier certificat.csr. Vous pouvez si vous le souhaitez l’examiner avec, par exemple, openssl req -in -text.

Il vous faut maintenant faire signer cette demande par une autorité de certification. Le choix de l’autorité de certification à laquelle vous adresser dépend grandement de l’usage que vous voulez faire du certificat. Il peut s’agir d’une autorité générique « reconnue » (probablement le meilleur choix pour signer des messages S/MIME à destination de n’importe qui, puisque tout le monde fait confiance — à tort ou à raison — à ces autorités), d’une autorité spécifique à votre institution ou à votre compagnie (pour signer des messages internes à cette institution ou compagnie), ou même de votre propre autorité (par exemple pour vous authentifier auprès de votre propre serveur TLS).

Une fois en possession de votre certificat signé, importez-le dans le trousseau de gpgsm :

$ gpgsm --import certificat.crt

Vous devriez aussi importer le certificat racine de l’autorité qui l’a signé, ainsi que les éventuels certificats intermédiaires. Finalement, testez votre nouveau certificat en signant un fichier quelconque :

$ gpgsm --output quelconque.signed --sign quelconque gpgsm: signature created $ gpgsm --verify quelconque.signed gpgsm: Signature made 2014-12-01 12:11:32 using certificate ID 0xAB4057B0 gpgsm: Good signature from "/CN=Alice/O=Example Corp/DC=example/DC=net" gpgsm: aka "alice@example.net" S’authentifier auprès d’un serveur web

Je supposerai ici que vous voulez accéder à un serveur web qui exige une authentification du client par certificat et que vous souhaitez utiliser, pour cela, le certificat fraîchement obtenu ci-dessus.

Je ne traiterai pas de la mise en place de l’authentification côté serveur, qui sort du cadre de ce document (et qui est de toute façon assez bien documentée ailleurs). Je me contenterai de rappeler que les deux lignes suivantes, dans la configuration d’un serveur Apache httpd 2.2.x, obligent un client à présenter un certificat signé par la clef privé du certificat /etc/ssl/certs/client_ca.pem pour être autorisé à accéder au serveur :

SSLCACertificateFile /etc/ssl/certs/client_ca.pem SSLVerifyClient require

En ces temps où les mots de passe sont de plus en plus mis à mal, l’authentification par certificat (avec ou sans carte à puce) est une méthode de contrôle d’accès très intéressante et probablement trop peu utilisée. Combinée avec l’option FakeBasicAuth du module mod_ssl, elle peut remplacer complètement l’authentification par login et mot de passe.

Similairement à ce que nous avons vu plus haut pour SSH, le serveur est indifférent au fait que le certificat que vous allez lui présenter a sa clef privée sur une carte à puce, il ne voit qu’un certificat X.509 comme un autre. C’est du côté du client que les choses intéressantes se passent.

Côté client, donc, vous devez avoir fait signer votre requête de certificat par l’autorité appropriée et avoir importé le certificat signé dans le trousseau de gpgsm. Ensuite, il vous faut installer Scute et configurer Firefox pour qu’il charge dynamiquement cette bibliothèque (la procédure complète, captures d’écrans à l’appui, est détaillée dans la documentation de Scute).

Note

En principe, Scute devrait aussi être utilisable par n’importe quelle application capable d’utiliser un module PKCS #11 (Chromium par exemple). Mais je n’ai testé que Firefox, LibreOffice et Thunderbird (voir plus bas).

Sitôt la carte OpenPGP insérée dans le lecteur, Scute rendra votre certificat disponible pour Firefox — vous pourrez le vérifier en allant constater sa présence dans le Certificate Manager de Firefox. En vous connectant au serveur exigeant un certificat client, Firefox sélectionnera automatiquement ce certificat3 et vous serez invité à saisir votre PIN (si nécessaire) pour signer une partie de la poignée de main TLS, prouvant ainsi au serveur que vous possédez la clef privée du certificat.

Attention

Actuellement, Scute (version 1.4.0) ne fonctionne pas avec TLS 1.2, dont la prise en charge a récemment été introduite dans Firefox à partir de sa version 27. En effet, TLS 1.2 a changé, entre autres choses, la nature du message digest que le client est supposé signer avec sa clef privée : avec TLS <= 1.1, c’était systématiquement un double condensat MD5 et SHA-1 ; avec TLS 1.2, c’est maintenant un condensat variable (SHA-1 ou SHA-256, le plus souvent) enveloppé dans une structure ASN.1. Ce changement a cassé le code au sein de Scute chargé de relayer le message digest à la carte OpenPGP.

Malheureusement, le seul contournement aisé pour l’instant est de… désactiver TLS 1.2, ce qui se fait en réglant la variable security.tls.version.max à 2 dans about:config.

Pour ceux qui sont prêts à mettre un peu les mains dans le cambouis, Werner Koch a proposé un patch contre Scute 1.4.0 apportant la prise des message digests utilisés par TLS 1.2. Si vous utilisez GnuPG 2.0.26, ce n’est toutefois pas suffisant, il faut aussi appliquer un patch de votre serviteur

Par ailleurs, si vous utilisez GnuPG 2.1.0, cette version a révélé un bug de Scute qui conduit l’authentification à échouer dans certaines occasions. J’ai proposé un second patch contre Scute (à appliquer en plus de celui de Werner Koch) qui semble corriger le problème.

La prudence s’impose bien sûr avant d’appliquer ces correctifs. On ne patche pas des programmes ou bibliothèques cryptographiques à la légère (il y en a chez Debian qui ont essayé…).

Signer des documents OpenDocument

Si vous avez installé Scute et configuré Firefox pour l’utiliser comme expliqué dans la section précédente, vous pouvez également utiliser votre certificat X.509 pour apposer une signature électronique à vos documents OpenDocument depuis LibreOffice.

Il suffit pour cela de définir la variable d’environnement MOZILLA_CERTIFICATE_FOLDER et de la faire pointer vers le dossier de votre profil Firefox :

export MOZILLA_CERTIFICATE_FOLDER=~/.mozilla/firefox/nom_du_profil

Dès lors, LibreOffice peut utiliser tous les certificats présents dans le Certificate Manager de Firefox, y compris celui que vous avez généré à partir de votre carte OpenPGP.

Pour signer un document, rien de plus simple : insérez votre carte dans le lecteur et dans LibreOffice, allez dans File → Digital Signatures). Choisissez Sign Document…, sélectionnez votre certificat, entrez votre PIN, si nécessaire.

Signer des messages S/MIME

S/MIME (RFC 3851) est, avec OpenPGP, l’autre standard proposant la confidentialité et l’authentification « de bout en bout » des messages.

Thunderbird prend en charge nativement S/MIME, mais ne permet pas l’utilisation d’une clef privée sur carte à puce. Comme pour Firefox, c’est la bibliothèque Scute qui va lui apporter cette fonctionnalité.

Note

Scute ne permet la signature de messages S/MIME que si les patches évoqués plus haut sont appliqués.

Installez Scute sous Thunderbird de la même manière que sous Firefox (dans les préférences, allez dans la section Advanced, onglet Certificates, Security Devices ; dans le « Device Manager », ajoutez un nouveau module PKCS #11 et spécifiez le chemin complet vers la bibliothèque libscute.so). Une fois la carte dans le lecteur, votre certificat devrait apparaître dans l’onglet Your Certificates du « Certificate Manager ».

Dans les paramètres de votre compte de messagerie, visitez la section Security (attention à ne pas confondre avec la section OpenPGP Security, présente si vous utilisez Enigmail et qui, comme son nom l’indique, concerne OpenPGP et non S/MIME) et sélectionnez votre certificat X.509 pour signer vos messages. Cochez éventuellement la case « Digitally sign messages (by default) », si vous souhaitez systématiquement signer vos messages sortant (ce réglage est toujours ponctuellement désactivable au cas par cas).

Votre certificat X.509 est également utilisable à partir de Mutt, à condition que ce dernier utilise la bibliothèque gpgme (GnuPG Made Easy) en lieu et place d’OpenSSL, comme backend cryptographique (en ajoutant l’option set crypt_use_gpgme dans le fichier de configuration de Mutt). Par l’intermédiaire de cette bibliothèque, Mutt déléguera les opérations de signature S/MIME à gpgsm qui, à son tour, fera appel à la carte OpenPGP.

Utiliser la carte comme token PKCS #15

Dans tous les cas d’utilisation du certificat X.509 présentés ci-dessus, la carte OpenPGP ne contient rien d’autre que la clef privée associée au certificat. Le certificat proprement dit est stocké dans le trousseau de GpgSM, où les applications doivent aller le chercher soit en appelant directement gpgsm, soit par l’intermédiaire de Scute.

Il est toutefois possible de stocker le certificat sur la carte OpenPGP elle-même, ce qui le rend utilisable indépendamment de GpgSM. En fait, cela transforme de facto la carte en un token PKCS #15, utilisable avec n’importe quel système ou application compatible avec ce format.

Le certificat doit être au format DER pour pouvoir être importé sur la carte. Si vous l’aviez rangé dans le trousseau de GpgSM, la commande suivante le sortira directement dans ce format :

$ gpgsm -o alice.der --export alice@example.net

Si votre autorité de certification vous a remis un certificat au format PEM, vous pouvez utiliser OpenSSL (par exemple) pour le convertir en DER :

$ openssl x509 -inform PEM -in alice.pem -outform DER -out alice.der

Lancez l’éditeur de carte de GnuPG pour procéder au transfert du certificat sur la carte. Notez que la commande writecert n’apparaît pas dans l’aide en ligne de l’éditeur.

$ gpg2 --card-edit Application ID ...: D27600012301020000005000012340000 […] gpg/card> admon Admin commands are allowed gpg/card> writecert 3 < alice.der gpg/card> quit

Note

Le premier argument de writecert est supposé indiquer le slot sur la carte dans lequel enregistrer le certificat. Toutefois, la carte OpenPGP ne possède qu’un seul slot pour certificat, et cet argument doit toujours être 3.

Votre carte OpenPGP PKCS #15 est désormais utilisable de manière autonome et ne requiert plus la présence des composants de GnuPG sur la machine. Toute application prenant en charge PKCS #15 (par exemple par l’intermédiaire d’OpenSC) peut exploiter la carte.

Attention

L’utilisation simultanée de la carte avec GnuPG et comme token PKCS #15 est impossible. En effet, Scdaemon requiert un accès exclusif à la carte, interdisant son utilisation par d’autres programmes comme OpenSC. C’est d’ailleurs la raison d’être de Scute : permettre à des programmes indépendants de GnuPG d’accèder à la carte via une interface standard (PKCS #11) fonctionnant au-dessus de Scdaemon, et laisser ce dernier être le seul à exploiter la carte directement.

Miscellanées Communiquer avec Scdaemon et la carte

Scdaemon, le démon auxiliaire de GnuPG 2.x gérant les cartes à puce, travaille normalement dans l’ombre des autres composants de GnuPG et l’utilisateur n’a jamais affaire à lui.

Il est néanmoins possible de dialoguer avec Scdaemon indépendamment des frontend de GnuPG. Cela peut occasionnellement être utile à des fins de débogage, pour d’éventuels usages avancés non prévus par les frontend, ou simplement par curiosité, pour comprendre ce qui se passe en arrière-plan.

Comme l’agent GnuPG, Scdaemon écoute sur une socket Unix et utilise le protocole Assuan pour recevoir ses commandes.

Avec GnuPG 2.1.0, la socket de Scdaemon est constante et fixée à $GNUPGHOME/S.scdaemon. On peut ainsi contacter le démon de la manière suivante :

$ echo SERIALNO | socat - unix-connect:/home/alice/.gnupg/S.scdaemon OK GNU Privacy Guard's Smartcard server ready S SERIALNO D276000240102000005000012340000 0 OK

(La commande SERIALNO demande à Scdaemon le numéro de la série de la carte OpenPGP actuellement insérée dans le lecteur.)

Mais il est probablement plus simple de passer par l’agent GnuPG (et son utilitaire gpg-connect-agent), qui fournit une commande SCD pour transmettre des commandes à Scdaemon. Cela permet de contacter Scdaemon sans avoir à se soucier de l’emplacement de sa socket :

$ gpg-connect-agent 'SCD SERIALNO' /bye S SERIALNO D276000240102000005000012340000 0 OK

Une fois qu’on sait communiquer avec Scdaemon, on peut obtenir la liste des commandes acceptées avec la commande HELP, et l’aide d’une commande particulière avec HELP commande :

$ gpg-connect-agent > SCD HELP […] # SERIALNO [<apptype>] # LEARN [--force] [--keypairinfo] # READCERT <hexified_certid>|<keyid> # READKEY <keyid> # SETDATA [--append] <hexstring> # PKSIGN [--hash=[rmd160|sha{1,224,256,384,512}|md5]] <hexified_id< # PKAUTH <hexified_id> # PKDECRYPT <hexified_id> # INPUT # OUTPUT # GETATTR <name> # SETATTR <name> <value> # WRITECERT <hexified_certid> # WRITEKEY [--force] <keyid> # GENKEY [--force] [--timestamp=<isodate>] <no> # RANDOM <nbytes> # PASSWD [--reset] [--nullpin] <chvno> # CHECKPIN <idstr> # LOCK [--wait] # UNLOCK # GETINFO <what> # RESTART # DISCONNECT # APDU [--[dump-]attr] [--more] [--exlen[=N]] [hexstring] # KILLSCD OK > SCD HELP READKEY # READKEY <keyid> # # Return the public key for given cert or key ID as a standard # S-expression. # # Note, that this function may even be used on a locked card. OK > /bye

Pour les plus aventureux, la commande probablement la plus intéressante est ADPU, qui permet d’envoyer des commandes APDU brutes à la carte (rapportez-vous à la spécification de la carte OpenPGP pour le détail des commandes APDU). Par exemple, pour lire les « octets historiques » de la carte :

$ gpg-connect-agent --hex 'SCD APDU 00CA5F5200' /bye D[0000] 00 31 C5 73 C0 01 40 05 90 00 90 00 .1.s..@..... OK Ré-initialiser une carte bloquée

Comme expliqué dans la section « Sécurité », après trois saisies erronées consécutives du PIN utilisateur et du PIN administrateur, plus aucun PIN ne peut être vérifié et la carte est définitivement bloquée.

La version 2.0 de la carte OpenPGP prévoit toutefois la possibilité de ré-initialiser une carte bloquée. La ré-initialisation efface toutes les données de la carte et la ramène à son état de sortie d’usine.

Cette fonctionnalité est optionnelle. Pour savoir si une carte donnée est ré-initialisable, il faut consulter les « octets historiques » comme dans l’exemple à la fin de la section précédente :

$ gpg-connect-agent --hex 'SCD APDU 00CA5F5200' /bye D[0000] 00 31 C5 73 C0 01 40 05 90 00 90 00 .1.s..@..... OK

Le huitième octet (05) est le « Life Cycle Status indicator ». Une valeur de 5 indique que la carte peut être ré-initialisée.

Pour ré-initialiser une telle carte, il faut lui envoyer successivement les deux commandes APDU « TERMINATE DF » et « ACTIVATE FILE », comme suit :

$ gpg-connect-agent > SCD APDU 00 E6 00 00 > SCD APDU 00 44 00 00 /bye

Pour éviter toute erreur malheureuse, la commande « ACTIVATE FILE » ne fonctionne que si elle est utilisée après la commande « TERMINATE DF », et cette dernière n’a elle-même pas d’effet si la carte n’est pas bloquée.

Pour forcer la ré-initialisation de la carte quel que soit son état actuel (bloqué ou non), on peut utiliser le script suivant (ou la commande factory reset de l’éditeur de carte de GnuPG, dans sa dernière version 2.1.1) :

SCD RESET SCD SERIALNO undefined SCD APDU 00 A4 04 00 06 D2 76 00 01 24 01 SCD APDU 00 20 00 81 08 40 40 40 40 40 40 40 40 SCD APDU 00 20 00 81 08 40 40 40 40 40 40 40 40 SCD APDU 00 20 00 81 08 40 40 40 40 40 40 40 40 SCD APDU 00 20 00 81 08 40 40 40 40 40 40 40 40 SCD APDU 00 20 00 83 08 40 40 40 40 40 40 40 40 SCD APDU 00 20 00 83 08 40 40 40 40 40 40 40 40 SCD APDU 00 20 00 83 08 40 40 40 40 40 40 40 40 SCD APDU 00 20 00 83 08 40 40 40 40 40 40 40 40 SCD APDU 00 e6 00 00 SCD RESET SCD SERIALNO undefined SCD APDU 00 A4 04 00 06 D2 76 00 01 24 01 SCD APDU 00 44 00 00 /echo Card has been reset to factory defaults /bye

Stockez ces commandes dans un fichier et envoyez le tout à la carte via l’agent GnuPG :

$ gpg-connect-agent --hex --run fichier

Attention

Rappelez-vous que la ré-initialisation est une fonctionnalité optionnelle. N’exécutez surtout pas la commande précédente sans avoir vérifié que votre carte est ré-initialisable ! Si elle ne l’est pas, votre carte sera bel et bien définitivement bloquée.

1. La carte n’est jamais utilisée pour chiffrer, puisqu’en cryptographie asymétrique, seul le déchiffrement nécessite une clef privée — le chiffrement utilise la clef publique du destinataire. ↩

2. Commentaire en tête du fichier scd/ccid-driver.c, dans les sources de GnuPG. ↩

3. À moins que vous ayez plus d’un certificat signé par l’autorité attendue par le serveur, auquel cas il vous demandera de sélectionner vous-même celui qu’il faut utiliser. ↩

Télécharger ce contenu au format Epub

Lire les commentaires

La sortie de la version stable 3.18 du noyau Linux a été annoncée le lundi 7 décembre 2014 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org. Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche.

• lien n°1 : Les noyaux précédents
• lien n°2 : Site officiel du noyau Linux
• lien n°3 : LWN : 3.18 Merge window part 1
• lien n°4 : LWN : 3.18 Merge window part 2
• lien n°5 : LWN : 3.18 Merge window part 3
• lien n°6 : Heise : Die Neuerungen von Linux 3.18
• lien n°7 : Kernel Newbies : Linux 3.18

Sommaire

• En bref
• Annonces des RC par Linus Torvalds
  • RC-1
  • RC-2
  • RC-3
  • RC-4
  • RC-5
  • RC-6
  • RC-7
  • Version finale
• Les nouveautés
  • Architecture
    • Prise en charge des nouvelles puces ARM
    • ACPI et gestion d’énergie
    • Gestion du bus PCI sur les processeurs ARM 64 bits
    • Mise en veille et réveil plus rapide
    • Architecture SPARC64
  • Développeurs
    • Mailbox
    • Correction de l’appel système fanotify_init()
    • Quelques fonctions variables par processeur marquées obsolètes
    • LLVM
    • Vidage mémoire des périphériques
    • Modules compressés
    • Paramètres de modules non sûrs
    • Résolveur de références au sein du device tree
    • Miniaturisation
    • Temps réel
  • Pilotes graphiques libres
    • DRM (Direct Rendering Manager)
    • AMD/ATI (pilote Radeon)
    • Intel (pilote i915)
    • NVIDIA (pilote Nouveau)
    • En vrac
  • Réseau
    • Transmission de paquets réseau en masse
    • Berkeley Packet Filter
    • Foo-over-UDP
    • DCTCP congestion control algorithm
    • Generic Network Virtualization Encapsulation (Geneve) protocol
  • Sécurité
    • Cryptographie
    • LSM
      • IMA & EVM
      • SELinux
      • SMACK
    • Trousseaux de clés
    • Liste non exhaustive des vulnérabilités corrigées
  • Systèmes de fichiers
    • F2FS
    • OverlayFS
    • NFS
    • Ceph
  • Virtualisation
    • KVM
    • Xen
• Le bilan en chiffres
• Appel à volontaires

En bref

• Architecture
  • Mise en veille plus rapide (100 ms par cœur)
• Développeurs
  • Amélioration de la gestion du compilateur Clang
  • Gestion des modules compressés
• Pilotes graphiques libres
  • DRM : unification des barrières TTM
  • ATI/AMD : meilleure gestion d’énergie
  • Nouveau : gestion du son avec les connexions DisplayPort ; amélioration du recadencement
• Réseau
  • Amélioration des performances réseau
  • Nouvel appel système : bpf()
  • Mise en place de tunnels génériques : Foo-over-udp
• Systèmes de fichiers
  • Ajout d’un nouveau système de fichiers : OverlayFS intégré
• Virtualisation
  • KVM améliore la gestion de l’imbrication de machines virtuelles, ainsi que la prise en charge de l’hyperviseur Jailhouse pour les processeurs AMD
  • Xen se prépare à XenServer 4.5

Annonces des RC par Linus Torvalds RC-1

La version RC-1 est sortie le 19 octobre 2014 :

Quand j’avais publié la version 3.17, j’avais dit que j’étendrais la phase d’intégration à trois semaines en raison de déplacements. J’ai clairement menti. Parce que nous voilà, après les deux semaines habituelles, et j’ai déjà sorti la 3.18-RC1.

Ce qui s’est passé, c’est que non seulement j’ai activement intégré malgré les voyages — j’ai été privé de communication seulement pendant quelques jours (en grande partie, mais pas seulement, à cause des vols ; l’hôtel à Düsseldorf a aussi été privé d’Internet pendant un jour) —, mais, sans doute plus important, les gens semblent avoir massivement envoyé leurs demandes d’intégration, parce que la RC-1 en contient plus que linux-next n’en a produit les quelques jours après le 3.17… Donc, la retenir une semaine de plus semble inutile.

Cela dit, je me rends compte que les gens auraient très bien pu prendre mes déclarations au pied de la lettre, et prévoir en fonction. Je déteste quand je reçois des demandes en toute fin de la phase d’intégration, mais en l’ayant fermée selon le calendrier habituel, je comprends aussi que l’on ait pu prévoir d’envoyer des demandes d’intégration un peu plus tard. Ça va. Prosternez‐vous un peu et expliquez‐moi ce qui se passe, et vous pourrez presque à coup sûr me rendre coupable de certains trucs.

Aussi, ai‐je peut‐être tout simplement raté quelque chose en raison du décalage horaire (hum… oui, appelons ça « décalage horaire », ça sonne tellement mieux que « incompétence de base et mauvaise planification »), donc, si vous vous sentez injustement négligé, envoyez‐moi un courriel pour expliquer pourquoi je vous ai injustement lésé.

Il y a également au moins une demande d’intégration que j’ai l’espoir d’obtenir le plus vite possible et que je prévois toujours de récupérer : j’espère toujours ardemment voir overlayfs enfin intégré. Mais il y avait quelques questions de dernière minute d’Al. En supposant que tout fonctionne bien, c’est une intégration tardive prévue. Pas la peine de retarder la sortie de la RC-1 pour un traînard connu, cependant.

Donc, là vous l’avez. La fenêtre d’intégration est close, mais avec un espace [room] pour des excuses et les possibles demandes d’intégration oubliées. Comme d’habitude, le résumé des rapports de modifications est beaucoup trop long pour être posté (statistiques de base : en gros 74 % de pilotes, 10 % de mises à jour d’architecture ; le reste étant : du réseau, les systèmes de fichiers, le cœur du noyau , la documentation, les fichiers d’en‐têtes, des mise à jour des outils…), et la suite est mon « journal d’intégration » qui, comme d’habitude, mentionne ceux qui m’ont fait des remontées, qui ne sont pas nécessairement les mêmes que les gens qui ont écrit le code.

En avant, testez,

Linus

RC-2

La version RC-2 est sortie le 26 octobre 2014 :

Nouvelle semaine, nouvelle RC, et maintenant la phase d’intégration est définitivement fermée.
J’avais espéré que la sortie de la RC-1 signifierait que quelques traînards feraient rapidement surface, et que le reste de la RC serait plus normale. Mais non, j’ai eu le droit toute la semaine à des demandes d’intégration en pagaille et la RC-2 a été plus longue que je l’aurais voulu.
Tant pis. Ce n’est pas que je sois vraiment surpris, mais ça veut dire que je vais probablement être désagréable la semaine prochaine envers quiconque essaiera de me soumettre des choses dont je penserai qu’elles ressemblent plus à du « développement » plutôt qu’à des « correctifs ». Vous aurez été prévenus. Je vous ai en effet donné trois semaines complètes pour l’intégration, c’est maintenant le moment de la correction des bogues, et d’un autre brouhaha. D’accord ?

Et, pour être honnête, nous avons eu de plus longues RC-2 historiquement. Pas récemment, toutefois. Les 3.3 et 3.4 avaient toutes deux de grosses RC-2, et la 3.15 (qui était la plus grosse jamais vue, si j’ai bonne mémoire) s’en approchait.
Au moins une partie provient de l’intégration très longtemps retardée d’overlayfs, que j’ai déjà mentionné dans le message de publication de la RC-1 comme étant en attente. Voyons quelles sont toutes les retombées que tout cela génère, mais ça aura duré longtemps (entre autres, parce qu’il avait besoin de différentes choses dans les couches VFS pour être intégré proprement), et je pense que c’est en bonne voie. Touchons du bois.

Donc, au moins en partie en raison de l’intégration d’overlayfs, près du tiers du correctif est du système de fichiers. Mais ce n’est pas dû qu’à overlayfs, cependant ; il y avait une demande d’intégration tardive pour ext4 qui, je pense, est en fait plus grosse, en partie à cause d’un ré‐usinage de code.

Le reste correspond à des mises à jour de pilotes plus usuelles (thermique, watchdog, cible SCSI, ACPI & gestion de l’alimentation, mises à jour diverses) et des mises à jour d’architectures (ARC, BRAS, PowerPC, MIPS, x86). Un peu de documentation et des mises à jour de fichiers en‐têtes viennent compléter le reste.

Le résumé ci‐joint pour les détails, je crois qu’il respecte toujours les contraintes de taille de la liste de diffusion.

Linus

RC-3

La version RC-3 est sortie le 2 novembre 2014 :

Une autre semaine, une autre RC, et les choses ne s’affinent pas vraiment de la manière que j’aurais espérée…

Bien que le correctif lui‐même soit beaucoup plus petit que ne l’était la RC-2 (pas de nouveau système de fichiers dans cette RC !), il y a en fait plus de modifications et plus de fichiers concernés. Il y en a partout, en plus.

Cela dit, je ne pense pas qu’il y ait quoi que ce soit de particulièrement horrible ici. Beaucoup, beaucoup, de petits trucs, avec des pilotes qui représentent la majorité de ce vrac (à la fois en termes de nombre de modifications et de lignes de code), mais le réseau et le cœur du noyau sont également présents dedans. Rien de particulier ne se démarque.

Le résumé des rapports de modifications ci‐joint pour plus de détails, s’il vous plaît, allez le tester.

Linus

RC-4

La version RC-4 est sortie le 9 novembre 2014 :

Eh, finalement, les choses se calment. En fait, ça avait vraiment l’air calme jusqu’à hier, au moment où certaines personnes ont soudain réalisé : « Eh, je pourrais envoyer mes trucs à Linus pour qu’il les mette dans la RC-4 ». Du coup, un tiers de tous les changements est arrivé le dernier jour, mais malgré cela, les choses semblent enfin se mettre en place, et nous parviendrons à la stabiliser en fin de compte.
En espérant que la tendance se maintienne…

Les choses semblent assez habituelles. Un peu plus de la moitié concerne des pilotes, et près d’un tiers sont des correctifs d’architectures (ARM, MIPS, PowerPC et s390). Le reste est constitué de quelques mises à jour de systèmes de fichiers (principalement XFS) et des trucs divers.

Le résumé du journal des modifications permet de se faire une bonne idée des détails, et rien ne semble particulièrement effrayant ni étrange.

Linus

RC-5

La version RC-5 est sortie le 16 novembre 2014 :

Hum. Nous avons eu une RC-4 très calme, et j’aurais aimé pouvoir dire que les choses ont continué à se calmer, mais… Ouais, la RC-5 est nettement plus grande que la RC-4. Tant pis.

Ce n’est pas comme si ça dépassait les bornes, même si la RC-4 était vraiment petite. Et les changements ne sont pas particulièrement étranges ni effrayants : environ 55 % de pilotes (réseau, pilotes graphiques, crypto, thermique, son), 15 % pour l’architecture (Xtensa, x86, ARM[64], PA-RISC, SPARC), et le reste est principalement un mélange de mises à jour du réseau, des systèmes de fichiers, des machines virtuelles, de la documentation et du traçage.

Les modifications tendent à être assez petites et explicites, et environ un tiers d’entre elles sont déclarées stables. Donc, nous avons encore quelques questions en suspens, mais les choses semblent assez normales. Il nous reste encore quelques semaines avant le final, et plus vous pourrez tester, mieux ce sera.

Linus

RC-6

La version RC-6 est sortie le 23 novembre 2014 :

Des progrès constants nous amènent vers la version finale, même si nous avons encore un gros souci non élucidé dans une régression que Dave Jones a signalée et que nous n’avons pas encore résolu. Dans notre processus de traque, on a regardé un bon paquet de détails divers de bas niveau et cela a révélé quelques points litigieux, mais encore aucune preuve irréfutable. Mais cela explique certains des correctifs de la RC-6…

La bonne nouvelle est que les choses se calment dans l’ensemble, et la plupart des modifications sont ici des corrections d’assez petites régressions, avec une poignée de correctifs stables. Près de la moitié de pilotes (réseau, son, PCI, InfiniBand, etc.), avec des mises à jour d’architectures (x86, MPIPS, ARM), et le code réseau représentant environ la moitié du reste. Et le dernier quart est « divers » : corrections de systèmes de fichiers, documentation, ordonnanceur…

Il y a assez peu de code qui a changé, et s’il n’y avait pas le problème en suspens de DaveJ, je serais probablement parfaitement heureux. Nous verrons comment tout cela se déroulera ; mais en attendant, plus ceci pourra subir de tests, mieux ce sera.

Donc, allez‐y, secouez‐moi ça,

Linus

RC-7

La version RC-7 est sortie le 30 novembre 2014 :

Les choses se calment gentiment et tout semble assez normal. En fait, s’il n’y avait pas les questions en suspens avec les blocages étranges du watchdog (et peut‐être le RCU), je serais assez heureux. En soi, ce n’est pas une régression de la 3.17, mais c’est toujours très inquiétant.

En même temps, avec l’arrivée des vacances et le problème qui n’est pas une régression, je suppute que ce qui arrivera, c’est que je sortirai la version 3.18 à l’heure dans une semaine, parce que la retarder perturbera la phase d’intégration et les fêtes de fin d’année, ou alors je devrai beaucoup la retarder.

Nous verrons… Peut‐être que DaveJ pourra le résoudre par dichotomie, maintenant qu’on a montré que « la 3.17 était OK » était une fausse piste (en fait, il semble que le problème se soit glissé entre la 3.16 et la 3.17).

C’est ennuyeux, parce que, comme mentionné, le reste semble fonctionner correctement. Le correctif RC-7 semble tout à fait normal, les deux tiers étant des pilotes (un peu sur tout : USB, réseau, staging, thermique, pilotes graphiques, son…) et la moitié du reste concernant des mises à jour d’architectures (principalement MIPS, ARM et PowerPC). Le reste est principalement des corrections du réseau et des systèmes de fichiers (NFS et Btrfs).

Linus

Version finale

La version finale est sortie le 7 décembre 2014 :

Ce fut une semaine calme, et le correctif depuis la RC-7 est minuscule, donc le 3.18 est sorti.

J’aurais adoré annoncer que nous avons compris le problème qui empoisonne le 3.17 pour une poignée de gens, mais nous n’y sommes pas parvenus. En même temps, il n’y a absolument aucune raison que tout le monde se tourne les pouces pendant que quelques‐uns tentent ardemment de dichotomiser un ancien problème. Par conséquent, retarder la publication n’était vraiment pas pertinent. D’autant plus que ça aurait ensuite fait traîner les choses pendant toute la période des vacances.

La fenêtre d’intégration du 3.19 est donc ouverte, et espérons que DaveJ aura achevé sa dichotomie (ou au moins que les hypothèses soient suffisamment restreintes pour que l’on atteigne le moment du « Ahaa ! ») au cours de la semaine prochaine. Mais, en solidarité avec Dave (et aussi pour rendre ma vie plus facile ;), essayons d’éviter d’introduire tout nouveau méchant problème. D’accord ?

Linus

Les nouveautés Architecture

La compilation à la volée des programmes de l’extended Berkeley packet filter (eBPF) est maintenant prise en charge sur l’architecture ARM64 (Cf. article sur le site LWN.net).

Prise en charge des nouvelles puces ARM

Cette nouvelle version inclut, comme d’habitude, la prise en charge de nouvelles puces ARM. Nous parlerons ici des plus importants, ainsi que des changements notables au niveau du device tree pour ARM.

L’Atmel SAMA5D4 dispose d’une prise en charge basique. il s’agit d’un système monopuce (SoC) basé sur le ARM Cortex A5, orienté haute performance et basse consommation énergétique. Il intègre un décodeur matériel pour l’affichage en 720p, un contrôleur mémoire DDR qui offre une bande passante allant jusqu’à 1 408 Mio/s, un co‐processeur pour le calcul flottant (FPU), un co‐processeur vectoriel NEON (SIMD), 3 ports USB high‐speed, deux contrôleurs réseau Ethernet 10/100 Mbit/s, un contrôleur vidéo LCD, une interface pour une caméra et bien plus. En consommation maximale, il est annoncé en dessous de 150 mW.

Du côté d’Allwinner, nous pouvons évoquer une première prise en compte des cartes Olimex A20-OLinuXino-LIME, ainsi que de la Merrii Hummingbird A20. La Olimex A20-OLinuXino-LIME est une carte de développement disposant d’un système monopuce Allwinner A20 double cœur ARM Cortex A7 cadencé à 1 GHz, de 512 Mio de mémoire vive DDR3, un processeur graphique ARM Mali 400, un connecteur SATA, un connecteur HDMI gérant des résolutions en HD 1080p.
La Merrii Hummingbird A20, quant à elle, dispose également d’un système monopuce Allwinner A20 double cœur ARM Cortex A7 cadencé à 1 GHz, de 1 Gio de mémoire vive, 4 Gio de mémoire Flash NAND interne, Ethernet Gigabit, un connecteur SATA, un lecteur de carte microSD…

Nous pouvons également mentionner quelques changements au sein de l’arborescence matérielle device tree. Quelques définitions de systèmes monopuces ont changé de licence, passant de la GPLv2 à une double licence GPLv2/X11, ce qui permet de faciliter leur réutilisation sans imposer d’héritage de licences.
Les prises en charge de l’horloge temps réel, d’un contrôleur DMA, ainsi que d’un contrôleur MMC ont été ajoutées à la définition du sun8i. Les contrôleurs MMC et i2c sont activés et utilisés sur les Ippo Q8H-V5 et bien d’autres. Je vous invite à voir les changements dans le commit de fusion.

Concernant les systèmes monopuces Rockchip, nous pouvons mentionner l’ajout de nouvelles horloges processeur au sein du pilote des horloges des Rockchip, il s’agit principalement de modifications pour la prise en charge des derniers RK3288.
Le pilote Ethernet arc bénéficie d’un pilote spécifique pour les systèmes monopuces RK3188 et RK3066 (que l’on peut trouver dans la Radxa Rock ou la Marsboard, par exemple). Ceci leur permet, d’intégrer la prise en charge de la couche physique Ethernet concernant la vitesse de communication entre le contrôleur EMAC et le contrôleur Ethernet, de gérer correctement les régulateurs de tensions, ainsi que les horloges MDIO.
Enfin, un pilote pour le circuit de gestion de l’énergie (PMIC) RK808 de Rockchip a été ajouté. Celui‐ci est notamment présent dans la carte d’évaluation du RK3288 ou certaines cartes qui possèdent cette puce.

Une prise en charge préliminaire pour les systèmes monopuces MesonX/Meson6 de chez Amlogic fait son entrée dans le noyau. Amlogic AML8726-MX (nom de code Meson6) est un microprocesseur haute performance destiné aux applications multimédia et aux appareils multimédia connectés à Internet (Multimedia Internet Devices — MID). Il intègre deux cœurs ARM Cortex A9 cadencés à 1,5 GHz, un co‐processeur SIMD NEON, un processeur graphique ARM Mali 400, un décodeur matériel permettant d’aider au décodage des vidéos en 1080p.

L’ordinateur Acer Chromebook 13 CB5 dispose d’une prise en charge au sein du device tree. Il s’agit d’un ultra‐portable équipé d’un NVIDIA Tegra K1 quadri‐cœur ARM Cortex A15 cadencé à 2,1 GHz, de 4 Gio de mémoire vive et d’une carte graphique à architecture Kepler. Il est livré sous ChromeOS.
Parmi les autres changements notables au sein du device tree pour Tegra, on peut citer l’ajout de la gestion SATA et PCIe pour les Tegra124, ainsi que leur activation sur la Jetson TK1 et l’activation du pavé tactile pour les Venise 2.

Les changements non évoqués sont consultables dans le commit de fusion, consultable ici.

ACPI et gestion d’énergie

Le principal changement dans la gestion de l’ACPI est sur les machines Apple : le microprogramme change de comportement selon que le système d’exploitation annonce être _OSI("Darwin") ou autre chose. Par exemple, il désactive les ports Thunderbolt, à moins que le système fonctionne sous OS X. Linux s’annonce donc maintenant comme Darwin sur ces machines.

Gestion du bus PCI sur les processeurs ARM 64 bits

Après onze versions de Linux, la gestion des bus PCI sur les processeurs ARM 64 bits vient d’être achevée. Il est maintenant possible d’utiliser cette fonctionnalité avec trois ponts PCI (AppliedMicro X-Gene, TI Keystone, Xilinx AXI).

Pour plus d’informations, vous pouvez consulter la demande d’intégration.

Mise en veille et réveil plus rapide

Ouah, on a gagné jusqu’à 100 ms par cœur de processeur lors du processus de mise en veille et de réveil. En effet, un temporisateur de 100 ms était utilisé pour attendre le réveil, et Lan Tianyu, d’Intel, l’a remplacé par un vrai signal. Ça n’a l’air de rien, mais sur un simple quadricœur on arrivait déjà presque à une seconde ; alors, pensons à ce joli serveur à 48 cœurs qui va pouvoir se réveiller en 5 secondes de moins !

Architecture SPARC64

La quantité de mémoire adressable sur l’architecture SPARC64 a été considérablement augmentée grâce à l’utilisation de tables de pages à quatre niveaux.

Développeurs Mailbox

Une nouvelle API fait son entrée dans cette version pour utiliser les capacités matérielles de communication inter-processeurs. Pour un peu plus d’informations, vous pouvez consulter la documentation écrite à son sujet.

Correction de l’appel système fanotify_init()

L’interface de programmation fanotify met à disposition un ensemble de fonctions qui permettent d’être notifié et d’intercepter les événements de systèmes de fichiers. Surveiller un dossier hiérarchisé ou un fichier ciblé peut faire partie des cas d'utilisations.
fanotify_init est un appel système associé à cette interface. Il permet d'initialiser un groupe fanotify et retourne un descripteur de fichier correspondant à la file d’événements que l'on peut manipuler par la suite via l'interface de programmation correspondante, comme par exemple fanotify_mark.

Jusqu'à présent, cet appel système contenait une limitation. Lorsque les drapeaux leur étant passés en paramètre au travers de la variable flags contenait le drapeau O_CLOEXEC, celui ci était tout simplement ignoré. Reste à savoir s'il s'agit d'une action volontaire ou d'un oublie… Ce problème est désormais corrigé. Il est demandé à tout les développeurs dont les applications peuvent utiliser ce drapeau de façon silencieuse ou qui travaillent tout simplement avec cette interface de vérifier leur code afin de ne pas introduire d'effets de bords non désirés.

Quelques fonctions variables par processeur marquées obsolètes

Quelques fonctions qui permettent d’accéder à des variables locales au processeur ont été marquées obsolètes, il s’agit de __get_cpu_var() et de __this_cpu_ptr(). L’usage de ces fonctions est à remplacer respectivement par this_cpu_ptr() et raw_cpu_ptr(). Je ne décrirai ici que les nouvelles fonctions.

this_processeur_ptr() et raw_processeur_ptr() sont des fonctions qui permettent d’accéder à un pointeur qui est propre au processeur depuis lequel la fonction est appelée. Ceci est notamment possible grâce aux registres de segments sur les architectures x86 ou des registres internes spécifiques qui contiennent le début de la zone mémoire dédiée au processeur courant. Ces fonctions permettent d’ajouter un décalage à l’adresse de base par processeur contenue dans ces registres spéciaux, et encodent cette opération de calcul d’adresse directement dans l’instruction de l’opération d’accès à la variable par processeur.

Cela permet notamment de résoudre pas mal de problèmes d’atomicité d’accès à des données sensibles, entre le moment où l’adresse est calculée et où la donnée est modifiée. Cela est d’autant plus intéressant concernant la lecture ou l’écriture de ces variables. Bon nombre d’instructions sont garanties atomiques car le processeur signale par un verrou matériel sur le bus mémoire qu’il est en train d’écrire ou lire une donnée. L’usage de telles instructions évite d’avoir à utiliser des moyens de synchronisation (type mutex, spinlock…) car elles sont atomiques et non conflictuelles. En revanche, lorsqu’elles sont utilisées de façon assez agressive, elles ont tendance à provoquer de la contention sur le bus. L’utilisation des fonctions évoquées dans cette section est donc très intéressante, car, comme les données sont garanties uniques par processeur, il n’y a pas besoin de mettre un verrou matériel sur le bus. Ceci est très intéressant en termes de performances sur des machines qui disposent de plusieurs cœurs.

D’autres fonctions « this_cpu() » sont disponibles dans le noyau. Je vous invite à lire la documentation pour plus de détails.

LLVM

Vingt‐six correctifs ont été intégrés pour améliorer la prise en charge de LLVM/Clang, en partie pour l’architecture ARM64 et les modules de cryptographie.

Une partie des correctifs consiste à remplacer les tableaux de taille variable dans les structures (Variable Length Array In Struct ou VLAIS. Cf. présentation à la Linux Plumbers Conference 2013) par un équivalent valide dans le standard C99 (correctifs : [1], [2]…).

Vidage mémoire des périphériques

Les périphériques que nous utilisons sont en général pilotés par un pilote depuis le noyau. Certains ont toutefois un micrologiciel directement dans la mémoire du périphérique, qui permet de réaliser des tâches complexes côté matériel (si vous me permettez l’expression). Lors du chargement du pilote au sein du noyau si celui‐ci le demande, le noyau Linux peut charger à la volée un micrologiciel directement dans la mémoire du périphérique. C’est notamment à ça que sert le projet linux-firmware.

Il arrive toutefois, comme le code logiciel au sein des pilotes de votre noyau, que celui du micrologiciel soit bogué ou fonctionne mal. Ceci rend la tâche beaucoup plus complexe aux développeurs, car cela peut concerner des parties matérielles non couvertes par la fiche technique, et il est parfois difficile de savoir dans quel état le périphérique se trouve.

Une fonctionnalité de vidage mémoire (coredump) de périphérique vient d’être ajoutée à cette nouvelle version. Ceci permet de récupérer une image binaire de l’état dans lequel votre périphérique se trouve.

Il s’agit d’un mécanisme générique de récupération des données dans la mémoire du périphérique, et non d’une image ou d’un format en particulier (qui varie d’un matériel à l’autre). Ceci est exposé dans sysfs via l’interface /sys/class/devcoredump/devcd*/. Je vous invite à regarder le commit en question pour de plus amples informations.

Modules compressés

Il était déjà possible de manipuler des modules noyau compressés par l’intermédiaire de module-init-tools (gzip) ou de kmod (gzip, xz). Les développeurs de distributions, ainsi que les bidouilleurs du dimanche n’auront plus besoin de mettre en place des procédures de compression automatique durant un déploiement, ceci vient d’être ajouté à kbuild (le système de construction du noyau).

Ce correctif rajoute une option à kconfig dans la section Enable loadable module support, et vous propose le choix de compresser avec xz ou gzip.
Ainsi, dès lors que vous lancez la commande make modules_install, vos modules seront automatiquement compressés après installation. Il est toutefois suggéré d’utiliser gzip pour les périphériques embarqués, certes moins efficace en termes de compression, mais bien plus rapide comparé à son homologue xz.

Paramètres de modules non sûrs

Il arrive parfois que certains modules exposent des paramètres de débogage ou de test pour les développeurs, s’avérant peu utiles voire dangereux pour les utilisateurs. Il serait pour cela pratique que des messages d’avertissement retiennent l’attention de l’utilisateur lorsqu’il examine ses journaux noyau. Deux fonctions ont été ajoutées pour remédier à ce problème, il s’agit de _module_param_unsafe() et _module_param_named_unsafe().

Lorsque des paramètres module exposés au noyau par l’intermédiaire de ces fonctions sont manipulés depuis l’espace utilisateur, cela mettra le noyau dans un état spécial, de corruption, que l’on appelle dans le jargon linuxien : kernel tainted.

Il s’agit d’un état dans lequel le noyau peut se mettre lorsqu’un module propriétaire est chargé ou qu’une action qui n’a pas lieu d’être est utilisée. Cela peut bloquer certaines API ou fonctionnalités du noyau dans certaines conditions et permet aux développeurs noyau de savoir s’il s’agit d’une utilisation ou d’un bogue dont ils doivent se soucier. Cela permet également d’informer l’utilisateur si ce qu’il est en train de faire est pris en charge par la communauté en cas de problème.

Résolveur de références au sein du device tree

Le device tree est une fonctionnalité qui permet de décrire la topologie matérielle de la carte embarquée sur laquelle le noyau s’exécute et lui donne des informations précieuses concernant la façon dont les composants matériels sont configurés et comment les exploiter. Par exemple, quelles broches GPIO utiliser en tant qu’interruption pour un périphérique, ou encore quelle est l’adresse de base physique MMIO d’un contrôleur dans la mémoire. Ainsi, un grand nombre d’informations spécifiques à la carte embarquée se retrouve au sein de ce device tree, et permet en plus de donner du contexte au noyau pour se retrouver avec du code pilote beaucoup plus générique et beaucoup plus maintenable. En effet, avec un tel mécanisme, le code des pilotes se focalise sur le fonctionnement du périphérique lui‐même et n’a pas besoin de contenir des dizaines de variantes en fonction de la carte utilisée, ceci est maintenant factorisé et sorti du code (du moins quand cela est possible).

En général, cela se présente sous la forme d’un fichier ayant une extension .dts contenant la topologie matérielle sous forme d’arborescence dans laquelle chaque pilote de périphérique (device driver) contient un nœud, que l’on appelle un device node. Chaque nœud dispose de propriétés et peut contenir à son tour des sous‐nœuds. Ces définitions et descriptions représentent généralement l’architecture matérielle de la carte. Au sein de ce même fichier, les nœuds peuvent se référencer les uns avec les autres, ce qui permet d’exprimer des contraintes matérielles (par exemple, mon contrôleur de NAND à besoin du SPI 0). Ces référencements sont exprimés en attribuant le nom d’une variable du nœud cible à une propriété du nœud qui en dépend. On appelle une telle référence, un phandle, une adresse de device node au sein du device tree en quelque sorte.
Ce fichier est ensuite compilé en un device tree blob par le compilateur device tree compiler (appelé dtc, oh yeah !) et chargé par le noyau. C’est dynamiquement que celui‐ci est interprété par les pilotes qui en ont besoin, en utilisant la bibliothèque device tree prévue à cet effet. Je vous invite à consulter le site devicetree.org pour plus de renseignements.

Oui, mais… c’est certes très pratique, mais quand même très statique. Qu’en est‐il des cartes disposant de plusieurs cartes d’extension, ou de certaines à base de processeurs ARM contenant des FPGA et complètement programmables ? Doit‐on définir un device tree par carte et par configuration ? Cela deviendrait rapidement non maintenable. C’est la raison pour laquelle, les mainteneurs de ce composant au sein du noyau ont commencé à étudier le sujet sérieusement.
L’idée serait d’avoir un device tree de base, chargé par le noyau au démarrage et de pouvoir par la suite venir y greffer dynamiquement, soit la portion d’un device tree par dessus, soit venir changer ou modifier à chaud une partie de celui‐ci chargée en mémoire. Cela serait très pratique pour les développeurs qui souhaitent tester rapidement un changement sans avoir à tout recharger, ou pour commencer à répondre aux problématiques ci‐dessus (par exemple, une portion de device tree par carte d’extension, que l’on greffe par dessus celui de la carte de base).

Une première partie, consiste à intégrer un solveur de portions de device tree au sein du noyau. Vous rappelez‐vous des phandles dans le paragraphe précédent ? Un nœud est capable d’en référencer un autre, en fonction des besoins du pilote lui étant associé ; pour ce faire, le noyau doit être en mesure de résoudre ce référencement sur les portions de device tree insérées à chaud. Il s’agit d’un solveur de références au sein du device tree. Cette prise en charge vient d’être ajoutée au noyau 3.18. C’est le début d’une suite assez intéressante de fonctionnalités.

Miniaturisation

Aujourd’hui, le noyau Linux est capable de tourner sur à peu près n’importe quoi, allant de l’objet connecté et des cartes de développement de type BeagleBone Black jusqu’aux super‐calculateurs. Qu’en est‐il des vrais systèmes embarqués avec des contraintes de tailles et de ressources ? Par exemple, des cartes avec des systèmes monopuces STM32 ou EFM32 qui ne disposent que de 1 Mio de mémoire vive, voire de quelques kibioctets.

Le noyau Linux a vu son empreinte mémoire minimum augmenter au fil des versions, chose qui a rarement diminué avec le temps. Ceci rend la tâche difficile aux développeurs qui ne disposent que de quelques kibioctets pour faire tourner l’intégralité de leur système, ainsi que leurs applications. Dans des cas comme celui‐ci, ils peuvent se tourner vers des alternatives libres comme FreeRTOS ou Contiki, voire des systèmes propriétaires. Et c’est ici qu’est le problème. Pourquoi le noyau Linux, ne pourrait‐il pas répondre à un tel besoin ?
Outre le fait que Linux nécessite une unité de gestion mémoire (MMU) pour pouvoir fonctionner, des alternatives libres basées sur la branche principale du noyau ont vu le jour, c’est le cas de µCLinux.

Ce fut le sujet de l’une des présentations de Josh Triplett au Kernel Summit 2014. Même si certains développeurs ont l’air de suggérer d’utiliser un noyau 2.4, ceci n’est pas une vraie solution sur le long terme. Pourquoi ces plates‐formes ne pourraient‐elles pas bénéficier d’une prise en charge par le noyau actuel ?

C’est la raison pour laquelle le site tiny.wiki.kernel.org a été mis à disposition. Il regroupe toutes les modifications qui sont à faire afin de minimiser le noyau et contient des informations relatives à ce projet.

Cela n’a pas été mentionné, mais depuis la version précédente, la commande make tinyconfig a été ajoutée. Elle permet de compiler un noyau minimal et vous laisse ensuite la possibilité d’ajouter uniquement ce dont vous avez besoin. Malheureusement, ceci n’est pas encore suffisant. Beaucoup de choses peuvent être optimisées au sein du noyau, afin de réduire la taille de l’image et son empreinte mémoire.

Dans cette version, pas mal d’améliorations et de correctifs ont été acceptés à ce sujet. Vous pouvez suivre l’état des choses à faire directement sur la page du site du projet.

Temps réel

Il y a un an Thomas Gleixner, mainteneur et développeur principal du projet Linux temps réel (ou PREEMPT_RT), alertait sur le manque de soutien de la part des industriels l’utilisant. Un an plus tard, malgré les efforts de la Linux Foundation et de l’OSADL, la situation n’'ayant pas évolué, il annonce que la maintenance de ce correctif sera maintenant effectuée à titre de hobby.
Apparemment les industriels ont préféré jouer à « le premier qui bouge (paye) a perdu » mais au final, ils risqueraient bien d’être tous perdants.
Il est alors fort probable, au vu de la vitesse d’évolution du noyau que ce projet prenne rapidement beaucoup de retard et soit de plus en plus difficile à maintenir.

Pilotes graphiques libres DRM (Direct Rendering Manager)

La modification la plus importante de DRM concerne la gestion de l’intervalle de suppression de trame (vblank). Auparavant, celle‐ci était désactivée quelques millisecondes après qu’aucun client n’ait demandé de synchronisation avec elle. Dorénavant, le comportement par défaut est de la désactiver immédiatement. Cela permet d’économiser de l’énergie en évitant de recevoir des interruptions non nécessaires. Ce comportement est possible pour tous les matériels possédant un horodatage matériel précis. Pour plus d’informations, vous pouvez consulter la demande d’intégration de cette série de correctifs.

David Herrmann et Daniel Vetter ont assaini les fichiers d’en‐tête de DRM, afin de mieux délimiter les fonctions préservées par souci de respect de l’API, mais qui ne devraient jamais être utilisées par un nouveau pilote. Ils ont également profité de cette opération de nettoyage pour exposer au pilotes DRM le moins possible des structures internes à DRM. Pour l’anecdote, lors de la relecture de ces correctifs, nous avons envoyé deux correctifs ([1] et [2]) triviaux pour corriger des erreurs dans les commentaires. Ces correctifs ont été fusionnés pour Linux 3.19. La morale est que si vous voyez des erreurs, même si elles sont triviales, envoyez des correctifs !

L’infrastructure commune s’améliore également sur la question de la gestion du mode d’affichage atomique. Cela inclut la prévention d’interblocages dans le tampon de trame Linux (fbdev) qui pouvaient déjà arriver avec les noyaux actuels, mais vont devenir bien plus courants lorsque plus d’applications vont demander des changements.

Du côté de TTM, le système de synchronisation par barrière a été revu et unifié à travers tous les pilotes utilisant TTM. Cela devrait améliorer la synchronisation entre plusieurs pilotes graphiques, comme cela est nécessaire pour les ordinateurs portables utilisant la technologie Optimus. Pour plus d’informations, vous pouvez consulter la demande d’intégration.

Pour plus d’informations sur les modifications apportées dans DRM, vous pouvez consulter la demande d’intégration DRM.

AMD/ATI (pilote Radeon)

La partie DRM du pilote Radeon fait encore de gros progrès, avec l’activation du décodeur vidéo matériel UVD pour le H.264 sur d’anciennes cartes (3xxx et 48xx).

Après avoir corrigé un problème avec la gestion d’énergie dans la famille Cayman dans Linux 3.17, un utilisateur a pu vérifier que les familles Nothern Island, Southern Island, Canary Island et BTC n’étaient plus touchées par ce problème (rapport de bogue). Ces puces gèrent maintenant mieux le DPM.

Pour finir, quelques correctifs pour la gestion du son via l’interface HDMI ont été proposés.

Pour plus d’informations, vous pouvez consulter la demande d’intégration Radeon.

Intel (pilote i915)

Le pilote DRM i915 a enfin reçu les derniers correctifs afin d’activer la gestion du PPGTT (Per‐Process Graphics Translation Table) qui permet d’isoler les différents clients graphiques dans différents espaces d’adressage. Du moins, c’était avant que plus de tests mettent en avant d’autres bogues, ce qui a conduit à sa désactivation. Ces bogues ont normalement été corrigés et espérons que la gestion du PPGTT sera enfin disponible dans Linux 3.19 !

Du côté de l’affichage, la gestion de la rotation de plans graphiques vient d’être ajoutée. La gestion du DRRS (dynamic refresh rate switching — commutation dynamique de fréquence de rafraîchissement) s’approche avec l’ajout des parties communes, le reste devrait arriver dans les noyaux suivants, ce qui devrait permettre de diminuer la consommation énergétique.

Du côté gestion du mode d’affichage, le code pour les puces i830M a été corrigé. La gestion de l’alimentation des panneaux eDP a également été revue et la gestion d’un nouveau mode d’établissement de lien DisplayPort a été ajoutée. Pour finir, plusieurs corrections de bogues ont été faites dans la gestion du HDMI, pour améliorer les résultats aux tests de conformité du standard.

Pour finir sur les modifications compréhensibles, la gestion de la commutation de pages a été améliorée pour mieux gérer les cas où le pilote ou le matériel a oublié un événement. Cela va permettre de ne pas voir son écran bloqué en attente d’un événement qui s’est déjà terminé !

Comme à son habitude, Daniel Vetter (mainteneur i915) a publié un compte‐rendu des modifications sur son blog, que vous pouvez lire pour plus d’informations. Vous pouvez aussi consulter la demande d’intégration i915.

NVIDIA (pilote Nouveau)

L’amélioration la plus visible dans Nouveau est l’ajout de la gestion du son avec les écrans DisplayPort (DP) (correctif). Cette fonctionnalité fait miroir à l’ajout du son sur HDMI, qui avait été ajouté dans le noyau 3.13.

Une autre amélioration visible dans Nouveau concerne les changements de fréquence d’horloge (reclocking — recadencement), notamment de la mémoire. Ce travail a été initié par Roy Spliet qui a travaillé pendant trois mois à plein temps durant l’été, dans le cadre du Google Summer of Code. Son travail a uniquement porté sur les puces GT21[568] (NVA[358]), mais il est maintenant possible de recadencer la majorité des cartes utilisant cette puce. Pour un compte‐rendu sur son projet, vous pouvez consulter sa présentation faite au XDC2014 qui s’est déroulée à Bordeaux en octobre. Grâce aux découvertes de Roy, Ben Skeggs a pu améliorer la gestion du recadencement dans la famille Kepler et, en outre, en a profité pour améliorer la gestion du recadencement de la mémoire.

Concernant la prise en charge de la première génération des processeurs graphiques Maxwell (puce GM107), celle‐ci s’améliore avec l’ajout de la gestion du ventilateur et de PDAEMON/PMU (système d’exploitation temps réel s’exécutant sur le processeur graphique ayant pour but de gérer l’énergie).

En vrac

Peu de changements du côté des pilotes DRM pour les systèmes monopuces.

La principale nouveauté est la gestion de la puce Samsung Exynos 3250 par le pilote exynos. Ce pilote a également changé son interface pour l’appel système mmap() et l’a remplacé par l’implémentation proposée par DRM. Pour finir, le pilote utilise maintenant la nouvelle interface DRM de gestion universelle des plans graphiques, afin d’exposer ses différents contrôleurs vidéo CRTC (partie du processeur graphique qui envoie les pixels à l’écran). Pour plus d’informations, voir la demande d’intégration exynos.

Du côté d’Adreno, la puce md4 se voit ajouter la gestion du protocole de communication LVDS, utilisé par les dalles LCD des ordinateurs portables. La gestion du panneau B101XTN01.0 a également été ajoutée. Pour finir, le pilote a commencé à être refactorisé, pour faciliter l’arrivée de la future famille de processeur Adreno. Pour plus d’informations, voir la demande d’intégration MSM.

Réseau Transmission de paquets réseau en masse

Les améliorations de performance réseau dans cette version ont été fusionnées. Entre beaucoup d’autres choses, elles permettent à de relativement petits systèmes de gérer des interfaces rapides à leur vitesse réelle, même quand des petits paquets sont transmis. La performance des petits paquets a toujours été un problème pour Linux, c’est pourquoi c’est une amélioration importante.
Ce travail est limité en portée, en particulier, il ne va marcher qu’avec les files d’attente uniques. Éric Dumazet a regardé le correctif et a réalisé que cela pouvait être encore plus poussé : le processus de validation des paquets pour la transmission pouvait être déplacé complètement en dehors de la section critique de verrouillage de la file d’attente, ce qui améliore la concurrence dans le système. Les résultats du correctif ont des avantages qu’Éric décrit comme impressionnants : atteinte du débit théorique de l’interface de 40 Gbit/s, et ce, même en l’absence de gestion matérielle de la segmentation. De petits changements peuvent avoir de grands effets quand ils sont appliqués aux bons endroits.

Berkeley Packet Filter

Le nouvel appel système au Berkeley Packet Filter, bpf(), a été inclus. Il ne sert pour l’instant pas à grand chose, car il manque l’intégration aux sous‐systèmes de traçage et de filtrage de paquets notamment. Seul le cœur a été intégré, et consiste en une « machine virtuelle universelle » qui est maintenant disponible dans le noyau. Plus de détails sont disponibles dans l’article sur le site LWN.net [correctifs: [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], documentation dans les sources du noyau].

Foo-over-UDP

Le sous-système Foo‐over‐UDP a été fusionné. Il permet d’encapsuler arbitrairement n’importe quel protocole dans un tunnel UDP. Le choix s’est porté sur UDP, parce que beaucoup d’interfaces réseau disposent désormais d’une gestion matérielle pour UDP, qui gère notamment le calcul des sommes de contrôle des paquets. Le protocole UDP n’ajoute pas non plus trop d’informations, puisque seuls une adresse et un numéro de port sont nécessaires, ce qui n’augmente pas beaucoup la taille du paquet.

Il est aussi possible de faire fonctionner UDP avec le Receive Side Scaling (RSS) et l’Equal-cost multipath routing protocol (ECMP) (documentation du noyau : Scaling in the Linux Networking Stack), ce qui permet d’augmenter les performances dans certaines configurations (forte redondance des connexions entre deux systèmes, par exemple).

Les avantages des tunnels sur UDP sont si importants que certains développeurs pensent qu’ils vont devenir omniprésents dans les prochaines années. Plus de détails et un exemple de mise en place d’un tel tunnel sont disponibles dans l’article sur LWN.net.

DCTCP congestion control algorithm

Un nouvel algorithme de gestion de la congestion pour le protocole TCP a été intégré. Nommé Data Center TCP (DCTCP), il est, comme son nom l’indique, préposé à des cas d’utilisation fréquemment rencontrés dans les réseaux stables et fortement connectés des centres de données. Plus de détails sur le site Web dédié et le commit du correctif.

Generic Network Virtualization Encapsulation (Geneve) protocol

Le protocole Generic Network Virtualization Encapsulation (Geneve) est désormais pris en charge. Plus d’informations sont disponibles dans le brouillon IETF.

Sécurité

L’appel système prctl() gère une nouvelle opération PR_SET_MM_MAP, qui permet de définir l’agencement d’un certain nombre d’éléments essentiels d’un processus : l’endroit où sont localisés les données et le code, l’emplacement auquel démarre la pile, etc. Cette fonctionnalité est nécessaire pour le projet CRIU, lorsqu’il est utilisé en combinaison avec les espaces de noms [correctif].

Cryptographie

Le module effectuant les opérations cryptographiques peut tirer avantage des extensions matérielles permettant d’effectuer un même calcul sur plusieurs tampons simultanément. Pour commencer, l’infrastructure a été ajoutée, ainsi qu’une implémentation pour SHA1 utilisant les extensions AVX2 (correctifs : [1], [2], [3], [4], [5], [6]).

LSM

De nombreux bogues liés à l’utilisation de SMACK et de IMA & EVM simultanément sont corrigés dans cette version.
Comme les fonctions security_file_set_fowner(), f_setown() et __f_setown() retournaient toujours 0, elles n’ont maintenant plus de code de retour [correctif].

IMA & EVM

Les options liées à l’intégrité sont mieux présentées dans le menu Kconfig (correctifs : [1], [2]).

Un nouveau mode d’utilisation d’IMA a été ajouté : log. On l’utilise en précisant ima_appraise=log comme option au noyau. Les précédents modes (off, enforce et fix) n’étaient pas suffisants, car ils ne permettaient pas de voir l’ensemble des accès interdits sans les corriger automatiquement (mode fix). Le mode log laisse donc l’administrateur analyser le système en autorisant tous les accès, mais en écrivant toutes les erreurs dans le journal [correctif].

Une situation de compétition potentielle a été corrigée lors d’un accès à un même nœud d’index (inode) par deux processus simultanément [correctif].

Une nouvelle variable a été introduite pour permettre de gagner en performance dans certains cas [correctif].

Les violations d’intégrité faites à partir de correspondances mémoire d’un fichier sont maintenant correctement détectées dans tous les cas [correctif].

Correction de divers bogues (correctifs : [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22]).

SELinux

SELinux ne tient pas particulièrement compte des espaces de noms (namespaces) lors des vérifications de contrôle d’accès. Mais dans le cadre des espaces de noms réseau, une petite amélioration de la gestion du cache a été faite pour que les interfaces virtuelles soient proprement associées à une interface réelle [correctif].

Jusqu’à présent, un processus avec les attributs NO_NEW_PRIVS ou NOSUID ne pouvait pas changer de contexte SELinux. Il le peut désormais, uniquement si le contexte de destination est plus restrictif que le contexte courant [correctif].

Correction de divers bogues (correctifs : [1], [2], [3], [4], [5], [6]).

SMACK

Le développeur de SMACK (Casey Schaufler) a toujours refusé de créer un mode permissif ressemblant à ce qui est fait avec SELinux, par peur de se retrouver dans la même situation (les administrateurs exécutant systématiquement setenforce 0 ou passant la totalité du système en mode permissif, alors qu’une seule application pose problème).

Il a donc créé un mode « mise en place » (Bring‐up access mode) qui permet d’enregistrer l’ensemble des permissions nécessaires à une application pour son bon fonctionnement. L’objectif étant que ce mode ne sera pas disponible sur les systèmes en production, mais uniquement sur les versions de développement. Les détails de l’utilisation de ce mode sont dans le message du correctif.

Une étiquette SMACK vide ne causera plus de kernel panic ! [correctif].

Correction de divers bogues (correctifs : [1], [2], [3], [4], [5], [6]).

Trousseaux de clés

Il n’est plus possible de créer de clés avec comme type un nom commençant par un point [correctif].

Correction de divers bogues (correctifs : [1], [2], [3], [4], [5], [6], [7], [8]).

Liste non exhaustive des vulnérabilités corrigées

Touche principalement KVM et les espaces de noms utilisateur :

• CVE-2014-3610 [correctif] ;
• CVE-2014-3611 [correctif] ;
• CVE-2014-3646 [correctif] ;
• CVE-2014-3647 (correctifs : [1] et [2]) ;
• CVE-2014-7970 [correctif] ;
• CVE-2014-7975 (correctifs : [1] et [2]) ;
• CVE-2014-8480 [correctif] ;
• CVE-2014-8481 [correctif].

Systèmes de fichiers F2FS

Le système de fichiers F2FS gère maintenant les écritures atomiques (où une série d’opérations réussissent ou échouent comme une seule action) via un ioctl() spécifique à F2FS. Il a aussi gagné la prise en charge de l’opération FITRIM (discard).

OverlayFS

Le système de fichiers OverlayFS (cousin de UnionFS) a été intégré au noyau. Ce n’est pas véritablement un système de fichiers au sens propre, mais il peut être vu comme une surcouche de ceux‐ci. Il faut l’appréhender comme un système de calques permettant de superposer différentes couches de fichiers.
Il est utilisé sur les périphériques amorçables et autres systèmes en mémoires mortes (OpenWRT). Il est très utile pour les machines virtuelles répliquées.

UnionFS (Union File System) est un service du système de fichiers de Linux qui permet de fusionner plusieurs points de montage appelés « branches » : c’est une union de montages. L’utilisation habituelle de ce système est de fusionner une partition système en lecture seule avec une partition en écriture permettant d’enregistrer les nouveaux fichiers et fichiers modifiés, le système UnionFS se chargeant de ne présenter que la dernière version de chaque fichier [source : Union File System].

Voici les liens vers la documentation dans les sources du noyau, le correctif principal et tous les correctifs liés.

NFS

Le système de fichiers réseau NFS gère maintenant l’opération SEEK de la spécification NFS 4.2 (encore en cours de développement), permettant l’utilisation des options SEEK_HOLE et SEEK_DATA de lseek(2). Ces options permettent de se déplacer dans des fichiers contenant des trous (sparse files) (voir SEEK_HOLE and SEEK_DATA for sparse files).

Ceph

Le composant Rados chargé de la gestion des périphériques en mode bloc dans le projet Ceph gère désormais les requêtes discard. Pour rappel, ces requêtes permettent d’augmenter les performances et la durée de vie des disques SSD (TRIM).

Virtualisation KVM

La RC1 a introduit plusieurs nouveautés pour les architectures de processeurs prises en charge :

• l’architecture des ordinateurs centraux IBM (mainframes s390) se prépare à prendre en charge les grandes pages mémoire pour l’hôte ;
• pour les PowerPC, le débogage a été amélioré (à la fois à partir de l’invité, via des registres spécifiques, et à partir de l’hôte via gdbstub) ; il y a aussi la prise en charge de la virtualisation pour les processeurs e65000 ;
• du côté de chez ARM(64), c’est la mémoire en lecture seule qui fait son apparition ; ceci permet d’émuler un micrologiciel dans une mémoire Flash de type NOR ;
• et pour le x86(_64), outre les traditionnelles corrections, on retrouve des améliorations de la virtualisation imbriquée avec une meilleure gestion de celle‐ci pour les processeurs Intel sous Windows, et un début de prise en charge de l’hyperviseur Jailhouse pour les AMD ; le retrait de mémoire à chaud devrait aussi mieux fonctionner, et un bogue assez rare de la gestion du cache a été corrigé.

Avec la RC2, est aussi venue une correction assez grosse qui corrige un bogue pour la virtualisation imbriquée qui permettait à l’invité imbriqué de crasher l’hôte non imbriqué.

Xen

La RC1 a apporté les nouveautés suivantes :

• ajout de pilotes SCSI para‐virtualisés (PVSCSI) ;
• amélioration de la contiguïté mémoire pour la para‐virtualisation ;
• prise en charge des gros initrd pour les invités para‐virtualisés ;
• adaptation des invités PVH en préparation de Xen 4.5 ;
• les pilotes vont pouvoir utiliser les interruptions en multi‐thread.

Le bilan en chiffres

En ce qui concerne les statistiques du cycle de développement du noyau 3.18, le site LWN.net a publié son traditionnel article récapitulatif.

En nombre de modifications, on se situe à 11 186, soit environ 1 000 modifications de moins que la version précédente du noyau. Le nombre de contributeurs est, quant à lui, de 1 428. Ce nombre est resté relativement constant sur la dernière année.

Le développeur ayant écrit le plus de modifications est H. Hartley Sweeten (237) pour son travail de nettoyage des pilotes Comedi. Du côté des développeurs ayant le plus modifié de lignes, on trouve des mainteneurs tels que Greg Kroah‐Hartman, ayant supprimé des pilotes, ou d’autres, comme Martin Peres et Roy Spliet, qui ont modifié des microcodes, ce qui a généré beaucoup de lignes modifiées dans des fichiers d’en‐tête. Ce classement est donc à prendre avec des pincettes.

Environ 200 entreprises ont participé à l’élaboration de ce noyau. En tête, on retrouve Intel, qui a effectué 10,9 % des changements que l’on peut trouver dans cette nouvelle version. En deuxième place, Red Hat a contribué 7,6 % des changements. Il est cependant important de noter que les développeurs sans affiliation ont effectué 11 % des modifications, soit juste un peu plus qu’Intel, alors que les personnes non identifiées ont écrit 7,3 % des modifications. On peut donc dire, bien que le noyau soit majoritairement écrit par des employés d’entreprises, que les contributeurs indépendants sont toujours les bienvenus et sont même une majorité !

Appel à volontaires

Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition :

Mainteneur Contributeur(s) La phase de test Aucun Davy Defaud Arch Romain Perier Mali Développeurs Romain Perier Pilotes graphiques libres Martin Peres Réseau Aucun Timothée Ravier BRULE Herman Systèmes de fichiers Aucun Timothée Ravier Sécurité Timothée Ravier Virtualisation Xavier Claude Édition générale Aucun Martin Peres, Mali, M5oul et Davy Defaud

Un peu de vocabulaire :

• le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ;
• un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur.

Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps et de volontaires.

Nous sommes particulièrement à la recherche de mainteneurs pour les sections Systèmes de fichiers et Réseau, les précédents n’ayant pas donné de signes de vie pendant la rédaction des dernières dépêches.

Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les commits intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !

Télécharger ce contenu au format Epub

Lire les commentaires

LILA est une association loi 1901 à profil artistique et libriste, créée fin 2005 par Grégoire Coustenoble et Jehan Pagès. Elle avait été initialement créée pour organiser un festival de musique Libre mais le projet n'a pu aboutir, et l'association est restée dormante longtemps. Ses créateurs ont décidé de lui redonner vie, il y a quelques mois, expliquant le terme d'inauguration, même si cela semble étrange pour une association vieille de plusieurs années.

Cette petite soirée aura donc lieu ce samedi 20 décembre 2014, de 16h à 19h, au 31 avenue Parmentier 75011 Paris (métro Saint Ambroise).

Vous pourrez alors discuter avec les bénévoles, et voir un peu mieux ce que l'on fait. La rencontre est assez informelle, il ne s'agit pas de conférences, mais simplement de prendre un verre et de se rencontrer. Quelques boissons sont prévues, ainsi que de quoi grignoter.

• lien n°1 : Association LILA

Dans un contexte économique où les majors pilotent énormément de décisions politiques, où la passivité est la norme, et où on est considérés comme des « consommateurs », voire des voleurs a priori, plutôt que dans une relation constructive avec les créateurs, nous espérons pouvoir faire un peu contrepoids, avec des valeurs d'échanges où les artistes peuvent vivre de leur art (et pas seulement ceux en haut de la pyramide) et où toute personne peut profiter librement des œuvres, pour que les arts ne se limitent pas à « l'industrie du divertissement ».
Et nous souhaitons également créer nous-même ou participer à des créations d'œuvres collectives, en plus de promouvoir ces valeurs, ce qui est une composante importante de notre action.

Bien sûr le Logiciel Libre a une place importante dans nos activités, surtout parce que les logiciels de création artistique sont encore relativement peu connus, ou du moins mal vus, alors que le Logiciel Libre a désormais une place de choix dans pas mal de secteurs économiques, en particulier techniques.

Nous sommes pourtant bien pourvus, que ce soit pour le graphisme (GIMP, Inkscape, Scribus, Krita, MyPaint…), la 3D (Blender…), le son (Audacity, Ardour…), la photo (Darktable, Entangle…), etc. Mais ces logiciels restent considérés principalement dans les utilisations dites "amatrices" par l'industrie. Si LILA peut les aider à être mieux connus, mais aussi à les améliorer (NdA : j'ai personnellement du code dans GIMP, Blender et libmypaint entre autres), ce seront de grands pas.

Néanmoins les Logiciels Libres ne sont pas le but premier de l'association. Leur finalité intéresse bien plus, en l'occurrence les créations artistiques elles-mêmes. En ce sens, LILA est un pendant aux diverses associations libristes qui souvent se focalisent plus sur le logiciel comme finalité, proposant une vision complémentaire.

LILA a commencé à manifester sa présence avec un petit projet de financement de logiciels et d'artistes, le Calendrier du Libre, actuellement en cours d'impression et d'envoi (les résultats en chiffres précis seront bientôt publié sur le site de l'association). De plus, un projet de ressources du Libre avec plusieurs contributeurs actifs de l'écosystème du graphisme Libre est en cours de préparation. Ce projet devrait — espérons le — intéresser pas mal d'artistes quand il sera dévoilé plus en détail.

Quoiqu'il en soit, nous espérons vous voir ce samedi 20 décembre 2014. Si vous comptez venir, n'hésitez pas à nous envoyer un petit message au préalable, ce qui nous permettra d'avoir une idée du nombre de personnes qui passeront (sinon vous pouvez simplement venir à l'improviste, ça marche aussi).

Télécharger ce contenu au format Epub

Lire les commentaires

Le GULL associatif StarinuX organise un atelier sur les serveurs libres DHCP (sous GNU/Linux).

• Objectif : à l'issue de la formation, vous saurez installer, configurer, mettre en œuvre, un serveur DHCP (Dynamic Host Configuration Protocol) opérationnel, capable d'envoyer automatiquement une adresse IP aux stations de son réseau et domaine Intranet, avec l'option d'envoyer la même IP vers un ordinateur déterminé selon son adresse MAC ;
• quand : le samedi 27 décembre 2014 de 9h30 à 17h30 ;
• lieu : 48 rue de Colombes 92400 Courbevoie, salle corail étage 1A, (SNCF : gare de Courbevoie, 7min de St Lazare et 1min de la Défense) ;
• modalités : comme à l'accoutumée, une participation de 20€ annuelle (10€ pour les demandeurs d'emploi) est demandée, valable pour plus de 15 ateliers ;
• contact : events chez starinux.org.

• lien n°1 : Site de l'organisateur
• lien n°2 : Infos et inscription

Télécharger ce contenu au format Epub

Lire les commentaires

Le groupe d'utilisateurs et utilisatrices de Logiciels Libres de Toulouse « Toulibre », en collaboration avec « Tetaneutral », fournisseur d'accès internet et hébergeur libre, proposent aux sympathisants et sympathisantes de se retrouver l'un des mardis ou jeudis de chaque mois pour échanger autour des logiciels Libres, des réseaux libres, discuter de nos projets respectifs et lancer des initiatives locales autour du Libre.

Ce repas est ouvert à toutes et à tous, amatrices et amateurs de l'esprit du Libre, débutantes et débutants ou technicien(ne)s chevronné(e)s.

• lien n°1 : inscription

Ce « Quatrième/Quelconque Jeudi/Jour du Libre Toulousain (Qjelt) » aura lieu le mardi 23 décembre 2014 à 20 heures, au restaurant « Bois et Charbon » : 64 rue de la Colombette à Toulouse, à proximité de la place Saint Aubin, accessible par le métro à la station Jean Jaurès (ligne A et B). Entrée/plat/dessert + 1/4 de vin à 18€. Pour des raisons de logistique, une inscription préalable avant la veille au soir est demandée.

Télécharger ce contenu au format Epub

Lire les commentaires

La société Formations Linux LPI organise des formations LPI-101 et LPI-102 du Linux Professional Institute. Chaque formation inclut le passage de l’examen LPI 101 ou LPI 102, qui sont les deux moitiés de la certification LPIC-1.

Linux Professional Institute est un organisme à but non lucratif qui propose des certifications pour des administrateurs système et des programmeurs Linux.

• lien n°1 : Les formations à Metz
• lien n°2 : Inscription à la formation et à l'examen LPI 101
• lien n°3 : Inscription à la formation et à l'examen LPI 102
• lien n°4 : C’est comment une certification LPI ?

Les formations ont lieu à Metz :

• pour le LPI-101, elle aura lieu du lundi 16 au vendredi 20 mars 2015 inclus, de 9h à 12h30 et de 13h30 à 17h ;
• pour le LPI-102, elle aura lieu du lundi 23 au vendredi 27 mars 2015 inclus, de 9h à 12h30 et de 13h30 à 17h.

Les dates et lieu de passage des examens LPI-101 et LPI-102 sont en attente de confirmation.

La formation est recommandée pour réussir chaque examen, elle est faite par un formateur certifié LPIC-3 et contributeur LPI. En 2013, 100% des personnes qui ont suivi la formation LPI à Metz ont réussi l’examen.

Il est recommandé de s’inscrire dès maintenant pour obtenir à temps le financement de la formation et pour avoir une place (nombre de places limitées).

Télécharger ce contenu au format Epub

Lire les commentaires

Voici le troisième volet de la série 2014 sur la création d'entreprise dans le logiciel libre. Après l'entretien avec Ludovic Dubost au sujet de sa société XWiki, je vous propose de redécouvrir le parcours de Daniel Castronovo qui nous avait déjà parlé de son auto-entreprise Ikux il y a environ 3 ans.

Après être passé d'auto-entreprise à SARL, Ikux a cessé son activité en décembre 2013. Cette évolution est à l'opposé de ce que nous a présenté Jérôme Martinez entre décembre 2011 et septembre 2014 ; c'est aussi ce qui fait l'intérêt de ce retour d'expérience.

• lien n°1 : La société Ikux sur Infogreffe

Bonjour Daniel. Nous avions discuté fin 2011 de la création de ton auto-entreprise Ikux. Tu vendais alors des prestations autour de l'administration système. Peux-tu nous rappeler brièvement ton activité ?

Essentiellement de l’infogérance autour de briques OpenSource (administration système Linux), intégration de logiciels libres (gestion de parc, supervision, sécurité, serveurs Web, serveurs applicatifs, cloud, mail, sauvegarde, etc.)

Mais aussi de la formation sur des logiciels libres ou technologies pour des ingénieurs au tiers de mon temps, ainsi que des audits de sécurité.

Mes clients étaient surtout des start-up (dans le monde entier), ou bien des PME, ETI, TPE.

Il me semble que tu avais rapidement dépassé le plafond de CA autorisé pour une activité d'auto-entrepreneur. Où en es-tu aujourd'hui ?

J'étais passé en SARL moins d'un an après le début de mon activité, ça a été le début de la fin car j’avais notamment moins de 200€ de charges mensuelles, beaucoup de TVA à payer, rappels RSI, etc. Donc beaucoup de paperasses, sachant que j’avais un comptable tout de même.

La SARL n'est pas un statut intéressant si on est l'unique gérant majoritaire, sans aucun employé, avec très peu de charges et des délais de paiement long.

Quel a été le processus qui t'a amené à décider de cesser ton activité ? Était-ce inévitable ?

Au fur et à mesure des mois j’ai ressenti une crise, moins de clients, des clients réguliers qui ont mis la clef sous la porte ou se sont fait racheter, les clients en difficultés de paiements.

Et surtout je me rendu compte que beaucoup ne voulaient plus payer pour du logiciel libre qui marche avec un suivi, des conseils, et voulait juste des prestations au rabais, ou grapiller des infos pour les donner à leurs stagiaires ou concurrents low-cost.

J’aurai pu essayer de continuer en l’état en évitant de me payer, embaucher un commercial pour acquérir de nouveaux clients, trouver un local, ou m’exiler dans un pays avec une fiscalité plus avantageuse.

Mais franchement je n’en avais plus l’envie, je voulais à ce moment-là continuer à faire de la technique et de la qualité.

Pour que les lecteurs comprennent bien l'ensemble du processus, peux-tu faire un résumé des étapes importantes de la vie de ton entreprise ?

Phase 1 - Création d'entreprise en auto-entrepreneur

• 01/09/2011 : ouverture du statut en auto entrepreneur
• J+15 : premiers clients
• 3 mois plus tard : plusieurs gros contrats d'infogérance et audit, début en tant que formateur en logiciels libres sur Paris essentiellement : GLPI, OCS Inventory, Linux avancé, scripting, sécurité, Nagios, Centreon, etc.
• 6 mois plus tard : beaucoup d'activité, contrats sur contrats, travail le jour et souvent les nuits étaient longues.

Faire de la formation m'a permis d'accumuler les bons de commandes, faire de la pub, avoir une notoriété plus grande.

Phase 2 - Passage en SARL

• 22/09/2012 : création de la SARL
• 1 mois plus tard : l'activité est au beau fixe, j'arrête les formations (j'ai déménagé à plus de 120km, paiement à 90 jours, trop de frais, plus de temps à y consacrer)
• 3 mois plus tard : moins d'activité, je continue car beaucoup de clients me payent à 60-90 jours
• 6 mois plus tard : perte de 50% des clients (4 gros contrats qui se sont arrêtés, beaucoup de clients ont mis la clef sous la porte, des paiements qui s'éternisent (quand ils payent).

Je reçois entre 2 et 5 appels par jours. 8 fois sur dix, la conversation se termine par un classique "c'est cher pour du libre, vous pouvez pas me faire un geste commercial … ou prendre des parts, ou m'offrir la prestation".

Même les entreprises qui font plus de 1 million de CA ne voulaient plus payer pour du libre au final. De plus je me suis rendu compte que mon site avait été copié, pour proposer des tarifs à moins 50%. A ce moment-là, je me suis vraiment posé des questions, j'en ai parlé autour de moi. Beaucoup de mes concurrents avaient le même problème, aux même périodes.

Phase 3 - Arrêt de l'activité

• 23/12/2013 : dissolution
• début janvier 2014 : contrat salarié dans une SSII du domaine bancaire
• fin mars 2014 : je commence mon nouveau job chez Suderiane : support niveau 2 multiplateforme, admin sys windows et linux
• 20/05/2014 : clôture des comptes de ma SARL

J'ai du quémander à plus de trois reprises le RSI pour me faire un rappel, le plus dur est de devoir relancer pour payer…

Quelles difficultés as-tu rencontrées dans cette phase d'arrêt d'activité ?

Quand on est entrepreneur on sait ce que l'on veut en général, on connait les pièges à éviter aussi (les grosses SSII et moi ça fait deux). Donc je me suis très vite mis sur le marché du travail, j'ai pas eu de mal à décrocher des entretiens. Mais à chaque fois il y avait un truc ou deux qui ne me convenait pas, par exemple le fait de faire des heures à rallonge sans compensation, les trajets (plus de 3h de transport quotidien), le type de travail à effectuer, etc.

Au bout de 1 mois j'en avais marre - de plus les finances te rappellent vite à l'ordre, alors j'ai commencé un nouveau job dans une grande entreprise française du domaine bancaire. Au bout de dix jours je m'ennuyais fortement. On a donc décidé de mettre fin à cette mission car je n'aime pas me tourner les pouces, ni le fait que l'on ne prenne pas en compte mes avis techniques (c'est dur de faire bouger une grande entreprise).

Dés le lendemain j'avais plusieurs entretiens prévus à plus de 100km de mon domicile, intéressants, mais encore et toujours les bonnes vieilles méthodes des SSII. Donc j'ai décidé d'envoyer des CV dans mon département, peu de réponses intéressantes. Sauf une qui m'a fait changer d'avis, j'ai enfin découvert une entreprise respectueuse de ses salariés, jeune, innovante.

Avec le recul quels enseignements tires-tu de cette aventure ?

Le logiciel libre est viable pour créer une entreprise, mais il faut au moins être deux selon moi, en tout cas dans le domaine de l'infogérance, car le freelance fait peur. Il faut beaucoup s'entourer, donc vivre dans une grande ville, avec une vraie culture du logiciel libre, participer à des événements, associations, etc.

Le co-working peut être une bonne solution également mais là aussi il faut y trouver son compte.

Les besoins liés aux logiciels libres dans le domaine de l'administration système sont souvent présents dans de grosses structures, ou des structures innovantes. Donc ne cherchez pas à vous installer n'importe où.

Pour ce qui est du choix du statut à privilégier lors de la création ou modification, il faut vraiment détailler votre activité à votre comptable, sans quoi on peut vite aller droit au mur.

Dans mon cas, l'une de mes plus grosses difficultés a été le manque d'échanges au quotidien (bien sûr il y Twitter, les forums), mais un admin sys a toujours besoin d'échanger au quotidien pour évoluer, demander de l'aide, etc.

Au sujet de la paperasse, j'utilisais Dolibarr pour mes devis et factures et j'exportais le tout en pdf pour le donner à ma comptable.

Comment as-tu rebondi professionnellement ?

Je travaille dans une petite entreprise d'informatique qui fait de la maintenance, en tant que technicien informatique (support niveau 2, administration système et réseaux). Je m'occupe à 50% de logiciels libres, 50% de logiciels propriétaires. J'ai été recruté grâce à mes compétences en OpenSource ; à ce jour j'ai déployé plusieurs solutions à base de logiciels libres en clientèle.

Tu travailles désormais dans un contexte mixte open/closed source. Quels sont les bons et mauvais côtés de ce contexte ?

Cela amène une polyvalence certaine, ce qui permet de mieux cerner certains besoins. Le logiciel libre n'est pas la solution miracle pour tous les besoins dans le monde de l'entreprise. Par contre il faut encore plus travailler pour accumuler d'autres compétences, ne pas perdre son acquis en logiciels libres.

Je dirais qu' à mon sens il n'y a que des bons cotés, ne serait-ce que pour mieux se "vendre" par la suite, comprendre les problématiques clientes lors du passage closed source/open ou inversement par exemple.

Les entrepreneurs disent souvent qu'ils ne reviendraient pour rien au monde au salariat. Toi, tu l'as fait. Cela t'apporte sans aucun doute un regard neuf sur le salariat en comparaison avec des personnes qui n'ont connu que ce statut. Que peux-tu en dire suite à ton expérience d'entrepreneur ?

Le salariat permet de faire uniquement de la technique, se concentrer 7h / jour sur ce que l'on fait. Cela apporte une tranquillité et de l'ouverture d'esprit, un salaire fixe, peu importe le niveau d'activité de l'entreprise.

De plus dans mon cas, cela m'a permis de revivre sur le plan humain, le fait de partager ces connaissances, de ne pas être seul face à une problématique.

L'entrepreneuriat est une très bonne école de la vie, j'ai beaucoup appris en seulement deux ans, j'ai côtoyé des personnes qui m'ont aussi fait grandir. Mais pour durer il faut savoir prendre des risques, faire autre chose que de la technique au quotidien, remettre en question sans cesse sa société.

Penses-tu te relancer dans l'aventure entrepreneuriale ? Si oui, dans le domaine du logiciel libre ?

Non, ce n'est pas envisagé… pour les 10 prochaines années en tout cas.

Compte-tenu de ton expérience, conseillerais-tu aujourd'hui à quelqu'un de se lancer dans la création d'entreprise ? Dans le domaine du logiciel libre ?

Oui assurément.

Il faut bien choisir le domaine d'activité. Par les temps qui courrent il y a plusieurs choix possibles :

• le low-cost,
• les niches,
• l'innovation,
• et la création d'activité à l'étranger,
• …

Peux-tu nous présenter rapidement ce que fait l'entreprise où tu travailles actuellement et pourquoi l'as tu choisie ?

• Maintenance de parc : serveurs et postes de travail (volume de 1 à plus de 20 serveurs) pour totaliser plus de 250 serveurs
• Audit et conseil
• Formation
• Développement

L'entreprise Suderiane me permet de m'épanouir techniquement, je mets en place diverses solutions OpenSource, je fais du support niveau 2 (ce qui permet d'être proche des clients), met en place des solutions propriétaires également, je migre des clients de solutions propriétaires vers du libre et inversement (selon leurs besoins).

Le libre n'est pas l'unique solution, quelques fois selon la nature du client, son budget, le temps qu'il a, une solution OpenSource peut être envisageable ou non.

Un dernier mot ? Une conseil ou une idée à partager ? une recette ?

Pour ceux qui veulent faire de la veille quotidienne en 30min il vous faut :

• un PC faible consommation (Zotac, Raspberry Pi et consort)
• un serveur web (LAMP classique)
• selfoss + une centaine de flux

Pour stocker / gérer vos mots de passe :

• Keepass 2 (multiplateforme)
• penser à chiffrer la mémoire virtuelle (dixit les derniers proof of concept)

Mon coup de cœur du moment : pfsense (firewall + proxy + routage avancé + vpn)

Mon dernier test : isowall (cloisonnement d'une machine pour qu'elle accède qu'au net)

Merci Daniel pour ce retour d'expérience. Bonne continuation à toi.

Télécharger ce contenu au format Epub

Lire les commentaires

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

• [Next INpact] Le blocage administratif des sites programmé pour février 2015
• [Côté Brest] Une médiathèque de poche
• [Les Echos] L'erreur fondamentale de Jeremy Rifkin
• [Maddyness] #Bordeaux: Ouverture de La Banquiz, le premier accélérateur des startups du logiciel libre
• [Le Monde.fr] «Il ne faut pas que les données personnelles soient échangées contre de la banane!»
• [Numerama] Le Parti Pirate nargue la justice. Amusant mais à double tranchant.
• [Next INpact] L'Assemblée nationale refuse à nouveau de surtaxer les ebooks avec DRM

• lien n°1 : April
• lien n°2 : Revue de presse de l'April
• lien n°3 : Revue de presse de la semaine précédente
• lien n°4 : Podcast

[Next INpact] Le blocage administratif des sites programmé pour février 2015

Par Marc Rees, le vendredi 12 décembre 2014. Extrait:

Selon nos informations, le gouvernement entend activer le blocage administratif à partir de février 2015 au plus tard. Le projet de décret est dans la boucle, mais il doit encore être notifié à Bruxelles, puisqu’il touche à la «société de l’information». Paris envisage maintenant une notification d’urgence afin de tenir ce calendrier.

Lien vers l'article original: http://www.nextinpact.com/news/91391-le-blocage-administratifs-sites-programme-pour-fevrier-2016.htm

[Côté Brest] Une médiathèque de poche

Par Pierre Gicquel, le mercredi 10 décembre 2014. Extrait:

Pensée et développée par les Chats cosmiques, une jeune association brestoise au poil, la CosmicBox est un mini ordinateur qui a plus d’un tour dans son sac.

Lien vers l'article original: http://www.cotebrest.fr/2014/12/10/une-mediatheque-de-poche

[Les Echos] L'erreur fondamentale de Jeremy Rifkin

Par Vincent Lorphelin, le mercredi 10 décembre 2014. Extrait:

L’économie du partage des ressources doit aussi inclure un partage des profits, ce qui ouvre une voie intermédiaire entre les économies associative et capitaliste: l’économie de l'utilité.

Lien vers l'article original: http://www.lesechos.fr/idees-debats/cercle/cercle-119788-lerreur-fondamentale-de-jeremy-rifkin-3-1073565.php

[Maddyness] #Bordeaux: Ouverture de La Banquiz, le premier accélérateur des startups du logiciel libre

Par Jennifer Padjemi, le lundi 8 décembre 2014. Extrait:

Alain Rousset, président de Bordeaux Unitec et François Pellegrini, président d’Aquinetic vont inaugurer prochainement La Banquiz. Nouvel arrivant dans le paysage des accélérateurs français, celui-ci se destine à l’attention des startups du secteur des logiciels libres en France. L’inauguration de ce lieu est prévue vendredi 12 décembre prochain au Cinéma Jean Eustache à Pessac.

Lien vers l'article original: http://www.maddyness.com/accompagnement/accelerateurs/2014/12/08/la-banquiz

Et aussi:

• [usine-digitale.fr] La Gironde se dote d’un accélérateur des start-up des logiciels et technologies libres
• [Aqui!] Aquinetic et Bordeaux Unitec s'associent pour créer la Banquiz

[Le Monde.fr] «Il ne faut pas que les données personnelles soient échangées contre de la banane!»

Par la rédaction, le lundi 8 décembre 2014. Extrait:

Les autorités européennes de protection des données personnelles – le «G29», dont le représentant français est la Commission nationale de l'informatique et des libertés (CNIL) – organisent lundi 8 décembre à Paris une conférence internationale consacrée à la protection des données personnelles: l'European Data Governance Forum, à suivre en direct vidéo et sur Twitter avec le mot-clé #EDGF14.

Lien vers l'article original: http://www.lemonde.fr/pixels/article/2014/12/08/il-ne-faut-pas-que-les-donnees-personnelles-soient-echangees-contre-de-la-banane_4536320_4408996.html

Et aussi:

• [Next INpact] Edward Snowden: «Veut-on sacrifier toute notre vie privée au profit de la sécurité?»
• [L'OBS] Protection des données privées: "Google semble prêt à des efforts"
• [01net.] Falque-Pierottin (Cnil): «La protection des données est un droit fondamental»
• [Next INpact] La CNIL et l'Inria vont révéler les indiscrétions d'Android
• [Numerama] Réformes numériques d'ici 2017: voici le programme complet!
• [Next INpact] Thierry Mariani, les hotspots Wi-Fi et la Hadopi… mettons les points sur les i

[Numerama] Le Parti Pirate nargue la justice. Amusant mais à double tranchant.

Par Guillaume Champeau, le lundi 8 décembre 2014. Extrait:

Le Parti Pirate a annoncé la création d'un nouveau site miroir pour donner l'accès à The Pirate Bay, démontrant l'inutilité pratique du jugement du 4 décembre dernier. Mais cette provocation pourrait se retourner contre lui, et donner du grain à moudre aux partisans d'une automatisation des procédures judiciaires en matière de blocage de sites internet.

Lien vers l'article original: http://www.numerama.com/magazine/31523-le-parti-pirate-nargue-la-justice-amusant-mais-a-double-tranchant.html

Et aussi:

• [Framablog] Qui agit pour nos libertés numériques?
• [Next INpact] Le blocage de The Pirate Bay déjà contourné par le Parti Pirate français
• [Next INpact] Enjeu de lourds intérêts, le blocage d'Allostreaming sera rejugé fin 2015
• [Next INpact] La guerre de Fleur Pellerin contre le «piratage de masse» reportée à 2016?

[Next INpact] L'Assemblée nationale refuse à nouveau de surtaxer les ebooks avec DRM

Par Xavier Berne, le lundi 8 décembre 2014. Extrait:

Alors que la France pourrait bientôt être condamnée par la justice européenne à cause de la TVA réduite dont profitent tous les ebooks, les députés écologistes proposaient de trouver une sortie de secours en n’appliquant ce taux de 5,5 % qu’aux seuls livres numériques dépourvus de verrous (DRM). Mais sans grande surprise, le gouvernement et les parlementaires s’y sont opposés.

Lien vers l'article original: http://www.nextinpact.com/news/91279-l-assemblee-nationale-refuse-a-nouveau-surtaxer-ebooks-avec-drm.htm

Télécharger ce contenu au format Epub

Lire les commentaires

Glances permet de juger l'état de sa machine, ou d'une machine distante, à l'aide d'un tableau de bord en mode console/terminal ou Web. La version 2.2 a été mise en ligne et apporte son lot de nouveautés que nous allons parcourir ensemble dans cette dépêche:

• installation simplifiée ;
• centralisation de la supervision de vos machines à partir d'un mode "super client" ;
• amélioration de la fonction de graphe ;
• nouvelle fonction de tri des processus ;
• amélioration de l'interface console/terminal.

• lien n°1 : Site officiel (Github)
• lien n°2 : Articles sur le blog de l'auteur

Simplification de l'installation

En plus, des classiques installations via Pypi et par paquet (Debian, Fedora, Arch Linux, Mac OS…), il est maintenant possible d'installer et de mettre à jour Glances à partir d'un script. Il suffit donc de saisir les commandes suivantes dans un terminal:

curl -L http://bit.ly/glances | /bin/bash

Introduction au mode browser ("super client")

Jusqu'à cette version 2.2, Glances pouvait superviser la machine hôte avec la commande:

$ glances

ou superviser une machine distante (serveur Glances ou démon SNMP si le serveur Glances n'est pas trouvé) avec:

$ glances -c <hostname>

De nombreux utilisateurs l'ayant demandé, une amélioration de ce dernier mode a été introduite. Elle permet de superviser plusieurs machines distantes à partir d'un même client. Pour cela, il suffit de lancer, sur le client, la commande:

$ glances --browser

Ainsi, Glances va se mettre en écoute des serveurs Glances disponibles sur son réseau local et en afficher une liste:

La déclaration automatique des serveurs Glances sur le réseau est faite à partir du protocole multicast Zeroconf, il est donc limité aux réseaux locaux. En plus de ce mode automatique, il est possible de déclarer statiquement les machines à superviser en utilisant le fichier de configuration de Glances (voir ici, un exemple de déclaration).

Note: cette nouvelle fonction est encore à l'état expérimental et sera améliorée dans les prochaines versions. N'hésitez par à remonter les demandes d'améliorations sur le dépôt officiel du projet.

Faire des graphes de ses statistiques

Introduite dans la version 2.1, la fonction de graphe permet de générer des fichiers contenant les courbes des principaux indicateurs disponible dans Glances (CPU, MEM, LOAD, Net IO…). L'empreinte mémoire de Glances étant plus importante quand cette fonction est utilisée, il faut préciser le paramètre suivant au lancement de Glances pour l'activer:

$ glances --enable-history --path-history /tmp

Glances va alors se lancer en conservant en mémoire les statistiques écoulées. L'appui sur la touche 'g' générera les fichiers (au format PNG) dans le répertoire demandé (/tmp). La touche 'r' (reset) permet de remettre à zéro cette mémoire.

Les prochaines versions de Glances se focaliseront sur les interfaces externes vers des services de logs/graphes existants (voir la fiche suivante), notamment Influxdb, Statsd et Rsyslog.

Nouvelle fonction de tri des processus

Il est maintenant possible de trier les processus en fonction de la colonne CPU times (touche 't') qui donne un bon indicateur de la consommation CPU d'un processus.

Il est également possible de masquer la barre de statistique de gauche pour donner plus d'espace au processus (en pressant la touche '2').

Amélioration de l'interface console/terminal

D'autres petites améliorations de l'interface Curse, avec l'apparition de la touche 'F' au niveau du greffon système de fichiers, pour forcer l'affichage de l'espace disponible (en lieu et place de la taille occupée) et l'affichage de statistiques étendues (CPU affinity, open threads et network IO…) pour le processus en haut de la liste avec la touche 'e' (en minuscule).

Conclusion

En plus de ces nouvelles fonctions, Glances 2.2 corrige un bon nombre de problèmes et grâce à la contribution d'Alessio Sergi et de Maxime Desbrus, une optimisation du code a également été effectuée. Ainsi Glances 2.2 consomme moins de CPU que les versions précédentes.

Pour finir, le projet est toujours à la recherche de contributeurs, notamment pour les passerelles vers les services de logs présentées dans cette dépêche. N'hésitez pas à contribuer !

Télécharger ce contenu au format Epub

Lire les commentaires

Ce mardi 9 décembre 2014, le projet Fedora a annoncé la sortie de la distribution GNU/Linux Fedora 21 ainsi qu’une nouvelle version du site web. La version 20, sortie il y a un an, coïncidait avec les dix ans d'existence de Fedora. La raison pour laquelle la version 21 a pris plus de temps pour sortir est dû à l'initiative Fedora.next, qui est une réorganisation profonde du projet, pour réfléchir sur les dix prochaines années.

Pour rappel, Fedora est une distribution GNU/Linux communautaire développée par le projet éponyme et sponsorisée par l’entreprise Red Hat, qui lui fournit des développeurs ainsi que des moyens financiers et logistiques. Fedora peut se voir comme une sorte de vitrine technologique pour le monde du logiciel libre, c’est pourquoi elle est prompte à inclure des nouveautés. Tous les détails dans la suite de la dépêche.

• lien n°1 : Les notes de versions en anglais
• lien n°2 : Fedora.Next
• lien n°3 : Site officiel du Projet Fedora
• lien n°4 : Site officiel du Projet Fedora
• lien n°5 : Site de la communauté francophone de Fedora
• lien n°6 : Torrents pour Fedora 21
• lien n°7 : Projet Atomic
• lien n°8 : DLFP : Fedora 20, dite Heisenbug, est disponible et le Projet Fedora fête ses 10 ans !

Sommaire

• Les produits
  • Fedora Workstation
  • Fedora Server
  • Fedora Cloud
  • Fedora Atomic Host
• Changement de modèle de gouvernance
• Nouvelles versions des principaux logiciels
  • Environnements bureautiques
    • Gnome
    • KDE
    • Mate
    • Sessions Gnome sous Wayland
  • systemd
  • Sécurité
  • Développement

Fedora garde un rôle central dans le développement de ces nouveautés, via le développement en amont. En effet, les développeurs de la distribution contribuent également au code d’un certain nombre de logiciels libres contenus dans la distribution, dont le noyau Linux, GNOME, NetworkManager, PackageKit, PulseAudio, X.Org, la célèbre suite de compilateurs GCC et bien d'autres.

Par ailleurs, les distributions telles que RHEL, CentOS ou Scientific Linux (plus indirectement) sont développées à partir d’une version de Fedora et mises à jour environ tous les trois à cinq ans.

Les produits

Une des grandes nouveautés de cette version est la séparation de la distribution en trois produits : Workstation, Server et Cloud. Chacun de ces produits est construit sur la base commune de paquets de Fedora et utilise le même noyau, le même installeur, le même gestionnaire de paquets, etc. Les produits sont des installations spécialisées, ayant des objectifs différents.

Fedora Workstation

Fedora Workstation fournit l'environnement de bureau GNOME (version 3.14), qui est facile à utiliser et minimise les distractions, pour pouvoir se concentrer sur son travail. Il est, par exemple, possible de désactiver les notifications, pour pouvoir les lire à un moment plus opportun.

Le public cible de Fedora Workstation sont les développeurs, administrateurs systèmes et étudiants en informatique, bien qu'il puisse convenir aussi pour un public plus large. Les développeurs vont pouvoir apprécier un environnement configuré pour leurs besoins qui fournit des outils comme DevAssistant.

Fedora Workstation permet, par défaut, une détection de portails captifs. Si la demande du portail est reconnue, une fenêtre apparaît automatiquement pour vous permettre de vous authentifier vis-à-vis de la page web du portail.

Les développeurs font souvent tourner des serveurs de test qui s'exécutent sur des ports réseaux élevés (dont le numéro est supérieur à 1024) et l'interconnectivité avec de nombreux appareils de consommation modernes exige également ces ports. Le pare-feu dans Fedora Workstation, firewalld, est configuré pour permettre ces accès. Les ports inférieur à 1024, à l'exception de sshd et les clients pour la samba et DHCPv6, sont en revanche, bloqués.

Reportez-vous à la documentation sur firewalld pour plus de détails sur la personnalisation de la configuration du pare-feu ou installer le paquet firewall-config pour un outil graphique.

Fedora Server

Cette version est prévue pour utiliser Fedora comme serveur web, serveur de fichiers, serveur de base de données ou comme plate-forme d'Infrastructure as a service. Utilisant systemd pour optimiser le démarrage du système et déployant du LVM pour rendre plus flexible le partitionnement, Fedora Server vise à simplifier des tâches complexes telles que le SSO ou l'utilisation authentifiée à des services réseaux.

Deux grosses nouveautés : les fonctionnalités d'administration de serveur et le rôle de contrôleur de domaine. En effet, Fedora Server peut déployer un contrôleur de domaines géré par FreeIPA.
Trois outils sont disponibles pour administrer vos serveurs : Cockpit, Rolekit et OpenLMI.

Cockpit est une interface web puissante et facile à prendre en main qui permet de gérer plusieurs serveurs GNU/Linux.
Rolekit permet de déployer des rôles d'installation. Un rôle est un ensemble de logiciels qui correspond à une et une seule tâche système, par exemple « serveur web ».
OpenLMI fournit une API de gestion de serveurs à distance.

Fedora Cloud

Cette version inclut par défaut les outils permettant de l'utiliser sur des environnements de Cloud privés ainsi que ceux pour Amazon ou pour faire tourner des conteneurs Docker. Fedora Cloud est une version réduite de la distribution, afin que celle-ci prenne le moins d'espace disque possible. Il est possible de convertir une instance Fedora Cloud en Fedora Server.

Fedora Atomic Host

Il y a également l'apparition d'une image Fedora Atomic utilisant rpm-ostree pour gérer les mises à jour de manière atomique. Cela se combine avec Docker pour permettre un déploiement facile d'applications via des conteneurs sous Fedora

Changement de modèle de gouvernance

Suite aux discussions qui ont eu lieu durant la dernière conférence Flock à Prague en août 2014, le projet Fedora s’est doté d'une nouvelle forme de gouvernance. Celle-ci inclut des représentants des groupes (Engineering, Outreach) responsables de la version, des membres élus et un conseiller pour la diversité.

Nouvelles versions des principaux logiciels

Le noyau Linux passe à la version 3.17. Mais Fedora met à jour assez rapidement la version du noyau, même pour une même version de Fedora. Donc la mise à jour vers Linux 3.18 devrait bientôt arriver.

Environnements bureautiques Gnome

GNOME, l’environnement de bureau par défaut de Fedora, passe de la 3.10 à la 3.14. Ce saut permettra d'ajouter la gestion des écrans à haute-résolution, des écrans tactiles multi-touch ou encore une gestion préliminaire de Wayland, dans l'objectif de remplacer le serveur graphique X.org. Les développeurs de GNOME continuent de peaufiner leur environnement graphique. Ainsi, Evince a été remanié pour s'intégrer davantage dans GNOME 3.14 et l'application Photos peut maintenant s'interfacer avec les services et les serveurs de Google. Le contenu des terminaux gnome-terminal peut maintenant être recherché dans GNOME Shell.

En parallèle, le gestionnaire d'applications Software a été profondément remanié et apporte une meilleure intégration au système. Nous pouvons noter l'apparition des applications de gestion des journaux systèmes, d’un client IRC Polari ou encore d'un enregistreur audio. Cette mise à jour est clairement sous le signe de la maturation du projet GNOME.

Bien que Fedora Workstation soit basé sur GNOME, les autres environnements de bureau sont toujours disponibles dans Fedora. Il existe toujours les différentes Spins, qui sont des variantes un peu moins officielles (les développeurs se focalisent plus sur les trois produits de base).

KDE

KDE n'est pas en reste : mise à jour vers KDE 4.14, SDDM remplace par défaut KDM en tant que gestionnaire graphique de connexion (KDM est toujours disponible via les dépôts logiciels) L'outil de configuration du bureau peut désormais être complété par un utilitaire graphique de configuration pour systemd, logind & journald. La configuration du pavé tactile a été entièrement revue vers la simplicité d'usage. Dolphin, le gestionnaire graphique de fichiers, suit désormais son terminal, et vice-versa : les déplacements dans une arborescence sont synchrones entre les deux.

C'est aussi l'occasion de proposer en avance KDE Framework 5. En somme, toutes les bibliothèques de KDE peuvent exploiter notamment la bibliothèque Qt5, qui est la principale évolution de cette gamme logicielle. À des fins de stabilité et de compatibilité, cet ensemble est installable en même temps que KDE Framework 4.

Mate

Pour les nostalgiques de l'ère GNOME 2, MATE passe en version 1.8. Tout d'abord elle s'intègre mieux au système avec la gestion de upower 1.0 pour la gestion d'énergie mais aussi à PulseAudio pour la gestion du son ou encore systemd-logind pour la gestion des sessions. Le gestionnaire de fenêtre Marco se fait plus flexible avec la prise en charge d'un léger tiling et snapping. L'aide utilisateur a été remaniée et quelques effets graphiques supplémentaires pointent le bout de leurs nez, notamment pour l'extinction de l'appareil. Attention, beaucoup de noms de paquet sous la forme mate-function ont changé en faveur du nom du programme. Par exemple, mate-file-manager devient caja.

Sessions Gnome sous Wayland

Afin de confirmer son statut de vitrine technologique du Logiciel Libre, Fedora 21 apporte la gestion de sessions GNOME entièrement sous Wayland. Bien entendu cette gestion se fait en parallèle de la version pure X11, le passage de l'un à l'autre se faisant au lancement de la session sur GDM. Cela ne fonctionne que pour les applications GNOME, les autres programmes auront souvent des comportements erratiques. L'objectif est d'améliorer la prise en charge des pilotes, des applications et de remonter beaucoup de problèmes auprès des différents projets, le tout pour faire avancer plus rapidement ce chantier de longue haleine.

systemd

Systemd a été mis à jour vers la version 215. Cette version contient énormement d'améliorations, notamment pour la gestion des services tournant dans des conteneurs. On pourra aussi découvrir systemd-networkd, permettant de gérer des configurations d'interfaces réseaux via systemd.

Sécurité

SSSD (System Security Services Daemon) permet désormais l'usage des GPO (Group Policy Objects, de type authentification locale et distante, services et plus), lorsque Fedora est utilisé dans un environnement Active Directory. Ceci n'affecte pas les autres usages de SSSD (cas d'usage IPA, par exemple) et étend les possibilités de contrôle d'accès par un A.D. Chaque GPO peut bénéficier d'une configuration via PAM, permettant aux administrateurs d'utiliser un outil maîtrisé.

Les certificats signés avec MD5 sont désormais rejetés, cet algorithme est considéré comme non sécurisé. L'ensemble des bibliothèques de chiffrement de Fedora est mis à jour en ce sens. Bien que peu utilisé sur Internet, ce type de certificats se rencontre encore dans des réseaux privés. Fedora recommande de passer sur SHA256 ou au moins sur SHA1. Une variable d'environnement (openssl_md5_enable_verify) peut cependant être positionnée afin de valider un certificat encore signé avec MD5.

Développement

Un assistant au service des développeurs permet de démarrer sereinement un projet C, C++, Ruby, Python, NodeJS, Java… en préparant un environnement (il propose de configurer un Vim spécifique pour ce projet, par exemple) ; mais aussi une cible Docker ou GitHub. Des « sous-assistants » sont disponibles, par exemple : « Django pour Python ». DevAssistant est proposé en outil console et en outil graphique.

PHP a été mis à jour pour Fedora 21. Vous trouverez ainsi la version 5.6 et toutes les nouveautés qui vont avec. L'ensemble des applications PHP fournies par la distribution ont été testées avec cette version.

Python 3.4 a été intégré afin que les utilisateurs de Fedora puissent profiter des améliorations qu'il apporte. De nouvelles bibliothèques Python apparaissent dans la distribution. Attention, la version de Python par défaut reste la 2.7 et non python3.

L’environnement Java est mis à jour avec la version OpenJDK 8. Les versions OpenJDK 7 ne seront plus disponibles, afin de simplifier la maintenance. L'effort pour maintenir deux version de Java, en parallèle comme dans Fedora 20, étant jugé trop important, pour un gain relatif.

Make 4.0 est désormais fourni. L'ensemble des paquets est construit en utilisant cette version.

Boost 1.56 Uplift est disponible. Les paquets utilisant Boost ont tous été reconstruits pour garantir la cohérence. À noter aussi : Boost.Build v2 est désormais utilisé pour construire le paquet.

GCC 4.9 est utilisé. Comme nouvelles fonctionnalités, il y a notamment C++14, OpenMP 4.0, la prise en charge de SIMD améliorée, etc.

Ruby 2.1 et Ruby On Rails 4.1 pour les utilisateurs de ce langage de script et pour les développeurs web.

Télécharger ce contenu au format Epub

Lire les commentaires

LinuxConsole est une distribution qui existe depuis plus de dix ans. Il faut comprendre "LinuxConsole" comme « Utiliser Linux aussi simplement qu'une console de jeu ». Ce fut le premier LiveCD avec l'accélération graphique fonctionnant de base par défaut.

Cette version (2.3) s'est un peu éloignée de ce concept, mais elle propose quand même de nombreux jeux ; le nom est donc resté, faute de mieux ;) Tout est fait pour qu'on puisse jouer facilement (accélération graphique et manettes devant fonctionner de suite), mais des programmes « classiques » sont aussi disponibles.

Cette distribution est principalement utilisée pour « recycler » des anciens ordinateurs (sous Windows XP/Vista/Seven), avec un système rapide, complet et peu gourmand en mémoire vive.

Les modes d'utilisation sont multiples :

• LiveCD ;
• LiveUSB (avec persistance de données) ;
• Installation à côté de Windows (Windows boot loader) ;
• Installation sur un disque dur vierge, dual boot utilisant Grub.

La seconde partie de la dépêche contient des informations plus techniques.

• lien n°1 : linuxconsole.org

De LinuxConsole 2.0 à LinuxConsole 2.3

LinuxConsole passe directement de la version 2.0 à la version 2.3, le numéro de version étant défini pour l'outil de génération de distribution Dibab. Les sorties « binaires » 2.1 et 2.2 étaient pour Albatros, une distribution cousine. Pour éviter la profusion des noms, AlbatrOS fusionne avec LinuxConsole (il ne devrait plus y avoir de sorties d'AlbatrOS).

Programmes présents dans cette version

• langues : français / anglais / espagnol / allemand / portugais / breton (!) ;
• bureau LXDE ;
• gestionnaire de réseaux Network Manager ;
• gestionnaire de fichiers Pcmanfm ;
• VLC ;
• gparted ;
• galculator ;
• evince ;
• xfburn ;
• audacious ;
• gestionnaire d'impression (cups).

Les jeux présents sur l'ISO Les jeux libres vs les jeux gratuits pour tablettes / Smartphones

On pourrait penser que les jeux gratuits pour tablettes / Smartphones sont plus « intéressants » que des jeux libres, parfois vieillots. Mais à bien y réfléchir, ces jeux « gratuits » contiennent soit des plateaux payants, soit des logiciels de récupération de données personnelles et dont le gameplay est assez léger.

Voici donc la liste des jeux du module linuxconsole (fichier squashfs)

• gcompris ;
• Aisleriot ;
• foobillardplus ;
• armagetronad ;
• ltris ;
• astromenace ;
• neverball.

Les applications installables par Internet

• Steam ;
• hedgewars ;
• 0ad ;
• openttd ;
• extremetuxracer ;
• xmoto ;
• xonotic ;
• Libreoffice ;
• mplayer ;
• warsow ;
• wine ;
• playonlinux ;
• …

Une fonctionnalité intéressante : un « apt-get » maison permet d'installer des binaires Debian, même si tous les paquets de l'ISO ont été compilés avec Dibab. Parmi les paquets testés, ont peut citer lmms, atris, et billard-gl.

Un liveCD/USB « jeux LinuxFr.org »

Un liveCD/USB « LinuxFr.org » est en préparation en collaboration avec l'association LanPower. C'est un CD composé d’œuvres de contributeurs au site Linuxfr.org dont on peut trouver une liste de jeux sur le wiki LinuxFr.org. Il a pour vocation de fournir un support de promotion de ces jeux, mais ce peut être aussi un outil de test rapide. Ce CD n'est pas destiné à être vendu, parce qu'il comporte des jeux sous forme de prototypes non finis.

Nouveautés Sources et patches Arch Linux

Depuis le début (version 2.0), certains binaires sont générés à l'aide des patches de Debian (notamment lorsque le code source original est ancien), mais j'avais de plus en plus tendance à aller voir du côté d'Arch Linux (je trouve que leurs paquets source sont bien plus faciles à lire).

Sources

Du coup, on peut maintenant mettre en entrée du fichier list-$ARCH ou list-$MODULE une référence à l'URL d'un paquet (Ex : archlinux:armagetronad, qui ira prendre l'archive adéquate).

Patches

En utilisant le format 'archlinuxpatched:sdl', la version actuelle de SDL pour ARCH sera récupérée et les patches ARCH pour SDL seront appliqués avant la compilation.

Version 64 bits

La version 2.0 était sortie en 32 bits, cette version propose aussi une version 64 bits. Par contre, la version 64 bits (estampillée beta) ne supporte pas le multi-lib, Steam n'est donc disponible qu'en utilisant la version 32 bits.

Installation sur un disque vierge

Lors de la sortie de LinuxConsole 2.0, l'annonce avait été partagée sur ce forum. Il en était ressorti une surprenante mauvaise image de Wubi. Un fork a donc été développé pour qu'on puisse facilement installer LinuxConsole 2.0 sur Windows. Il est aussi possible de l'installer via gparted/grub.

Nouveau navigateur intégré : Qupzilla

Après avoir sélectionné Midori sur les versions 2.1 et 2.2 d'AlbatrOS, nous avons choisi Qupzilla comme navigateur internet intégré. En effet, il associe la rapidité et le rendu correct de sites Internet modernes.

Mises à jour

• Noyau Linux : 64 bit-> 3.17.5, 32 bits -> 3.14.26 ;
• Xorg : 1.16.2 ;
• Mesa : 10.2.9.

Raspberry Pi

Il n'y a toujours pas de version « binaire » disponible, on peut compiler un noyau et un système de fichiers en choisissant raspi (cible Raspberry Pi réel) ou raspi-qemu (cible Raspberry pi émulé) au moment du make de dibab.

Une implémentation de Wayland devrait être disponible pour la version 2.4

La compilation croisée n'étant pas totalement satisfaisante, il est envisagé d'essayer distcc.

Télécharger ce contenu au format Epub

Lire les commentaires

Dotclear le moteur de blog libre, distribué sous licence GNU GPL v2, sort en version 2.7 sous le nom de code Currywurst.

La version 2.6 est sortie il y a maintenant 13 mois. Voici la suite ! La version 2.7 est moins spectaculaire que la version 2.6 mais elle apporte tout de même des changements significatifs côté administration et côté public.

• lien n°1 : Télécharger Dotclear
• lien n°2 : Site web de Dotclear
• lien n°3 : Définition du clickjacking
• lien n°4 : Les templates Dotclear

Un nouvel éditeur WYSIWYG et du HTML5 côté administration mais aussi côté visiteur. Administration

Un nouvel éditeur (basé sur CKEditor) a été intégré. Il devrait réglé des petits problèmes liés à l'intégration de vidéos externes notamment. L'ancien éditeur est toujours présent. Comme il existe plusieurs éditeurs, les préférences utilisateurs permettent de choisir l'éditeur pour chaque syntaxe supportée (HTML, Wiki, Markdown…)

D'autre part, la partie administration est passée à HTML5. Côté accessibilité, les rôles ARIA principaux ont été intégrés.

Côté public

Côté public, les modèles de pages (templates) sont aussi passés en HTML5. Le moteur de templates a été modifié et permet le choix d'un jeu de templates et l'héritage de templates. Du coup deux jeux de templates sont livrés avec cette nouvelle version de Dotclear :

• un nommé mustek, semblable au jeu de template des versions précédentes. Il est utilisé par défaut ;
• un nommé currywrust, utilisant l'héritage des templates. Il est utilisé par le nouveau thème par défaut : Berlin.

Comme pour la partie administration, les principaux rôles ARIA ont été ajoutés.

Divers

• protection activable contre le clickjacking ;
• les sons et les vidéos utilisent désormais les tags HTML 5 ;
• drag'n'drop sur écran tactile ;
• de nombreuses corrections de bugs.

Si votre hébergeur le permet, vous devriez voir apparaître la proposition de mise à jour vers cette version depuis votre interface d'administration.

Le paquet Debian de Dotclear, pour la version 2.7 ne devrait pas tarder à rejoindre les dépôts officiels.

Télécharger ce contenu au format Epub

Lire les commentaires

Simple and Fast Multimedia Library (SFML) est une bibliothèque C++ destinée à faciliter le développement d'applications multimédia et en particulier de jeux vidéo. Elle intègre à la fois les éléments graphiques, le réseau, la gestion des sons et la gestion des fontes. Cette bibliothèque est disponible sur les principaux systèmes d'exploitation et, en particulier, votre préféré.

Le 7 décembre est sortie la version 2.2, soit un an et demi après la version 2.1. Cette nouvelle version apporte quelques nouvelles fonctionnalités, dont la prise en charge d'Android et iOS et la correction de nombreux bugs.

• lien n°1 : Sur LinuxFr.org : Bibliothèque SFML version 2.1
• lien n°2 : Simple and Fast Multimedia Library
• lien n°3 : SFML sur github

SFML est une bibliothèque comparable à Simple DirectMedia Layer (SDL). Au niveau des différences, SDL est en C alors que SFML est en C++ ; SDL offre une API un peu plus bas niveau que SFML ; SDL est uniquement consacré à la partie graphique, mais il existe des bibliothèques annexes qui permettent d'avoir les mêmes fonctionnalités que SFML (SDL_ttf, SDL_image, SDL_net).

Nouveautés de SFML 2.2 Une nouvelle équipe

Depuis SFML 2.1, l'équipe de développement s'est enrichie. D'un seul développeur, Laurent Gomila, on est passé à une équipe, principalement des développeurs qui utilisent beaucoup SFML et qui ont développé des bibliothèques d'extensions. On peut citer :

• Jan Haller alias Bromeon qui a développé la bibliothèque Thor et qui s'occupe du port OSX ;
• Marco Antognini qui a développé sftools et qui s'occupe du port Android ;
• binary1248 qui a développé Simple and Fast Utility Network Library (SFNUL) ;
• Stefan Schindler alias TankOs qui a développé SFGUI ;
• Jonathan De Wachter alias Sonkun qui a développé beaucoup de bindings Python vers toutes ces bibliothèques.

Port Android et iOS

Il est maintenant possible d'utiliser SFML sur ces deux plateformes mobiles. C'est la première version qui le permet et il faut donc s'attendre à quelques bogues.

Compilation et outillage

Plusieurs chaînes de compilation sont maintenant prises en charge (en plus de celles déjà existantes) :

• compilateurs de Debian/kFreeBSD ;
• VS2013 sur Windows.

De même, le nom des système d'exploitation et des compilateurs est désormais plus clair dans les fichiers CMake.

Dans les sous-systèmes…

Dans le sous-système System, la classe sf::String permet maintenant de convertir depuis et vers n'importe quel codage UTF. Elle gagne également deux méthodes, remplacement et sous-chaîne. La classe sf::Time gagne les opérateurs modulo et division.

Dans le sous-système Window, il est désormais possible de vérifier et demander le focus sur la fenêtre. La classe sf::Joystick expose désormais des données sur le matériel : nom, identifiant du fabricant, identifiant du produit.

Dans le sous-système Graphics, la classe sf::Font expose beaucoup plus d'informations qu'auparavant. Elle fait maintenant ses calculs avec des flottants à la place d'entiers, pour une meilleure précision, notamment pour le souligné. La classe sf::Color gagne un opérateur de soustraction. Et surtout, un nouveau système plus flexible pour le blending est mis en place.

Dans le sous-système Audio, les principales améliorations concernent la capture de son.

Dans le sous-système Network, la classe sf::Http a gagné la prise en charge de PUT et DELETE. Les entiers 64 bits sont maintenant gérés par la classe sf::Packet. Et la classe sf::Ftp permet d'envoyer des commandes directement.

Conclusion

Sans apporter de révolution, cette version consolide l'existant. Le portage de la version 2.1 à la version 2.2 devrait se passer dans d'excellentes conditions. Il faut noter qu'il n'y a pas encore eu de sortie officielle, juste un tag sur github. En particulier, la documentation n'est pas encore en ligne, mais devrait arriver dans les prochaines semaines.

SFML 3

Des discussions sur SFML3 ont commencé et vont se poursuivre. L'idée est de voir ce qui manque à SFML et qui ne peut pas être implémenté facilement en utilisant SFML. Le débat riche a déjà amené quelques idées intéressantes comme :

• la prise en charge de C++11, éventuellement optionnelle
• la lecture de vidéo (même si l'auteur principal n'est pas très chaud à cette idée au vu des dépendances)
• meilleure séparation de la partie fenêtre et de la partie graphique, avec un contexte graphique bien à part (un peu comme SDL)
• intégration de bibliothèques d'extension (même si l'idée ne fait pas l'unanimité) :
  • Thor : une extension pour gérer les animations, les systèmes de particules, les grandes textures, etc.
  • 3DEE : une extension pour faire de la 3D (avec une implémentation par un des membres de la nouvelle équipe).

Aucune date n'est annoncée pour l'instant, évidemment. Mais ce fil de discussion montre le dynamisme autour de cette bibliothèque qui reste une valeur sûre quand on développe des jeux 2D simples en C++.

Télécharger ce contenu au format Epub

Lire les commentaires

Le 8 décembre 2014, la version 4 de Seafile est sortie. Cette solution d'hébergement et de synchronisation de fichiers (à la Dropbox, Google Drive, OwnCloud, pour ne citer qu'eux), publiée sous licence GPL3 s'enrichit ainsi de deux nouvelles fonctionnalités :

• le support de la synchronisation sur HTTP/HTTPS ;
• une nouvelle interface de consultation des fichiers depuis le client (Cloud file browser).

Si vous ne connaissez pas Seafile, je vous invite à faire un tour dans les liens.

• lien n°1 : Site officiel
• lien n°2 : Démo publique
• lien n°3 : Annonce de la version 4
• lien n°4 : Dépêche LinuxFr.org de la version 3
• lien n°5 : Documentation
• lien n°6 : Seafile avec Docker

Synchronisation sur HTTP/HTTPS

Auparavant, la synchronisation passait par un protocole maison sur des ports peu conventionnels, ce qui pouvait être un facteur bloquant pour certains déploiements, par exemple derrière des pare-feux trop restrictifs. Cette nouvelle fonctionnalité permet donc de s'affranchir de cet obstacle.

Si les questions de sécurité vous préoccupent, la possibilité d'utiliser HTTPS en lieu et place de l'ancien protocole est également une bonne nouvelle, puisqu'on est sur quelque chose de beaucoup plus standard en matière de chiffrement.

Pour le moment, la fonctionnalité n'est pas activée de base sur le client, il faut se rendre dans les paramètres et l'activer manuellement. À terme, elle deviendra l'option par défaut.

Cloud file browser

Cette nouveauté concerne les clients de Seafile pour bureau, dont les nouvelles versions sont publiées au même rythme que celles du serveur.

Auparavant, pour accéder sur un ordinateur aux fichiers d'une bibliothèque non synchronisée sur ce terminal, il fallait passer par l'interface web de Seafile ou par WebDAV. Avec le cloud file browser, il est désormais possible d'interagir avec une bibliothèque non-synchronisée directement depuis le client Seafile, le tout sans la télécharger. Parmi les actions disponibles, on trouve par exemple l'envoi, le téléchargement, la mise à jour ou la suppression d'un fichier, la création d'un lien de partage, le renommage, …

Autres nouveautés

Cette nouvelle version majeure a également été l'occasion d'améliorer certaines choses :

• Côté serveur, le temps d'affichage de certaines pages de l'interface web a été réduit, l'ergonomie de l'outil d'envoi de fichier a été revue, et on peut désormais de fixer une date d'expiration pour les liens de partages.
• Côté client, on retiendra la possibilité de filtrer les bibliothèques par nom (pratique quand on en a beaucoup).

Conclusion

On ne trouve donc pas de fonctionnalité révolutionnaire dans cette nouvelle version, mais un certain nombre d'ajouts sympathiques qui viennent compléter ce qui était déjà présent dans les versions antérieures. Seafile atteint une maturité certaine et constitue une alternative sérieuse et performante face aux solutions de synchronisation existantes.

Si vous avez un bout de serveur sous la main, c'est peut-être le moment d'essayer !

Télécharger ce contenu au format Epub

Lire les commentaires

CatchChallenger est un jeu de rôle indépendant en ligne, massivement multijoueur (MMORPG), à l'ancienne, libre, publié sous licence GNU GPL v.3 aussi bien pour le code que pour les données artistiques et le site web.

La base du jeu est un mélange de différents styles : combat, farming, exploration, fabrication, commerce, gestion, compétition. Les travaux se sont concentrés sur la jouabilité, les performances et la créativité.

Cette version totalise plus de 5 Mo de code, plus de 1 700 commits sur 3 ans de vie (sur les différentes parties du projet). Le client et le serveur sont développés sous GNU/Linux, puis automatiquement empaquetés pour OS X et Windows.

• lien n°1 : Site officiel
• lien n°2 : Boutique
• lien n°3 : Feuille de route

Améliorations depuis la dernière version

La sécurité et l'anonymat ont été améliorés (dissimulation des dates des fichiers du serveur).

La vérification de la clef publique a été changée, cela permet de voir s'il y a eu détournement DNS/routage — et c'est transparent pour l'utilisateur (l'équivalent de known_hosts + StrictHostKeyChecking no pour SSH).

La réactivité et les possibilités pour le contenu du jeu ont été améliorées, dont le fait de mettre des objets sur la carte.

Un algorithme de recherche de chemin (path finding) d’un nouveau genre a été développée spécialement pour le jeu (je n'ai trouvé aucun jeu qui avait ces besoins), mais désactivé pour cause de bugs.

Si quelqu'un a les paquets utiles pour sa distribution et la démarche de compilation pour le jeu, je pourrai le mettre dans le README.

L'amélioration de la bande passante pour le téléchargement du datapack et la détection des miroirs corrompus (donc pas besoin de leur faire confiance), permettent la réduction des coûts.

Des technologies, techniques et algorithmes ont été développés (Aperçu des technologies), suite aux analyses et recherches, des innovations ont vu le jour.

Les outils annexes basiques pour le projet sont présents comme les tests cases, un tracking des performances par commit, le Git/issues, des zones communautaires, l'exploration depuis le site du contenu (dont le convertisseur de map vers le format .png), tous les scripts d'automatisation, les grabbers et convertisseurs divers pour importer le contenu d'autre jeu à titre d'exemple.

Le projet est toujours à la recherche d'aide pour le client, un seul des points suivants est demandé :

• Un développeur QtQuick2 (portage QtQuick1 d'un code et adaptation des binding C++) ;
• Un développeur HTML5/Websocket/WebGL.

Le futur

J'ai posté une feuille de route pour la partie développement qui s'étale sur trois ans, si les rentrées d'argent suivent.

Pour l’utilisateur final

Un nouveau wiki sera mis en place sur l'univers du jeu, avec les données générées du datapack, cela remplacera le datapack explorer et permettra d'ajouter des données arbitraires (histoire, photo, dessin, commentaire…).

Le client recevra diverses améliorations (navigation uniquement au clavier, à la souris, peut-être au joystick), diverses améliorations de l'interface (dont une série d'animations qui la rendra plus sympathique).

Changement interne

Des changements internes sont prévus (passage en C++11 pur pour un certain type de serveur, arbre de serveur/base de données, …), surtout après avoir eu assez de retours pour cette version 1.0 ; mais aussi des changements de programmations et de protocole, et les traditionnels ajouts de protection native et amélioration des performances.

Les serveurs

Les serveurs seront organisés en arbre avec tout ce qui va avec (datapack, base de données). Et donc, vous pourrez avec le même personnage (avec les mêmes items, monstres…) aller sur plusieurs serveurs d'un même groupe. Des serveurs pour les bots seront spécialement ouverts, cela permettra à ceux aimant coder des bots d’affronter les bots des adversaires.

Fonds

Le projet étant fait de manière professionnelle et par des professionnels, soumis à l'impôt et encadré par une entreprise, il a besoin de fonds. Pour cela une campagne Indiegogo sera sûrement ouverte, un espace pour les utilisateurs premiums donnera accès à de nouveaux habillages… Tout cela en plus de la version 1.0 qui est en vente actuellement en Bitcoin, via PayPal ou sur le Nextcoin market (un Ebay décentralisé). Le code, même vendu, est sous GNU GPL v.3.

Autre

La version 3 commence aussi à être ébauchée. Les technologies liées aux monnaies virtuelles sont étudiées (donc autre que le transfert de valeur). Il y aura sûrement la publication du code C10M qui applique une technique permettant sur un PC normal de faire des millions de connexions simultanées et en utilisant une base de données taillée sur mesure (pour minimiser et optimiser les index, les performances et l'espace occupé).

Télécharger ce contenu au format Epub

Lire les commentaires

Le Chaos Communication Congress, célèbre rassemblement de hackers buvant du Club Mate, organisé par le Chaos Computer Club revient cette année pour sa 31e mouture (aussi nommée 31c3).

Au cours des seules deux dernières années, l’événement a vu Jacob Appelbaum offrir une keynote abordant la surveillance avant les révélations de Snowden, puis révéler l’année suivante le catalogue Tailored Access Operations de la NSA ; William Binney, Thomas Drake et Jesselyn Radack parler de leurs activités de lanceurs d’alertes ; Glenn Greenwald intervenir au sujet des révélations de Snowden ; et de nombreux autres activistes et hackers du monde entier venir parler de leurs recherches et activités.

La 31e édition se déroulera comme à l’accoutumée au Congress Center Hamburg dans la ville de Hambourg, au nord de l’Allemagne, du 27 au 30 décembre 2014.

• lien n°1 : Blog des événements du CCC
• lien n°2 : Wiki du 31c3
• lien n°3 : Programme des conférences
• lien n°4 : Regarder le 31c3 en streaming (et autres accès distant)

Sommaire

• Slogan
• Programme
• Infrastructures
• Assemblées
• Suivre le congrès en restant au chaud chez soi
• Assister au congrès

Slogan

La plupart des éditions du CCC ont leur slogan, le 29c3 annoncait ainsi Not My Department, allusion à la phrase attribuée à Wernher von Braun et qui ne doit pas devenir l’excuse des hackers pour travailler sur des projets à l’éthique discutable. Le 30c3, quant à lui, suite aux révélations concernant la NSA, n’a pas eu de slogan, pour refléter l’effroi de la communauté concernant les sujets liés à la surveillance. L’édition de cette année, annonce A New Dawn (une nouvelle aube), probable référence à la nécessité de devoir se relever de ces événements.

Programme

Le programme en version bêta a été publié il y a quelques jours ; ceux qui assisteront à l’événement pourront notamment voir :

• une keynote de Alec Empire ;
• une projection du film documentaire Citizenfour relatant les péripéties de Edward Snowden, réalisé par Laura Poitras ;
• une présentation de Netanel Rubin promettant une apocalypse semblable à ShellShock pour l’interpréteur Perl (pivot central de nombreuses distributions GNU/Linux) ;
• une présentation sobrement intitulée « Fuck Off Google » par le Comité invisible (les auteurs des livres L’insurrection qui vient et À nos amis ;
• [Sarah Harisson] et gracefire mettant en évidence les besoin d’OPSEC des lanceurs d’alertes ;
• le Dr Gareth Owen présentant une méthode de désanonymisation des utilisateurs de Tor.

Beaucoup d’autres conférences seront présentées, impliquant des sujets aussi bien sociaux, artistiques (comme une présentation de contenus de Geocities), que scientifiques (domaine des lanceurs astronautiques, ordinateurs quantiques, transhumanisme, intelligence artificielle, sécurité, cryptographie, couture, etc.).

Infrastructures

Les hackers du CCC ont pour habitude d’organiser leurs affaires convenablement, ce qui donne des infrastructures plus que décentes pour une conférence de ce type, voyez plutôt :

• réseau GSM opéré par le club lui‐même, cela permet à tous les participants de communiquer via texte et voix de façon gratuite pendant la durée de l’événement, le seul coût d’entrée à ce réseau étant l’achat d’une carte SIM (2 € l’année dernière) auprès du POC, réutilisable de congrès en congrès ;
• réseau DECT afin de réaliser la même chose, mais avec des téléphones DECT ;
• le Seidenstrasse, système de livraison pneumatique permettant de propulser des bouteilles plastiques vides (ou pas). Ce système mis en œuvre pour la première fois lors du 30c3, permettra encore une fois aux participants de s’échanger des patates, des clés USB, des drogues, des mots doux (pas forcément dans cet ordre) dans l’enceinte du bâtiment. Cette année, le réseau sera tout de même de taille réduite comparativement à l’année dernière. Le but étant de fiabiliser l’ensemble en vue d’un déploiement décent lors du CCC Camp 2015 (congrès d’été du CCC se déroulant tout les 4 ans) ;
• une connexion Internet sera aussi de la partie ; aucune info n’a été publiée dessus pour le moment, mais il faut s’attendre à un déploiement similaire à celui de l’année dernière. Je m’attends à divers autres réseaux, comme un IPv6 only, du Wi‐Fi WPA2 802.1X libre d’accès et chiffré (acceptant tout nom utilisateur + mot de passe) ainsi qu’une connexion globale pour l’événement supérieure à 100 Gbit/s.

Assemblées

Les assemblées sont des rassemblements de groupes dont le but est de faire la promotion de leurs idées, travailler ensemble, etc.

Ainsi, nous retrouverons comme à l’accoutumée la safe zone de la Quadrature du Net (à laquelle il manque toujours 98 000 € pour son budget), où il sera bien vu de boire du thé, avec la présence du projet CaliOpen.

L’assemblée NoisySquare, commencée lors de OHM 2013 en résistance à leurs sponsors, sera réitérée. Cette assemblée devenant une sorte de congrès dans le congrès, il est normal de s’y attarder. Cette année, NoisySquare accueillera les projets et des ateliers concernant Tails, LEAP, GNUnet, I2P, OTR.

Beaucoup de hackerspaces ainsi que certaines distributions GNU/Linux tiendront également une assemblée lors de cette édition.

Les plus curieux pourrons s’essayer au tricot, au crochetage de serrure, à la soudure, à la signature de clés GPG, à la certification CAcert, la torrefaction du café, l’organisation de FAI associatifs, au pwnage de consoles, etc.

Suivre le congrès en restant au chaud chez soi

L’ensemble des conférences sera diffusé en direct sur Internet, ce qui implique que tout le monde peut les regarder, cela se passe en ligne.

La page accueille également les instructions pour permettre aux spectateurs distants de faire relayer leurs questions aux conférenciers via IRC.

Assister au congrès

La meilleure façon de profiter de cet évènement unique étant bien évidemment de venir directement au congrès afin de se faire sa propre idée (et boire des litres de Club Mate), il est fortement recommandé d’acheter sa place ! La vente des tickets se termine très bientôt, une vente de ticket (espèce uniquement) se fera à l’entrée de l’évènement le premier jour, pour ceux qui préfèrent ce mode de vente. Le wiki du CCC recense les hotels à proximité de l’évènement.

Note personnelle de l’initiateur de la dépêche : bien évidemment, toute personne se rendant à l’évènement et souhaitant m’aider à rédiger un compte‐rendu pour LinuxFr.org est bienvenu et peut se signaler dans les commentaires (ou utiliser le numéro 98013911 sur le réseau GSM du 31c3).

Télécharger ce contenu au format Epub

Lire les commentaires

«GLOU», c'est le bruit que fait le liquide quand il descend entre deux discussions sur les libertés et la technologie avec les membres de l'association LoLiCA.

Suite au bon succès de la première session, nous renouvelons l'opération le jeudi 18 décembre à partir de 18h30, au Grand Comptoir (2 cours de la Gare - Gare de Reims).

C'est l’occasion de se retrouver autour d’un verre et d’échanger sur l’actualité du libres et toutes autres thématiques. Aussi bien pour novices que confirmés.

L'évènement est ouvert à tous. Venez nombreux !

• lien n°1 : L'info sur le site de l'association
• lien n°2 : L'événement sur l'agenda du libre.

Télécharger ce contenu au format Epub

Lire les commentaires