Je l'ai dis LaTeX n'a pas de concurrent. Les deux seuls aux quels je pense c'est postscript et lout,
OK pour Lout, mais comparer LaTeX (ou même TeX) avec PostScript je ne suis pas sûr que ce soit pertinent : PostScript est un langage de description de page, là où TeX et LaTeX font de la mise en page.
Un seul example suffit à saisir la nuance : en PostScript, rien dans le langage ne va s’occuper de formatter un paragraphe, c’est à toi de le couper en lignes et de faire afficher chaque ligne une par une, en calculant toi-même les coordonnées de départ de chaque ligne. PostScript ne fait qu’afficher le texte là où tu lui dis de le faire.
La comparaison foireuse du jour : PostScript c’est de l’assembleur, TeX c’est du C¹, et LaTeX c’est du C « à la GObject » (voire du Vala).
¹Et avec un peu de mauvaise foi on pourrait probablement appliquer à TeX ce qu’on dit du C : « c’est un langage qui combine l’expressivité du PostScript avec la lisibilité du PostScript »…
Et donc, alors que le langage se trimbale tous ces défauts (qui sont assez fondamentaux, pour la plupart je ne vois pas comment on pourrait les améliorer sans changer profondément le langage), la chose la plus importante à faire serait de rendre LaTeX plus attractifs pour des utilisateurs dont les besoins ne justifient probablement pas l’utilisation de LaTeX à la base ?
Il faudrait d’abord expliquer en quoi c’est un problème.
Oui, LaTeX n’est probablement pas adapté à la rédaction d’un petit document qui ne doit pas prendre plus de trente minutes. Et alors ? On a justement d’autres outils (que ce soit Word, Writer, ou même le bon vieux WritePad¹ si on ne veut pas prendre un bazooka pour écraser une mouche) pour ce cas de figure.
Pourquoi serait-il crucial d’adapter LaTeX à un cas d’utilisation pour lequel il n’est pas vraiment conçu ?
Je m’arrête là. De toutes façons, tu as une longue carrière derrière toi avec au moins vingt-cinq papiers alors que je ne suis qu’un débutant de post-doc avec cinq pauvres papiers (même pas dans des journaux avec un gros impact), et en plus avec ma veine tu pourrais être dans un de mes jurys quand je vais passer les concours. Alors évidemment, tu as raison et je ne raconte que des conneries.
Bah c’est facile. La dernière fois que j’ai vérifié, il y avait un peu plus de 26 000 journaux en biologie et médecine (tous les journaux indexés par MEDLINE), depuis le American Association of Dental Editors’ Journal jusqu’au Zhongguo Zhong xi yi jie he za zhi Zhongguo Zhonghiyi jiehe zazhi (« Chinese journal of integrated traditional and Western medicine »).
Il suffit donc de consulter la page d’instructions aux auteurs pour chacun d’eux.
Eh bien nos expériences diffèrent considérablement. Les deux seuls journaux que j’ai vu accepter du (La)TeX sont Nucleic Acids Research et PNAS (celui-ci allant en effet jusqu’à fournir un fichier de style). Pour la quinzaine d’autres auxquels j’ai eu affaire, c’était Word ou PDF uniquement.
En 2008, Nature faisait semblant d’accepter du LaTeX en précisant bien que la première chose qu’ils en faisaient était de le convertir en Word. Maintenant ils ne se donnent même plus cette peine.
Il me semble que les revues et journaux en sciences sont systèmatiquement en LaTeX, où l'auteur envoie les sources et pas le document formatté.
Non. Absolument pas. C’est même le contraire, (La)TeX est rarement accepté comme format de soumission, à part peut-être dans les revues qui se spécialisent en maths ou physique.
La plupart des soumissions se font en Word ou en PDF.
Our preferred format for text is Microsoft Word, with the style tags removed. If you have prepared your paper using TeX, please convert to PDF format and upload the PDF only at submission.
(Au passage, admirez le « with style tags removed » : à quoi bon réclamer du Word comme format de soumission si on ne peut même pas utiliser les fonctionnalités intéressantes d’un traitement de texte ? À ce compte-là autant demander de soumettre du texte brut…)
Euh, ça fait longtemps que Word gère les styles. Le problème avec les styles n’est pas que Word ne les « gère » pas ou les gère mal, c’est que les utilisateurs, soit ne savent même pas que ça existe, soit ne voient pas l’intérêt de perdre du temps avec avec ça (ben oui, c’est tellement plus rapide de sélectionner un bout de texte et d’appliquer manuellement le formatage désiré).
(La même chose est valable pour LibreOffice d’ailleurs.)
Cela dit, ce comportement (ignorer les styles et formatter manuellement) est complètement raisonnable dans le cas d’un petit document « one-shot » qu’on écrit en trente minutes et sur lequel on ne reviendra jamais. Moi-même dans ce cas de figure, j’utilise LibreOffice en faisant fi des styles.
la bibliographie
Je n’ai jamais vu personne utiliser les fonctions intégrées de Word pour ça (encore une fois, je pense que rare sont ceux qui savent que ça existe). Tous ceux que je connais qui ont besoin de ce genre de fonctionnalités utilisent des outils externes, genre EndNote ou Zotero.
Sans cette fonctionnalité, la plupart des commandes fonctionnent quand même car elles n’ont pas besoin d’échanger de gros messages avec la carte (ce qui fait que tu peux éditer le contenu de la carte sans problèmes), mais importer une clef RSA moderne (2048 bits ou plus) est impossible.
Malheureusement, il n’y a pas grand’chose d’autre à faire que de changer le lecteur — à moins de se contenter de clefs RSA de 1024 bits, ce qui n’est plus suffisant aujourd’hui.
OK, j’avais mal compris ce que tu voulais dire par « installation toute prête » — je pensais que tu parlais de créer une sorte de distribution clef-en-main pour quiconque voudrait utiliser un Raspberry Pi comme hotspot.
En fait, tu parles d’une installation unique sur une de tes machines, c’est ça ? Et tu ne veux pas que les utilisateurs du hotspot puissent modifier cette installation ?
S’ils ont un accès physique au Raspberry Pi (ce qui devrait être le cas vu que tu parles plus haut d’accèder à la carte SD via un autre système), en gros c’est mort. Tu peux probablement rendre la tâche suffisamment difficile pour décourager un utilisateur moyen, mais tu n’arrêteras pas un utilisateur avancé.
Chiffrer le système de fichiers est une solution, seulement s’il est acceptable que toi seul soit capable de démarrer la machine (pour que tu puisses saisir le mot de passe ou brancher la clef de déchiffrement) — si n’importe lequel de tes utilisateurs doit pouvoir (re)démarrer la machine à sa guise, c’est mort.
Alors je veux empêcher l'utilisateur de pouvoir modifier l'installation pour une chose toute simple.
Je ne veux pas que l'utilisateur puisse ajouter de quoi espionner les connexions des utilisateurs qui se connecteraient sur le hotspot.
Un tel système ne pourrait pas être libre. D’après moi ce que tu cherches contrevient directement à la « liberté 0 », la liberté d’utiliser le programme pour tous les usages.
Peu importe la cause (elle peut être noble ou abjecte), si tu interdis certains usages à tes utilisateurs, on ne parle plus de logiciels libres.
Et du coup, selon les licences de ce que tu comptes mettre dans ton « installation toute prête pour Raspberry Pi », il n’est pas sûr que tu aies le droit de la redistribuer.
Moi ce qui aurait tendance à me faire râler avec Systemd, ce sont ceux (opposants ou zélateurs, même combat) qui ne peuvent pas s’empêcher de l’évoquer dans n’importe quelle discussion…
À moins que j’ai raté quelque chose, on ne sait pas combien de lecteurs de ton précédent journal sont allés vers la page de soutien de la QdN. Qu’est-ce qui te permets de dire qu’ils sont plus nombreux que les 507 de l’année dernière ?
Ok, j'y suis allez un peu fort mais au moins, ça vit.
Ah ben oui, heureusement que tu es là. Aucun doute, c’est seulement grâce à toi que la QdN a obtenu son argent.
pourquoi Linux ne tournerai pas avec les équivalents BSD
À ma connaissance (mais je fais confiance aux BSDistes du coin pour me corriger promptement là-dessus si besoin), l’userland des BSD n’a jamais été conçu pour fonctionner avec un autre noyau que les noyaux BSD.
En fait, je crois que l’userland GNU est le seul à avoir été explicitement conçu indépendemment de tout noyau et à pouvoir fonctionner sous une variété de noyaux différents (ce qui a rendu possible la combinaison de GNU + Linux). Et ce pour une raison simple : comme GNU n’avait pas de noyau à lui, il fallait bien qu’il puisse tourner sur les autres noyaux existants à l’époque.
Les lecteurs USB sont, bien sûr, détectés lors de leur branchement et pas seulement au démarrage de pcscd.
Effectivement, je ne sais plus d’où je tenais ça.
Je crois que c’est la page de manuel de pcscd qui m’a induit en erreur :
-H, --hotplug
Ask pcscd to rescan the USB buses for added or removed readers and re-read the /etc/reader.conf.d/reader.conf files to detect added or removed non-USB readers (serial or PCMCIA).
J’avais interprété ça comme voulant dire qu’appeler pcscd --hotplug était nécessaire pour que tous les lecteurs (USB ou non) nouvellement branchés soient pris en compte, ce qui n’est manifestement le cas pour les lecteurs USB. Autant pour moi.
De plus pcscd n'est pas forcement lancé au démarrage mais peut l'être à la demande d'un programme en utilisant systemd.
Tout à fait, mais le point important dans ce paragraphe était qu’on ne devrait de toute façon pas avoir à se soucier de démarrer pcscd, c’est le rôle de la distribution. Après, que pcscd soit lancé au démarrage par un script System V ou à la demande par une unité Systemd relève du détail pour l’utilisateur, et je fais confiance aux distributions ayant intégré Systemd pour avoir fait ça correctement.
En effet, il faut configurer chaque logiciel et chacun d'une façon différente. Ça serait tellement plus simple s'il existait un système de gestion unique que chaque application interrogerait pour retirer les données dont elle a besoin.
Bah je trouve que pour OpenPGP, on en est déjà à peu près là.
Toutes les applications que je connais qui prennent en charge OpenPGP le font via GnuPG d’une manière ou d’une autre (soit en appelant directement /usr/bin/gpg, soit en passant par la bibliothèque GpgME qui le fait à leur place). Du coup, c’est GnuPG qu joue le rôle du « système de gestion unique » et une fois que GnuPG fonctionne, toutes ces applications en profitent (y compris dans l’utilisation de la carte OpenPGP).
Par exemple, je signe mes tags Git (git tag -s) avec ma carte OpenPGP — et à aucun moment je n’ai eu à configurer Git pour ça, puisqu’il délègue la signature à GnuPG.
Pareil pour Enigmail ou Mutt : une fois GnuPG configuré pour utiliser la carte, il n’y a rien à faire de leur côté.
C’est bien pour ça que la section « Signer ou déchiffrer des messages OpenPGP », qui devrait logiquement être le cœur de la dépêche (c’est quand même ce à quoi la carte est fondamentalement destinée…), est en réalité la partie la plus courte : c’est parce qu’il n’y a rien à dire !
Du côté des certificats X.509, on n’en est pas là, certes. Du moins sous GNU/Linux (il me semble que X.509 est beaucoup mieux intégré sous Windows : notamment, je suis presque sûr qu’il doit exister un dépôt central de certificats pour tout le système, disponible à toutes les applications, au lieu d’un dépôt par application comme c’est le cas par exemple avec Firefox et Thunderbird). GpgSM aurait vocation à changer ça, il appartient maintenant aux applications de s’en servir…
OK mais je la mets où ma clé ? Sous l'oreiller ? Quels sont les bons conseils pour mettre sa clé privée au chaud et de façon pérenne ?
J’ai préféré ne pas aborder ces questions. Elles sont totalement indépendantes de l’utilisation de la carte OpenPGP et la dépêche est déjà bien assez longue comme ça.
Personnellement, j’ai d’une part une sauvegarde au format papier (générée avec paperkey) qui ne sort jamais de chez moi, et d’autre part une sauvegarde électronique, dans une archive chiffrée et dupliquée entre une clef USB que j’ai toujours avec moi, mon téléphone portable et un serveur loin de chez moi.
(L’archive contient également, outre mes clefs OpenPGP, une petite sélection de documents importants — le genre de documents que j’aimerais conserver même si je devais perdre tout le reste, par exemple si mon appartement devait partir en fumée.)
Je me demande juste s'il est possible de faire fonctionner Scute avec Evolution pour profiter de s/mime?
Pour faire court : oui en théorie, non en pratique pour l’instant.
Pour faire moins court :
Scute est un module PKCS #11 qui devrait normalement fonctionner avec n’importe quelle application capable d’utiliser dynamiquement un tel module (donc, ce n’est même pas limité aux applications utilisant NSS).
Le fait que ton certificat apparaisse dans Evolution confirme que cela devrait fonctionner.
Toutefois, avec la version actuelle de Scute (1.4.0), cela ne peut pas fonctionner, ni avec Evolution, ni avec Thunderbird, pour la même raison qui fait que l’authentification TLS avec Firefox ne fonctionne qu’avec TLS <= 1.1 et pas avec TLS 1.2 : parce que Scute n’accepte pour l’instant que des message digest de 36 octets (correspondant à la concaténation d’un condensé SHA-1 et d’un condensé MD5). Or aussi bien S/MIME que TLS 1.2 utilisent comme message digest une structure constituée d’un OID identifiant l’algorithme de condensation utilisé (généralement SHA-1 ou, de plus en plus, SHA-256) suivi du condensat lui-même. Scute ne reconnaît pas ces structures et est donc incapable de les faire signer par la carte.
Il y a une bonne et une mauvaise nouvelle : la bonne, c’est que comme mentionné dans la dépêche, des patches existent ; la mauvaise, c’est qu’il faut patcher pour que ça marche.
Comme je ne suis pas sûr d’avoir été assez clair dans la dépêche, je re-précise ici :
dans tous les cas, pour utiliser TLS 1.2 ou S/MIME, il faut appliquer à Scute 1.4.0 le patch de Werner Koch du 12 septembre 2014 ;
avec GnuPG 2.0.26, il faut aussi appliquer à GnuPG lui-même ce patch, qui autorise l’utilisation d’algorithmes autres que SHA-1 (c’est en fait un simple backport d’un commit de GnuPG 2.1) ;
avec GnuPG 2.1, pas la peine de toucher à GnuPG mais il faut appliquer à Scute un second patch de mon cru en plus de celui de Werner (ce patch corrige un bug insidieux à cause duquel Scute n’échoue à signer que de temps en temps et non systématiquement).
Avec GnuPG 2.1.1, Scute 1.4.0 et les deux patches mentionnés appliqués, « chez moi ça marche™ » — aussi bien TLS 1.2 avec Firefox que S/MIME avec Thunderbird. Je soupçonne que cela devrait aussi fonctionner avec Evolution.
Pour ceux que ça intéresse, je mets à disposition le document source au format DocBook ainsi qu’une version PDF générée à partir de ce dernier. Sous licence CC BY-SA bien sûr, comme la version publiée ici.
(Le texte de la version DocBook est presque le même que le texte de la dépêche — la version initiale de celle-ci a d’ailleurs été générée à partir de DocBook, via pandoc —, à part diverses corrections apportées ici par les contributeurs de la dépêche — au fait, merci à eux ! — que je n’ai pas toujours ré-intégré, par flemme essentiellement.)
Pour ceux qui l'auront remarqué, le code de la carte "Open"PGP n'est pas libre.
Il n’y a pas de « code de la carte OpenPGP ». « La » carte OpenPGP n’est qu’une spécification dont il existe plusieurs implémentations, certaines libre (dont des implémentations pour JavaCard), d’autres non.
Tu parles probablement du code de l’implémentation sur la BasicCard (celle vendue par KernelConcepts), qui effectivement n’est pas libre. Mais personne n’a jamais prétendu le contraire (cf. cette question récente sur la liste gnupg-users et les réponses de Werner Koch et de Kernel Concepts).
(Ce qui veut dire, en effet, que la FSFE distribue à ses adhérents une carte dont le code n’est pas libre. Bon vendredi.)
En conclusion, il ne faut pas (plus) utiliser la version 1 de la carte.
Tout à fait. C’est pour ça que j’avais choisi de ne même pas évoquer cette version. De toute façon, les implémentations de la version 1.0 ne sont à ma connaissance plus distribuées, et ceux qui en ont une l’ont probablement depuis assez longtemps pour ne pas avoir besoin de cette dépêche.
Et cerise sur le gâteau des modérateurs, on n'a presque rien corrigé!
Et merci à celui (ceux ?) qui a corrigé rapidement (avant même que je n’ai le temps de les signaler !) les quelques problèmes de mise en forme qui subsistaient lors de la publication, notamment sur les extraits de code ou les notes de bas de page. ;)
La version 1.0 de la carte OpenPGP est limitée à SHA-1 et RIPEMD-160, mais la version 2.0 (la seule dont il est question dans la dépêche) supporte prend en charge les algorithmes de la famille SHA-2 (SHA-{224,256,384,512})
les clés RSA de 1024bits sont beaucoup trop courtes et même celles de 2048 bits autorisées que jusqu'en 2020.
1024 n’est que la taille minimale qu’une carte OpenPGP 2.0 doit accepter pour être conforme avec cette spécification. À ma connaissance, toutes les implémentations acceptent au minimum 2048 bits, et la BasicCard de ZeitControl accepte depuis le début des clefs de 4096 bits (mais ce n’était pas affiché car c’était GnuPG qui ne permettait pas de les utiliser, jusqu’à la version 2.0.17 ou à peu près).
Une version 2.1 de la spécification est dans les cartons, avec l’introduction des clefs à base de courbes elliptiques (pour l’instant seul Gnuk implémente ce type de clefs, à titre expérimental).
Cela devrait définir un écran (virtuel) de 10000x10000, configurer le premier moniteur pour afficher une région de 1024x768 à partir de la position 100x100, et le second moniteur pour afficher une région de 800x600 à partir de la position 2000x2000.
(xrandr tout court te donnera les identifiants de tes moniteurs, si ce n’est pas « VGA1 » et « VGA2 »).
[^] # Re: Et si on prenait ça comme un retour?
Posté par gouttegd . En réponse au journal Word vs TeX. Évalué à 4.
OK pour Lout, mais comparer LaTeX (ou même TeX) avec PostScript je ne suis pas sûr que ce soit pertinent : PostScript est un langage de description de page, là où TeX et LaTeX font de la mise en page.
Un seul example suffit à saisir la nuance : en PostScript, rien dans le langage ne va s’occuper de formatter un paragraphe, c’est à toi de le couper en lignes et de faire afficher chaque ligne une par une, en calculant toi-même les coordonnées de départ de chaque ligne. PostScript ne fait qu’afficher le texte là où tu lui dis de le faire.
La comparaison foireuse du jour : PostScript c’est de l’assembleur, TeX c’est du C¹, et LaTeX c’est du C « à la GObject » (voire du Vala).
¹Et avec un peu de mauvaise foi on pourrait probablement appliquer à TeX ce qu’on dit du C : « c’est un langage qui combine l’expressivité du PostScript avec la lisibilité du PostScript »…
[^] # Re: Et si on prenait ça comme un retour?
Posté par gouttegd . En réponse au journal Word vs TeX. Évalué à 2.
Et donc, alors que le langage se trimbale tous ces défauts (qui sont assez fondamentaux, pour la plupart je ne vois pas comment on pourrait les améliorer sans changer profondément le langage), la chose la plus importante à faire serait de rendre LaTeX plus attractifs pour des utilisateurs dont les besoins ne justifient probablement pas l’utilisation de LaTeX à la base ?
[^] # Re: Et si on prenait ça comme un retour?
Posté par gouttegd . En réponse au journal Word vs TeX. Évalué à 1.
Il faudrait d’abord expliquer en quoi c’est un problème.
Oui, LaTeX n’est probablement pas adapté à la rédaction d’un petit document qui ne doit pas prendre plus de trente minutes. Et alors ? On a justement d’autres outils (que ce soit Word, Writer, ou même le bon vieux WritePad¹ si on ne veut pas prendre un bazooka pour écraser une mouche) pour ce cas de figure.
Pourquoi serait-il crucial d’adapter LaTeX à un cas d’utilisation pour lequel il n’est pas vraiment conçu ?
¹ Au fait, il existe encore ?
[^] # Re: 30 min
Posté par gouttegd . En réponse au journal Word vs TeX. Évalué à 6. Dernière modification le 28 décembre 2014 à 21:38.
Bon.
Journal of Cell Biology : Acceptable file formats for your manuscripts are DOC or PDF.
Journal of Biological Chemistry : Prepare the text in Microsoft Word 6.0 or a later version.
Molecular and Cellular Biology : Manuscript files in PDF, Word, or RTF format.
Cell Cycle : Manuscript files (text and tables) as Word or RTF files
Cancer Research (et probablement tous les journaux de l’AACR) : Manuscript files: Word, WordPerfect, Encapsulated Postscript (EPS), Text, Postscript, Rich Text Format (RTF), or PDF (accepted for original submissions only; not for revisions)
Molecular Biology of the Cell : For initial submission, a merged PDF (…) For a revised manuscript, a separate manuscript file in .doc or .rtf format
Je m’arrête là. De toutes façons, tu as une longue carrière derrière toi avec au moins vingt-cinq papiers alors que je ne suis qu’un débutant de post-doc avec cinq pauvres papiers (même pas dans des journaux avec un gros impact), et en plus avec ma veine tu pourrais être dans un de mes jurys quand je vais passer les concours. Alors évidemment, tu as raison et je ne raconte que des conneries.
[^] # Re: 30 min
Posté par gouttegd . En réponse au journal Word vs TeX. Évalué à 4.
Bah c’est facile. La dernière fois que j’ai vérifié, il y avait un peu plus de 26 000 journaux en biologie et médecine (tous les journaux indexés par MEDLINE), depuis le American Association of Dental Editors’ Journal jusqu’au Zhongguo Zhong xi yi jie he za zhi Zhongguo Zhonghiyi jiehe zazhi (« Chinese journal of integrated traditional and Western medicine »).
Il suffit donc de consulter la page d’instructions aux auteurs pour chacun d’eux.
[^] # Re: 30 min
Posté par gouttegd . En réponse au journal Word vs TeX. Évalué à 5.
Eh bien nos expériences diffèrent considérablement. Les deux seuls journaux que j’ai vu accepter du (La)TeX sont Nucleic Acids Research et PNAS (celui-ci allant en effet jusqu’à fournir un fichier de style). Pour la quinzaine d’autres auxquels j’ai eu affaire, c’était Word ou PDF uniquement.
En 2008, Nature faisait semblant d’accepter du LaTeX en précisant bien que la première chose qu’ils en faisaient était de le convertir en Word. Maintenant ils ne se donnent même plus cette peine.
[^] # Re: 30 min
Posté par gouttegd . En réponse au journal Word vs TeX. Évalué à 6.
Non. Absolument pas. C’est même le contraire, (La)TeX est rarement accepté comme format de soumission, à part peut-être dans les revues qui se spécialisent en maths ou physique.
La plupart des soumissions se font en Word ou en PDF.
Si on regarde Nature par exemple :
(Au passage, admirez le « with style tags removed » : à quoi bon réclamer du Word comme format de soumission si on ne peut même pas utiliser les fonctionnalités intéressantes d’un traitement de texte ? À ce compte-là autant demander de soumettre du texte brut…)
[^] # Re: 30 min
Posté par gouttegd . En réponse au journal Word vs TeX. Évalué à 10.
Euh, ça fait longtemps que Word gère les styles. Le problème avec les styles n’est pas que Word ne les « gère » pas ou les gère mal, c’est que les utilisateurs, soit ne savent même pas que ça existe, soit ne voient pas l’intérêt de perdre du temps avec avec ça (ben oui, c’est tellement plus rapide de sélectionner un bout de texte et d’appliquer manuellement le formatage désiré).
(La même chose est valable pour LibreOffice d’ailleurs.)
Cela dit, ce comportement (ignorer les styles et formatter manuellement) est complètement raisonnable dans le cas d’un petit document « one-shot » qu’on écrit en trente minutes et sur lequel on ne reviendra jamais. Moi-même dans ce cas de figure, j’utilise LibreOffice en faisant fi des styles.
Je n’ai jamais vu personne utiliser les fonctions intégrées de Word pour ça (encore une fois, je pense que rare sont ceux qui savent que ça existe). Tous ceux que je connais qui ont besoin de ce genre de fonctionnalités utilisent des outils externes, genre EndNote ou Zotero.
[^] # Re: J'ai deux cartes à puces OpenPGP dont je n'arrive pas à mettre les clés dessus
Posté par gouttegd . En réponse à la dépêche “OpenPGP card”, une application cryptographique pour carte à puce. Évalué à 4. Dernière modification le 26 décembre 2014 à 23:31.
Il semble que ton lecteur, s’il est bien utilisable avec le pilote CCID, ne prend pas en charge les commandes APDU étendues.
Sans cette fonctionnalité, la plupart des commandes fonctionnent quand même car elles n’ont pas besoin d’échanger de gros messages avec la carte (ce qui fait que tu peux éditer le contenu de la carte sans problèmes), mais importer une clef RSA moderne (2048 bits ou plus) est impossible.
Malheureusement, il n’y a pas grand’chose d’autre à faire que de changer le lecteur — à moins de se contenter de clefs RSA de 1024 bits, ce qui n’est plus suffisant aujourd’hui.
[^] # Re: Peut-être impossible
Posté par gouttegd . En réponse au message Chiffrer l'OS. Évalué à 2.
OK, j’avais mal compris ce que tu voulais dire par « installation toute prête » — je pensais que tu parlais de créer une sorte de distribution clef-en-main pour quiconque voudrait utiliser un Raspberry Pi comme hotspot.
En fait, tu parles d’une installation unique sur une de tes machines, c’est ça ? Et tu ne veux pas que les utilisateurs du hotspot puissent modifier cette installation ?
S’ils ont un accès physique au Raspberry Pi (ce qui devrait être le cas vu que tu parles plus haut d’accèder à la carte SD via un autre système), en gros c’est mort. Tu peux probablement rendre la tâche suffisamment difficile pour décourager un utilisateur moyen, mais tu n’arrêteras pas un utilisateur avancé.
Chiffrer le système de fichiers est une solution, seulement s’il est acceptable que toi seul soit capable de démarrer la machine (pour que tu puisses saisir le mot de passe ou brancher la clef de déchiffrement) — si n’importe lequel de tes utilisateurs doit pouvoir (re)démarrer la machine à sa guise, c’est mort.
[^] # Re: Peut-être impossible
Posté par gouttegd . En réponse au message Chiffrer l'OS. Évalué à 5.
Un tel système ne pourrait pas être libre. D’après moi ce que tu cherches contrevient directement à la « liberté 0 », la liberté d’utiliser le programme pour tous les usages.
Peu importe la cause (elle peut être noble ou abjecte), si tu interdis certains usages à tes utilisateurs, on ne parle plus de logiciels libres.
Et du coup, selon les licences de ce que tu comptes mettre dans ton « installation toute prête pour Raspberry Pi », il n’est pas sûr que tu aies le droit de la redistribuer.
[^] # Re: Kamoulox
Posté par gouttegd . En réponse au journal LQDN on the road again. Évalué à 4.
Moi ce qui aurait tendance à me faire râler avec Systemd, ce sont ceux (opposants ou zélateurs, même combat) qui ne peuvent pas s’empêcher de l’évoquer dans n’importe quelle discussion…
[^] # Re: Vous voulez des dons ? Montrez que vous les méritez !
Posté par gouttegd . En réponse au journal LQDN on the road again. Évalué à 3.
À moins que j’ai raté quelque chose, on ne sait pas combien de lecteurs de ton précédent journal sont allés vers la page de soutien de la QdN. Qu’est-ce qui te permets de dire qu’ils sont plus nombreux que les 507 de l’année dernière ?
Ah ben oui, heureusement que tu es là. Aucun doute, c’est seulement grâce à toi que la QdN a obtenu son argent.
[^] # Re: Et GNU ?
Posté par gouttegd . En réponse au journal LQDN on the road again. Évalué à 4.
À ma connaissance (mais je fais confiance aux BSDistes du coin pour me corriger promptement là-dessus si besoin), l’userland des BSD n’a jamais été conçu pour fonctionner avec un autre noyau que les noyaux BSD.
En fait, je crois que l’userland GNU est le seul à avoir été explicitement conçu indépendemment de tout noyau et à pouvoir fonctionner sous une variété de noyaux différents (ce qui a rendu possible la combinaison de GNU + Linux). Et ce pour une raison simple : comme GNU n’avait pas de noyau à lui, il fallait bien qu’il puisse tourner sur les autres noyaux existants à l’époque.
[^] # Re: Erreur sur le hotplug de pcsc-lite
Posté par gouttegd . En réponse à la dépêche “OpenPGP card”, une application cryptographique pour carte à puce. Évalué à 2.
Effectivement, je ne sais plus d’où je tenais ça.
Je crois que c’est la page de manuel de pcscd qui m’a induit en erreur :
J’avais interprété ça comme voulant dire qu’appeler
pcscd --hotplugétait nécessaire pour que tous les lecteurs (USB ou non) nouvellement branchés soient pris en compte, ce qui n’est manifestement le cas pour les lecteurs USB. Autant pour moi.Tout à fait, mais le point important dans ce paragraphe était qu’on ne devrait de toute façon pas avoir à se soucier de démarrer pcscd, c’est le rôle de la distribution. Après, que pcscd soit lancé au démarrage par un script System V ou à la demande par une unité Systemd relève du détail pour l’utilisateur, et je fais confiance aux distributions ayant intégré Systemd pour avoir fait ça correctement.
[^] # Re: Mettre ses clés au chaud
Posté par gouttegd . En réponse à la dépêche “OpenPGP card”, une application cryptographique pour carte à puce. Évalué à 7.
Bah je trouve que pour OpenPGP, on en est déjà à peu près là.
Toutes les applications que je connais qui prennent en charge OpenPGP le font via GnuPG d’une manière ou d’une autre (soit en appelant directement
/usr/bin/gpg, soit en passant par la bibliothèque GpgME qui le fait à leur place). Du coup, c’est GnuPG qu joue le rôle du « système de gestion unique » et une fois que GnuPG fonctionne, toutes ces applications en profitent (y compris dans l’utilisation de la carte OpenPGP).Par exemple, je signe mes tags Git (
git tag -s) avec ma carte OpenPGP — et à aucun moment je n’ai eu à configurer Git pour ça, puisqu’il délègue la signature à GnuPG.Pareil pour Enigmail ou Mutt : une fois GnuPG configuré pour utiliser la carte, il n’y a rien à faire de leur côté.
C’est bien pour ça que la section « Signer ou déchiffrer des messages OpenPGP », qui devrait logiquement être le cœur de la dépêche (c’est quand même ce à quoi la carte est fondamentalement destinée…), est en réalité la partie la plus courte : c’est parce qu’il n’y a rien à dire !
Du côté des certificats X.509, on n’en est pas là, certes. Du moins sous GNU/Linux (il me semble que X.509 est beaucoup mieux intégré sous Windows : notamment, je suis presque sûr qu’il doit exister un dépôt central de certificats pour tout le système, disponible à toutes les applications, au lieu d’un dépôt par application comme c’est le cas par exemple avec Firefox et Thunderbird). GpgSM aurait vocation à changer ça, il appartient maintenant aux applications de s’en servir…
J’ai préféré ne pas aborder ces questions. Elles sont totalement indépendantes de l’utilisation de la carte OpenPGP et la dépêche est déjà bien assez longue comme ça.
Personnellement, j’ai d’une part une sauvegarde au format papier (générée avec paperkey) qui ne sort jamais de chez moi, et d’autre part une sauvegarde électronique, dans une archive chiffrée et dupliquée entre une clef USB que j’ai toujours avec moi, mon téléphone portable et un serveur loin de chez moi.
(L’archive contient également, outre mes clefs OpenPGP, une petite sélection de documents importants — le genre de documents que j’aimerais conserver même si je devais perdre tout le reste, par exemple si mon appartement devait partir en fumée.)
[^] # Re: Et Evolution ?
Posté par gouttegd . En réponse à la dépêche “OpenPGP card”, une application cryptographique pour carte à puce. Évalué à 5.
Oups, je me rends compte que la dépêche contient une erreur (en même temps, ce n’est probablement pas la seule…) :
Dans le bloc « Attention » de la section S’authentifier auprès d’un serveur web, il y a deux fois le même lien vers le patch de Werner Koch. Celui appelé « un patch de votre serviteur » devrait être http://lists.gnupg.org/pipermail/gnupg-devel/2014-September/028759.html au lieu de http://lists.gnupg.org/pipermail/gnupg-devel/2014-September/028750.html.
[^] # Re: Et Evolution ?
Posté par gouttegd . En réponse à la dépêche “OpenPGP card”, une application cryptographique pour carte à puce. Évalué à 5.
Pour faire court : oui en théorie, non en pratique pour l’instant.
Pour faire moins court :
Scute est un module PKCS #11 qui devrait normalement fonctionner avec n’importe quelle application capable d’utiliser dynamiquement un tel module (donc, ce n’est même pas limité aux applications utilisant NSS).
Le fait que ton certificat apparaisse dans Evolution confirme que cela devrait fonctionner.
Toutefois, avec la version actuelle de Scute (1.4.0), cela ne peut pas fonctionner, ni avec Evolution, ni avec Thunderbird, pour la même raison qui fait que l’authentification TLS avec Firefox ne fonctionne qu’avec TLS <= 1.1 et pas avec TLS 1.2 : parce que Scute n’accepte pour l’instant que des message digest de 36 octets (correspondant à la concaténation d’un condensé SHA-1 et d’un condensé MD5). Or aussi bien S/MIME que TLS 1.2 utilisent comme message digest une structure constituée d’un OID identifiant l’algorithme de condensation utilisé (généralement SHA-1 ou, de plus en plus, SHA-256) suivi du condensat lui-même. Scute ne reconnaît pas ces structures et est donc incapable de les faire signer par la carte.
Il y a une bonne et une mauvaise nouvelle : la bonne, c’est que comme mentionné dans la dépêche, des patches existent ; la mauvaise, c’est qu’il faut patcher pour que ça marche.
Comme je ne suis pas sûr d’avoir été assez clair dans la dépêche, je re-précise ici :
dans tous les cas, pour utiliser TLS 1.2 ou S/MIME, il faut appliquer à Scute 1.4.0 le patch de Werner Koch du 12 septembre 2014 ;
avec GnuPG 2.0.26, il faut aussi appliquer à GnuPG lui-même ce patch, qui autorise l’utilisation d’algorithmes autres que SHA-1 (c’est en fait un simple backport d’un commit de GnuPG 2.1) ;
avec GnuPG 2.1, pas la peine de toucher à GnuPG mais il faut appliquer à Scute un second patch de mon cru en plus de celui de Werner (ce patch corrige un bug insidieux à cause duquel Scute n’échoue à signer que de temps en temps et non systématiquement).
Avec GnuPG 2.1.1, Scute 1.4.0 et les deux patches mentionnés appliqués, « chez moi ça marche™ » — aussi bien TLS 1.2 avec Firefox que S/MIME avec Thunderbird. Je soupçonne que cela devrait aussi fonctionner avec Evolution.
# Source et PDF
Posté par gouttegd . En réponse à la dépêche “OpenPGP card”, une application cryptographique pour carte à puce. Évalué à 9.
Pour ceux que ça intéresse, je mets à disposition le document source au format DocBook ainsi qu’une version PDF générée à partir de ce dernier. Sous licence CC BY-SA bien sûr, comme la version publiée ici.
(Le texte de la version DocBook est presque le même que le texte de la dépêche — la version initiale de celle-ci a d’ailleurs été générée à partir de DocBook, via pandoc —, à part diverses corrections apportées ici par les contributeurs de la dépêche — au fait, merci à eux ! — que je n’ai pas toujours ré-intégré, par flemme essentiellement.)
[^] # Re: Alternatives à la OpenPGP: La JavaCard
Posté par gouttegd . En réponse à la dépêche “OpenPGP card”, une application cryptographique pour carte à puce. Évalué à 3.
Pas la peine de charger une applet OpenPGP sur la Yubikey Neo, il y en a déjà une — comme mentionné dans la dépêche.
[^] # Re: Alternatives à la OpenPGP: La JavaCard
Posté par gouttegd . En réponse à la dépêche “OpenPGP card”, une application cryptographique pour carte à puce. Évalué à 9.
Il n’y a pas de « code de la carte OpenPGP ». « La » carte OpenPGP n’est qu’une spécification dont il existe plusieurs implémentations, certaines libre (dont des implémentations pour JavaCard), d’autres non.
Tu parles probablement du code de l’implémentation sur la BasicCard (celle vendue par KernelConcepts), qui effectivement n’est pas libre. Mais personne n’a jamais prétendu le contraire (cf. cette question récente sur la liste gnupg-users et les réponses de Werner Koch et de Kernel Concepts).
(Ce qui veut dire, en effet, que la FSFE distribue à ses adhérents une carte dont le code n’est pas libre. Bon vendredi.)
[^] # Re: spécifications cryptographiques un peu faibles
Posté par gouttegd . En réponse à la dépêche “OpenPGP card”, une application cryptographique pour carte à puce. Évalué à 5.
Tout à fait. C’est pour ça que j’avais choisi de ne même pas évoquer cette version. De toute façon, les implémentations de la version 1.0 ne sont à ma connaissance plus distribuées, et ceux qui en ont une l’ont probablement depuis assez longtemps pour ne pas avoir besoin de cette dépêche.
[^] # Re: Merci pour ce superbe article !
Posté par gouttegd . En réponse à la dépêche “OpenPGP card”, une application cryptographique pour carte à puce. Évalué à 5.
Et merci à celui (ceux ?) qui a corrigé rapidement (avant même que je n’ai le temps de les signaler !) les quelques problèmes de mise en forme qui subsistaient lors de la publication, notamment sur les extraits de code ou les notes de bas de page. ;)
[^] # Re: spécifications cryptographiques un peu faibles
Posté par gouttegd . En réponse à la dépêche “OpenPGP card”, une application cryptographique pour carte à puce. Évalué à 10.
La version 1.0 de la carte OpenPGP est limitée à SHA-1 et RIPEMD-160, mais la version 2.0 (la seule dont il est question dans la dépêche)
supporteprend en charge les algorithmes de la famille SHA-2 (SHA-{224,256,384,512})1024 n’est que la taille minimale qu’une carte OpenPGP 2.0 doit accepter pour être conforme avec cette spécification. À ma connaissance, toutes les implémentations acceptent au minimum 2048 bits, et la BasicCard de ZeitControl accepte depuis le début des clefs de 4096 bits (mais ce n’était pas affiché car c’était GnuPG qui ne permettait pas de les utiliser, jusqu’à la version 2.0.17 ou à peu près).
Une version 2.1 de la spécification est dans les cartons, avec l’introduction des clefs à base de courbes elliptiques (pour l’instant seul Gnuk implémente ce type de clefs, à titre expérimental).
# xrandr
Posté par gouttegd . En réponse au message Définir la position d'un écran dans un "bureau virtuel" plus grand. Évalué à 10.
C’est possible avec xrandr(1) :
Cela devrait définir un écran (virtuel) de 10000x10000, configurer le premier moniteur pour afficher une région de 1024x768 à partir de la position 100x100, et le second moniteur pour afficher une région de 800x600 à partir de la position 2000x2000.
(
xrandrtout court te donnera les identifiants de tes moniteurs, si ce n’est pas « VGA1 » et « VGA2 »).