Par contre, sur le long terme, les nouveaux projet risque de se concentrer sur l'interface par défaut.
Et donc on se retrouvera avec non pas une mais deux piles audio pouvant être utilisées pour l’audio-numérique « pro ». Avec des applications qui supporteront l’une, des applications qui supporteront l’autre, des systèmes où l’une sera installée par défaut mais pas l’autre, des utilisateurs qui n’y comprendront rien et qui viendront demander sur les forums « pourquoi c’est si compliqué l’audio sous GNU/Linux, je vais retourner sur MacOS X »…
Y’a pas à dire, les « créateurs de contenus » vont vraiment se sentir des « citoyens de première classe » avec une idée pareille.
Je présume qu'il n'est pas très pratique d'avoir à changer de serveur de son pour passer de la MOA à de la simple écoute en bluetooth
Étant donné que ça peut se faire complètement tout seul¹, je ne vois pas en quoi « ce n’est pas pratique ».
Ça n’a jamais dérangé les MAOïstes sous Windows d’avoir leurs diverses applications audio fonctionnant avec ASIO (en gros une pile audio spécifique à l’audio pro, inventé par Steinberg parce que la pile audio de base de Windows n’était pas satisfaisante — un peu comme Jack, quoi) pendant que le reste de leurs applications de bureau utilisaient DirectSound.
une autre solution pourrait être d'améliorer jack.
Encore une fois : c’est quoi le problème avec Jack, à part qu’il fait bien son boulot ?
¹ Exemple : Je ne fais pas de MAO, PulseAudio tourne et gère le sons de mes applications. Tiens, je décide de faire un peu de musique. Je lance Rosegarden, qui lance automatiquement Jackd (via D-Bus), PulseAudio cède automatiquement la main tant que Jackd est en service. Bon finalement je ne suis pas inspiré, je fere Rosegarden, Jackd se termine, PulseAudio reprend la main. Je n’ai rien eu à faire, où est la pénibilité ?
Autre exemple (plus réaliste à mon avis, parce qu’un MAOïste même amateur a plus de chance d’avoir une carte son dédiée en plus du chipset son intégré aux carte-mère) : PulseAudio fonctionne et gère le chipset son de la carte-mère pour toutes les applications desktop ; Jackd fonctionne et gère la carte son dédiée pour toutes les applications audio « pro ». En quoi est-ce « pénible » ?
Alors, d’après le billet de blog indiqué dans le journal :
A big part of the motivation for this is that we want to make Fedora Workstation the best place to create content and we want the pro-audio crowd to be first class citizens of our desktop.
Alors, d’une, je ne sais pas pour les utilisateurs de Fedora Workstation mais mour ma part en tant que MAOïste amateur je ne me suis jamais senti « citoyen de seconde classe » sur mon GNU/Linux.
Et de deux, pour être « la meilleure place pour créer du contenu », ce dont on a besoin n’est pas un n-ième framework mais des applications.
Il se trouve que GNU/Linux n’est pas dépourvu d’applications dédiées à la création audio-numérique. Ardour, Rosegarden, Qtractor, Bristol, NON, LMMS… pour ne citer que celles que j’utilise ou ai utilisées (il y en une tripotée d’autres). Leur point commun ? Elles utilisent toutes Jack (en tout cas pour leur version GNU/Linux, dans le cas des applications multi-plateformes).
Vouloir remplacer, sans aucune bonne raison (autre que « on peut le faire »), un composant qui s’est imposé de lui-même comme la pièce maîtresse de l’audio dite « pro » sous GNU/Linux ne va sûrement pas donner aux développeurs desdites applications qu’ils sont des « citoyens de première classe »…
At the same time we don’t want to make this another painful subsystem transition so PipeWire so we will need to ensure that PulseAudio applications can still be run without modification.
Merci. Je note quand même que ce souci d’éviter de trop grandes souffrances ne concerne que les développeurs d’applications utilisant PulseAudio. Développeurs d’applications Jack, vous allez en chier — mais on compte sur vous pour que les créateurs se sentent « citoyens de première classe » sur notre système, hein, ne nous lâchez pas.
We expect to start shipping PipeWire with Fedora Workstation 27, but at that point only have it handle video […] We will the bring the audio features onboard in subsequent releases as we also try to work with the Jack and PulseAudio communities to make this a joint effort.
« Allô, la communauté Jack ? Votre machin, là, que vous avez conçu sur mesure pour répondre pile poil aux besoins de l’audio numérique, et qui semble pas trop mal d’après ce qu’on m’a dit… on vient vous proposer de le remplacer par un truc qu’on a d’abord conçu pour faire complètement autre chose, mais auquel on aimerait bien rajouter après coup des fonctionnalités pour l’audio pro, comme ça en passant. C’est génial comme idée, non ? »
Cette proposition, c’est comme celle de KLANG il y a quelques années, c’est un gros doigt d’honneur à tous ceux qui veulent réellement faire de GNU/Linux une plate-forme sérieuse de création audio-numérique.
Sérieusement : Leave Jack alone! Si ça amuse quelqu’un de vouloir à nouveau « casser l’audio sous GNU/Linux », Poettering-style, grand’bien vous fasse, proposez un remplaçant à PulseAudio, introduisez une nouvelle période de confusion ou personne ne saura quelle est la bonne voie à suivre ou le bon outil à utiliser, donnez du blé à moudre à tous ceux qui se plaignent que la pile audio sous GNU/Linux est un bordel sans nom… mais pitié, laissez les développeurs et utilisateurs de Jack et des outils d’audio-numérique « pro » en dehors de tout ça.
Il s'agit d'une alternative à un autre serveur de son plus ancien nommé Jack, que PulseAudio visait à remplacer, sujet hautement polémique s'il en est.
Bah c’est sûr qu’en présentant les choses de façon erronée, on va susciter des polémiques…
PulseAudio n’a jamais visé à remplacer Jack. PulseAudio visait à remplacer (et a effectivement remplacé) les serveurs de sons de la génération de aRtsd ou EsounD. PulseAudio n’a jamais ne serait-ce que tenté de faire le travail de Jack, de même que Jack n’a jamais tenté de faire le travail de PulseAudio (ce qui n’empêche pas certains utilisateurs de Jack de s’en servir comme d’un serveur de sons généraliste, mais ça n’a jamais été le but).
gérer l'audio d'une manière qui non seulement couvre les cas d'utilisation de PulseAudio, mais aussi ceux gérés par Jack aujourd'hui
Mais pourquoi ? C’est quoi le problème avec Jack ? C’est quoi le problème avec ces outils qui font très bien leur boulot ?
Sans répondre à la question posée, je profite du fait que je tiens ici un créateur de salles d’escape-game pour soumettre une idée qui m’est venue après ma première (et seule, pour l’instant du moins) expérience dans un escape-game.
Et s’il y avait un « traître » dans une équipe d’escape-game ?
Je pensais à quelque chose dans ce genre :
Au début de la partie, chaque membre de l’équipe se voit remettre un petit bout de papier replié avec pour instruction de le déplier à l’abri du regard de ses compagnons.
Tous les papiers distribués sont vierges, sauf un qui contient le message « Vous êtes le traître » (ou assimilé).
Pour les joueurs qui ont un papier vierge, pas de changement, leur objectif est de sortir de la salle.
Pour le « traître », l’objectif est d’empêcher son équipe de sortir, en sabotant subrepticement les efforts de ses compagnons. « Subrepticement » parce que le traître ne doit pas se faire repérer : si l’équipe identifie le traître en son sein, le traître a perdu.
La présence d’un traître dans une équipe ne serait pas systématique : dans certaines parties, tous les papiers distribués aux joueurs seraient vierges. Mais bien sûr l’équipe n’en saurait rien…
Z’en pensez quoi ? C’est une idée à la con, ou non ? Existe-t-il des escape-game ayant implémenté ce genre de principes ?
je veux éviter que les clients "tombent" sur le scénario et perdent la surprise de la salle
Ça me paraît difficilement conciliable avec le simple fait de publier le scénario, même sans parler de le publier sous une licence libre (tu le publierais sans licence, donc sous le coup des règles habituelles du droit d’auteur, que le problème se poserait déjà).
Je dirais que c’est aux joueurs de décider ce qu’ils veulent faire. Je suppose que les amateurs de ce genre de jeux s’abstiendront volontairement de consulter le scénario d’une salle s’ils savent qu’ils ont l’intention de la faire tôt ou tard.
S’il y a des joueurs qui étudient le scénario à l’avance dans le seul but d’exploser le record de la salle, bah c’est dommage mais à mon avis c’est plus dommage pour eux que pour toi…
Bah l’idée « Debian stable = pas pour le bureau » est quand même pas mal répandue par les Debianneux eux-mêmes…
Par exemple, Raphaël Hertzog et Roland Mas, dans les Cahiers de l’admin – Debian Wheezy, écrivent :
Les administrateurs systèmes, soucieux avant tout de la stabilité de leurs serveurs, se moquent de la dernière version de GNOME ; ils opteront pour la Debian Stable et en seront satisfaits. Les utilisateurs finaux, plus intéressés par la dernière version de GNOME ou de KDE que par une stabilité irréprochable, trouveront en Debian Testing un bon compromis entre absence de problèmes graves et logiciels relativement à jour.
N’étant pas moi-même utilisateur de Debian (quelque version que ce soit) sur le desktop, c’est ce passage qui m’a fait demander, mi-ironiquement mi-sérieusement, s’il y avait des utilisateurs de Stable sur bureau…
Le passage de la version par défaut de GnuPG de 1.4 à 2.1 est très important, et pourrait surprendre les utilisateurs de Debian Stable sur desktop (il y en a ?), alors quelques petites remarques sur ce qui change, pêle-mêle.
a) Là où GnuPG 1.x était monolithique (le binaire gpg faisait tout), GnuPG 2.1 a une architecture modulaire (déjà amorcée avec GnuPG 2.0, mais c’est vraiment la branche 2.1 qui a achevé cette transition), comprenant au minimum les composants suivants :
gpg, le programme principal ;
gpg-agent, l’agent de gestion des clefs privées ;
dirmngr, le démon réseau.
(On peut éventuellement y ajouter scdaemon, le démon d’accès aux cartes à puce, si vous utilisez ce genre d’outils.)
L’utilisation des démons auxiliaires est obligatoire (l’utilisation de gpg-agent était facultative avec GnuPG 1.x, ce n’est plus le cas avec GnuPG 2.x). Pas la peine de jouer avec l’option --no-use-agent, elle est silencieusement ignorée.
b) Les clefs privées sont désormais stockées dans le dossier $GNUPGHOME/private-keys-v1.d. Le fichier $GNUPGHOME/secring.gpg n’est plus utilisé. À la première utilisation de GnuPG 2.1, les clefs privées présentes dans secring.gpg seront silencieusement migrées vers private-keys-v1.d.
c) Tous les démons auxiliaires (gpg-agent, dirmngr, scdaemon) sont démarrés automatiquement quand ils sont nécessaires. Cela peut éventuellement surprendre ceux qui utilisaient précédemment GnuPG 2.0 (que Debian fournissait dans le paquet gnupg2), où un script /etc/X11/Xsession.d/90gpg-agent se chargeait de démarrer l’agent au démarrage d’une session.
Similairement, la variable d’environnement GPG_AGENT_INFO, précédemment utilisée pour localiser la socket de l’agent, n’a plus lieu d’être.
La socket en question, d’ailleurs, n’est plus placé dans $GNUPGHOME, mais dans /var/run/user/$(id -u)/gnupg, dossier qui est géré par Systemd. Vous n’avez normalement pas besoin de le savoir, mais ça peut occasionner des surprises voire des désagréments si vous aviez l’habitude de faire des choses un peu « exotiques » avec l’agent GnuPG (aeris devrait pouvoir vous en dire quelques mots — je crois qu’il s’est arraché quelques cheveux sur cette question).
d) Les clefs OpenPGP au format v3 (qui datent de l’époque de PGP 2.6, au milieu des années 1990) ne sont plus du tout prises en charge. Si vous avez encore des données qui traînent chiffrées avec une clef v3, vous aurez besoin de GnuPG 1.x (que Debian fournit désormais sous le nom gnupg1) — auquel cas je vous invite instamment à déchiffrer ces données et à les re-chiffrer avec une clef plus récente.
e) GnuPG 2.1 a introduit un nouveau format de stockage des clefs publiques, le format keybox (fichier $GNUPGHOME/pubring.kbx), plus efficace que l’ancien keyring (fichier $GNUPGHOME/pubring.gpg). Néanmoins, si vous avez déjà utilisé GnuPG ≤ 2.0 et que vous avez donc déjà un fichier pubring.gpg, GnuPG 2.1 continuera à utiliser le fichier existant. Pour migrer vers le nouveau format (ce qui n’est pas obligatoire, remarquez), l’approche recommandée est la suivante :
cd ~/.gnupg
# Exporter les valeurs de confiance
$ gpg --export-ownertrust > otrust.lst
# Renommer le trousseau publique (ancien format) pour qu’il ne soit plus reconnu par GnuPG
$ mv pubring.gpg publickeys
# Ré-importer les clefs publiques; en l’absence de pubring.gpg, GnuPG 2.1 créera automatiquement un fichier keybox
$ gpg --import-options import-local-sigs --import publickeys
# Ré-importer les valeurs de confiance
$ gpg --import-ownertrust otrust.lst
f) La procédure de génération de clefs a été simplifiée : GnuPG génère par défaut des clefs « standard » sans plus demander à l’utilisateur de choisir lui-même l’algorithme, la taille, la date d’expiration (la seule chose demandée est l’identité à associer à la clef). Utilisez la commande --full-gen-key au lieu de --gen-key pour retrouver l’ancienne procédure où vous pouvez spécifier vous-même les caractéristiques de la clef.
g) GnuPG 2.1 prend en charge la cryptographie elliptique, mais par défaut la création de clefs ECC n’est pas accessible, même en utilisant la commande --full-gen-key. Il faut ajouter l’option --expert pour se voir offrir la possibilité de créer une clef ECC.
Ce que je trouve triste, c’est qu’on ait eu à attendre 2017 pour ça. Je veux dire, la problématique de la distribution de clé est loin d’être nouvelle, et l’idée de mettre sous la responsabilité du propriétaire du domaine example.com la distribution des clés des emails en *@example.com c’est pas une idée qui a besoin d’un Einstein pour être découverte.
Il y a eu des tentatives, mais qui n’ont pas vraiment décollé (les enregistrements CERT, dès 1999, ou les enregistrements PKA de GnuPG — cf. mon précédent journal).
Une des causes probables (sûrement pas la seule) est la lenteur du déploiement de DNSSEC. Peu de spécialistes étaient prêts à confier la distribution des clefs au DNS en l’absence de moyen d’authentification.
(C’est un cas somme toute assez classique du mieux ennemi du bien : sans DNSSEC, la publication des clefs dans le DNS n’est pas parfaite, donc on n’en veut pas, parce que pas de sécurité vaut mieux qu’une sécurité imparfaite — ce qui dans certains contextes n’est pas idiot : si les enjeux sont élevés, une technique presque-sûre-mais-pas-complètement peut être dangereuse, si elle fait prendre à ses utilisateurs des risques qu’ils ne prendraient pas autrement.)
la culture de « WoT sinon rien » qui a longtemps prévalu en est grandement responsable.
Oui. Les premièresréactions à l’annonce du modèle TOFU n’ont pas été très positives.
Il n'y a pas d'étude de l'ergonomie du client PGP GnuPG
Pas à ma connaissance en effet.
De toute façon, étudier l’ergonomie d’un outil en ligne de commande que l’utilisateur lambda n’utilise jamais directement (l’utilisateur lambda passe par un front-end graphique, standalone ou intégré à un client mail), quel intérêt ?
Ce serait comme vouloir étudier l’ergonomie d’un compilateur au lieu de celle de l’environnement de développement : quel sens y aurait-il à étudier l’ergonomie de vc.exe, c’est l’ergonomie de Visual Studio qui compte…
Tellement par ailleurs que le fait de lever la moindre critique est un blasphème.
Quand la critique est à ce point à côté de la plaque…
Citer des études de PGP ou Mailvelope pour critiquer l’utilisabilité de GnuPG, c’est à côté de la plaque pour au moins deux raisons :
PGP et Mailvelope sont des outils que l’utilisateur lambda utilise directement ; GnuPG est un backend destinés aux utilisateurs avancés (pour continuer mon exemple ci-dessus, tu cites une étude critiquant Visual Studio pour parler de l’ergonomie de GCC).
Même si PGP et GnuPG étaient tous deux des logiciels avec lesquels les utilisateurs lambdas interagissent directement, ce ne sont pas les mêmes logiciels. C’est comme si tu disais « Thunderbird est inutilisable, pour preuve voici un papier qui dit que Outlook est inutilisable. »
Je ne peux pas interpréter ça autrement que comme une volonté gratuite de cracher sur un logiciel, sans la moindre intention d’être constructif.
Tu veux être constructif ? Alors adresse tes critiques aux bonnes personnes. L’implémentation X d’OpenPGP est inutilisable ? Plains-toi aux développeurs de X au lieu de geindre que les développeurs de Y n’écoutent pas leurs utilisateurs.
Pour information et à ma connaissance, les seuls programmes graphiques (destinés à tous les utilisateurs et non pas seulement à ceux que la ligne de commande ne rebute pas) dans lesquels les développeurs de GnuPG sont plus ou moins impliqués sont :
GPA (GNU Privacy Assistant), développé (au moins en partie) par Werner Koch et Marcus Brinkmann ;
Enigmail (Kai Michaelis, un des contributeurs, est partiellement financé par g10code) ;
KMail.
Si tu as des critiques sur ces logiciels-là, tu peux te répandre et accuser les développeurs de GnuPG.
Il n'y a pas d'étude de l'ergonomie du client PGP GnuPG, un client en ligne de commande ancien (parce que, l'interface n'a probablement pas radicalement changé depuis le début).
Ancien ne veut pas dire obsolète. ET en général, on attend d’un outil en ligne de commande que son interface reste stable, surtout s’il sert de backend pour des outils plus proches de l’utilisateur.
En l'occurrence, quand dans l'étude de 2015, il y a 90% d'échec, on peut affirmer que ce n'est pas ergonomique et que ce n'est pas satisfaisant.
Mais c’est le problème des développeurs d’implémentations purement graphiques (comme PGP ou Mailvelope) ou de front-ends graphiques de GnuPG (comme Enigmail) ! GnuPG fournit le backend.
Toutefois les problèmes d’utilisabilité ne sont pas ignorés par les développeurs de GnuPG. Au contraire une grosse partie des travaux de ces dernières années (listés dans le journal) vise à améliorer l’utilisabilité pour les masses.
Un exemple : l’authentification des clefs. Tout le monde sait que la toile de confiance est trop compliquée à comprendre (encore plus à utiliser) pour le commun des mortels. Aucune interface graphique n’a jamais réussi à rendre ça intuitif, et je pense personnellement que c’est impossible.
Du coup, Neal Walfield a implémenté dans GnuPG un modèle de confiance plus simple, celui de la « confiance au premier contact ». Pour information, lors des premières discussions autour du modèle TOFU, plusieurs personnes ont fait valoir que cette fonctionnalité n’avait rien à faire dans GnuPG et que c’était plutôt le rôle des clients mails. Mais la position des développeurs de GnuPG était que TOFU serait plus utile s’il était implémenté une fois pour toutes dans le backend, plutot que de laisser chaque front-end faire sa sauce. Cette position a prévalu.
Alors certes, pour l’instant, TOFU ne change en rien la vie de l’utilisateur final. Il faut d’abord que les front-ends suivent le mouvement, et exploitent cette nouvelle fonctionnalité du backend (ce qu’aucun front-end ne fait encore à ma connaissance, à part GPA). Mais les développeurs de GnuPG ont fait leur boulot, maintenant la balle est dans le camp des développeurs de front-ends.
Pareil pour la question de la distribution des clefs. Tout est en place, dans GnuPG, pour permettre la publication et la récupération automatique d’une clef, sans aucune intervention de l’utilisateur. Maintenant il faut d’une part des front-ends qui exploitent ça, et d’autre part des fournisseurs de messagerie qui le supportent (on en trouve en Allemagne, comme posteo.de que j’avais cité dans mon précédent journal). Mais au niveau de GnuPG, la fonctionnalité est là.
Ça ne se voit peut-être pas, mais on va arriver progressivement à une situation où les messages de « Johnny » seront chiffrés sans qu’il n’ait rien à faire.
Tu peux cracher ta bile tant que tu veux, mais je réfute catégoriquement l’idée que les développeurs de GnuPG sont sourds aux remarques des utilisateurs et se moquent éperdument des questions d’utilisabilité.
(Je savais que j’aurais du inclure dans mon journal un petit historique pour rappeler aux gens que GnuPG ≠ PGP. Il faudra que j’y pense la prochaine fois.)
Ce papier concerne Mailvelope, une implémentation d’OpenPGP pour navigateurs web, sans aucun rapport avec GnuPG.
(Note pour le prochain journal : rappeler que OpenPGP ≠ PGP ≠ GnuPG, le premier est un protocole, les deux autres en sont des implémentations. Tip : peut-être rappeler que c’est comme SMTP ≠ Thunderbird ?)
Un commentaire malgré tout sur le papier en question parce que c’est quand même du lourd :
This paper presents the results of a laboratory study involving Mailvelope, a modern PGP client […] Our results shown [sic] that more than a decade and a half after Why Johnny Can’t Encrypt, modern PGP tools are still unusable for the masses.
Il s’agit simplement d’un bref commentaire de Schneier sur le papier précédent, donc qui ne concerne toujours pas GnuPG.
Je note tout de même que la « solution » de Schneier est de laisser purement et simplement tomber l’email, et de passer par des solutions centralisées de type Signal.
Merci aux développeurs de GnuPG et des autres implémentations d’OpenPGP de ne pas se résigner si facilement et de faire quelque chose, pendant que les chercheurs pondent leurs jolis articles pour dire que ce qu’on leur propose ne les satisfait pas.
Bah à la base j’étais parti pour un journal bookmark : le lien vers le site de la campagne, deux-trois mots de contexte autour et rien de plus. Je ne sais pas ce qui s’est passé, les « deux-trois mots » se sont transformés en deux-trois sections…
Je ne connais pas le niveau des cotisation patronal en Allemagne mais a ne fait qu'un «petit» salaire brut si on enlève 50% comme en France, non ?
Si j’en crois cette page, les cotisations patronales outre-Rhin seraient plutôt de l’ordre de 20%. Ça ferait un brut à environ 4 000 euros par mois, après je ne sais pas du tout où ça se situe par rapport à ce que peut espérer un développeur en Allemagne…
Ce que j'aimerais, c'est de pouvoir suivre des liens de façon à pouvoir par exemple à partir de sed, avoir le man en français, des exemples avec une coloration syntaxique, un tutoriel, le code source de sed…
Tous les formats de documentation à l’exception de celui des pages de manuel permettent les liens hypertextes, je ne vois pas ce qui te manque ou ce qu’un nouveau format apporterait.
Pour avoir de la bonne documentation (avec des tutoriels et « un bon ouvrage de référence »), il faut… écrire de la documentation. Les formats pour ça ne manquent pas. Ajouter un n-ième format ne vas pas automagiquement faire apparaître de la documentation ou subitement faire naître des vocations de rédacteurs.
Une unification autour d’un schéma XML serait infiniment préférable afin de générer au choix, HTML, PDF, DocBook, ePub
Pour information, à partir d’une source en Texinfo on peut déjà générer au choix (en plus de l’info) du HTML, du PDF, du DocBook.
Et puis, si on voulait une source de base en XML plutôt qu’en Texinfo, pourquoi inventer un nouveau schéma au lieu de partir sur du DocBook qui est quand même fait pour ça ?
il faut que les programmeurs aient connaissance que telle ou telle fonction ne soient pas dans le standard.
Oui. Et pour ça, les pages de manuel sous Linux ont généralement une rubrique CONFORMING TO indiquant quel standard définit les fonctions décrites dans les pages ou sur quel(s) système(s) elles sont disponibles.
Par exemple, la page de manuel de stat(2) indique :
Les subtilités pouvant poser problème à des programmes se voulant portables (par exemple, une fonction qui existe sous plusieurs systèmes mais dont le comportement n’est pas complètement identique) sont aussi en principe indiquées dans cette rubrique.
Bon, certes, là il s'agit d'une spécification POSIX, AIX n'a fait que se conformer à ces spécifications.
Non, à ma connaissance POSIX définit stat mais pas statx. L’appel statx fournit par AIX est une extension non-standard, exactement comme le statx qui vient d’être ajouté à Linux.
Je pense donc que plus beaucoup de gens ne s'intéresse à POSIX, me gourre-je ?
C’est plutôt qu’on ne se limite pas à implémenter uniquement ce que propose POSIX. Tous les systèmes ajoutent leurs propres extensions à un moment ou à un autre, Linux et AIX sont loin d’être les seuls à le faire. Parfois chacun fait ça seul dans son coin, parfois il y a un peu de concertation entre les différents systèmes, parfois encore un système invente une extension et elle est reprise par les autres…
Est-ce qu'un autre logiciel qui fonctionne sur le même principe serait en mesure de déverrouiller mes données ?
Non. Le logiciel en question utilise bien un algorithme de chiffrement standard (AES), mais le format de fichier lui n’est pas standard. Pour qu’un autre logiciel puisse déchiffrer des fichiers chiffrés avec AESCrypt, il doit spécifiquement implémenter la prise en charge de ce format.
Et la description du format m’a l’air un peu trop succinte. En particulier, il manque l’info relative à la dérivation de la clef (comment la phrase de passe entrée par l’utilisateur est-elle transformée en clef de chiffrement utilisable par AES).
Puis quand je vois ça :
16 Octets - Initialization Vector (IV) used for encrypting the
IV and symmetric key that is actually used to encrypt
the bulk of the plaintext file.
48 Octets - Encrypted IV and 256-bit AES key used to encrypt the
bulk of the file
16 octets - initialization vector
32 octets - encryption key
Ça ne m’inspire pas trop confiance : l’IV n’a normalement pas besoin d’être chiffré, que l’auteur ait cru bon de le faire n’est pas rassurant à mon avis.
tant que je n'ai pas ouvert le traffic sur ipv4 en OUTPUT sur le port TCP 53.
Donc ce serait un problème de résolution DNS. Pourtant le domaine sks-keyservers.net a bien des serveurs de noms répondant en IPv6, une machine « IPv6-only » devrait pouvoir résoudre ipv6.pool.sks-keyservers.net.
Difficile d’en dire plus sans davantage d’infos sur ta machine, notamment sa configuration DNS (tu utilises le résolveur du FAI ? ton propre résolveur ?)…
Est-ce que ça existe un logiciel qui, plutôt que d'aller chercher une clé sur un seul serveur HKP, va la chercher sur plusieurs et compare les réponses obtenues des différents serveurs ?
Pas à ma connaissance.
Mais est-ce qu'il ne vaut pas mieux le faire quand même ? […]
Dans le cas du pool hkps.pool.sks-keyservers.net, non, spécifier explicitement le certificat racine ne sert (plus) à rien (même si ça ne fait pas de mal non plus). Dès lors que tu utilises ce pool (que ce soit parce que tu l’as explicitement demandé ou parce que, depuis GnuPG 2.1.16, tu utilises le réglage par défaut), GnuPG ne tentera de valider les certificats des serveurs que contre le certificat racine du pool SKS (qui est directement inclus dans le code de GnuPG). Si quelqu’un tente de se faire passer pour un serveur du pool SKS avec un certificat signé par n’importe quelle autre autorité (y compris une autorité « reconnue » comme Verisign & Co), ça ne passera pas.
Dans le cas d’un éventuel autre serveur/pool, là oui, il peut être judicieux de spécifier explicitement le certificat racine, même s’il s’agit d’une autorité reconnue et donc présente dans le magasin du système).
Toutes les options relatives aux serveurs de clefs doivent aller dans dirmngr.conf :
keyserver pour indiquer le serveur de clefs à utiliser (seulement utile avecGnuPG < 2.1.16 ou, avec GnuPG ≥ 2.1.16, pour utiliser autre chose que le pool hkps.pool.sks-keyservers.net) ;
hkp-cacert pour le certificat racine des serveurs HKPS (là aussi, seulement utile si tu ne veux pas utiliser le pool par défaut) ;
use-tor pour accéder aux serveurs de clefs via Tor.
Dirmngr a d’autres options dont l’utilité est plus rare, cf man dirmngr pour une liste complète.
À partir de la version 2.1.16, le cas le plus courant est en fait de ne même pas avoir besoin d’un fichier dirmngr.conf, car les options par défaut devraient être satisfaisantes pour la plupart des utilisateurs.
Toutes les autres options citées (notamment --auto-key-locate) vont dans gpg.conf.
Euh, ça ce n’était pas une coquille, c’était l’expression voulue, dans le sens où « quiconque est capable de faire gpg2 --send-keys est capable de déposer une clef au nom de n’importe qui ».
Mais il y a hélas d’autres corrections à faire si un modérateur passe par là :
Section Le protocole HKP, 1er paragraphe : « il utilise le port TCP 11371 ou, dans sa version sécurisée par TLS (HKPS), par le port HTTPS standard 443 »
Section Les serveurs LDAP, 1er paragraphe : espace manquant entre les deux liens « plusieurs endroits »
Section Les enregistrements PKA, 4ème paragraphe : Les enregistrements PKAv1 ne sont plus supportés depuis GnuPG 2.1.3 (et non 2.1.13)
Section Le Web Key Directory, 3ème paragraphe : « La première étape est de demander le (ou les) enregistrement(s) SRV associé(s) a nom… »
Dans le cas d’un (petit) groupe de personnes qui se connaissent tous et qui se contactent directement (c’es-à-dire que A envoie lui-même le message à B, C, et D sans intermédiaire, B répond directement à A, C, et D sans intermédiaire, etc.), il n’y a rien de spécial à faire.
Chaque personne génère sa paire de clefs personnelle et s’arrange pour communiquer sa clef publique aux autres. Ensuite, à chaque envoi, le message sera chiffré avec la clef de chaque destinataire, et chaque destinataire le déchiffrera avec sa clef privée.
(En interne, ce qui se passe est que le message sera chiffré une seule fois avec une clef de session unique, et c’est la clef de session qui sera chiffrée plusieurs fois avec les clefs publiques des différents destinataires. Le message final de A à B, C, D ressemblera à ça :
clef de session chiffré avec la clef publique de B
clef de session chiffré avec la clef publique de C
clef de session chiffré avec la clef publique de D
message chiffré avec la clef de session
les clefs de session chiffrées étant normalement petites comparées au message lui-même, cette méthode n’augmente pas significativement la taille du message final.)
Qu'est ce qu'il se passe si mon horloge locale est complètement désynchro, genre 2 mois dans le passé?
« Qui diable de sérieux voudrait faire ça en premier lieu ? »
Une telle désynchronisation t’expose à pas mal de problèmes indépendamment des mises à jour de ton antivirus. Notamment, vis-à-vis des périodes de validité des certificats X.509 (et dans une moindre mesure les signatures DNSSEC, mais comme rares sont ceux qui signent leur zone et encore plus rares sont ceux qui vérifient les signatures, je reconnais que c’est moins gênant).
[^] # Re: Leave Jack alone!
Posté par gouttegd . En réponse au journal PipeWire veut unifier la gestion des flux audio et video. Évalué à 7.
Et donc on se retrouvera avec non pas une mais deux piles audio pouvant être utilisées pour l’audio-numérique « pro ». Avec des applications qui supporteront l’une, des applications qui supporteront l’autre, des systèmes où l’une sera installée par défaut mais pas l’autre, des utilisateurs qui n’y comprendront rien et qui viendront demander sur les forums « pourquoi c’est si compliqué l’audio sous GNU/Linux, je vais retourner sur MacOS X »…
Y’a pas à dire, les « créateurs de contenus » vont vraiment se sentir des « citoyens de première classe » avec une idée pareille.
[^] # Re: Leave Jack alone!
Posté par gouttegd . En réponse au journal PipeWire veut unifier la gestion des flux audio et video. Évalué à 5.
Étant donné que ça peut se faire complètement tout seul¹, je ne vois pas en quoi « ce n’est pas pratique ».
Ça n’a jamais dérangé les MAOïstes sous Windows d’avoir leurs diverses applications audio fonctionnant avec ASIO (en gros une pile audio spécifique à l’audio pro, inventé par Steinberg parce que la pile audio de base de Windows n’était pas satisfaisante — un peu comme Jack, quoi) pendant que le reste de leurs applications de bureau utilisaient DirectSound.
Encore une fois : c’est quoi le problème avec Jack, à part qu’il fait bien son boulot ?
¹ Exemple : Je ne fais pas de MAO, PulseAudio tourne et gère le sons de mes applications. Tiens, je décide de faire un peu de musique. Je lance Rosegarden, qui lance automatiquement Jackd (via D-Bus), PulseAudio cède automatiquement la main tant que Jackd est en service. Bon finalement je ne suis pas inspiré, je fere Rosegarden, Jackd se termine, PulseAudio reprend la main. Je n’ai rien eu à faire, où est la pénibilité ?
Autre exemple (plus réaliste à mon avis, parce qu’un MAOïste même amateur a plus de chance d’avoir une carte son dédiée en plus du chipset son intégré aux carte-mère) : PulseAudio fonctionne et gère le chipset son de la carte-mère pour toutes les applications desktop ; Jackd fonctionne et gère la carte son dédiée pour toutes les applications audio « pro ». En quoi est-ce « pénible » ?
[^] # Re: Leave Jack alone!
Posté par gouttegd . En réponse au journal PipeWire veut unifier la gestion des flux audio et video. Évalué à 10.
Alors, d’après le billet de blog indiqué dans le journal :
Alors, d’une, je ne sais pas pour les utilisateurs de Fedora Workstation mais mour ma part en tant que MAOïste amateur je ne me suis jamais senti « citoyen de seconde classe » sur mon GNU/Linux.
Et de deux, pour être « la meilleure place pour créer du contenu », ce dont on a besoin n’est pas un n-ième framework mais des applications.
Il se trouve que GNU/Linux n’est pas dépourvu d’applications dédiées à la création audio-numérique. Ardour, Rosegarden, Qtractor, Bristol, NON, LMMS… pour ne citer que celles que j’utilise ou ai utilisées (il y en une tripotée d’autres). Leur point commun ? Elles utilisent toutes Jack (en tout cas pour leur version GNU/Linux, dans le cas des applications multi-plateformes).
Vouloir remplacer, sans aucune bonne raison (autre que « on peut le faire »), un composant qui s’est imposé de lui-même comme la pièce maîtresse de l’audio dite « pro » sous GNU/Linux ne va sûrement pas donner aux développeurs desdites applications qu’ils sont des « citoyens de première classe »…
Merci. Je note quand même que ce souci d’éviter de trop grandes souffrances ne concerne que les développeurs d’applications utilisant PulseAudio. Développeurs d’applications Jack, vous allez en chier — mais on compte sur vous pour que les créateurs se sentent « citoyens de première classe » sur notre système, hein, ne nous lâchez pas.
« Allô, la communauté Jack ? Votre machin, là, que vous avez conçu sur mesure pour répondre pile poil aux besoins de l’audio numérique, et qui semble pas trop mal d’après ce qu’on m’a dit… on vient vous proposer de le remplacer par un truc qu’on a d’abord conçu pour faire complètement autre chose, mais auquel on aimerait bien rajouter après coup des fonctionnalités pour l’audio pro, comme ça en passant. C’est génial comme idée, non ? »
Cette proposition, c’est comme celle de KLANG il y a quelques années, c’est un gros doigt d’honneur à tous ceux qui veulent réellement faire de GNU/Linux une plate-forme sérieuse de création audio-numérique.
Sérieusement : Leave Jack alone! Si ça amuse quelqu’un de vouloir à nouveau « casser l’audio sous GNU/Linux », Poettering-style, grand’bien vous fasse, proposez un remplaçant à PulseAudio, introduisez une nouvelle période de confusion ou personne ne saura quelle est la bonne voie à suivre ou le bon outil à utiliser, donnez du blé à moudre à tous ceux qui se plaignent que la pile audio sous GNU/Linux est un bordel sans nom… mais pitié, laissez les développeurs et utilisateurs de Jack et des outils d’audio-numérique « pro » en dehors de tout ça.
# Leave Jack alone!
Posté par gouttegd . En réponse au journal PipeWire veut unifier la gestion des flux audio et video. Évalué à 10.
Bah c’est sûr qu’en présentant les choses de façon erronée, on va susciter des polémiques…
PulseAudio n’a jamais visé à remplacer Jack. PulseAudio visait à remplacer (et a effectivement remplacé) les serveurs de sons de la génération de aRtsd ou EsounD. PulseAudio n’a jamais ne serait-ce que tenté de faire le travail de Jack, de même que Jack n’a jamais tenté de faire le travail de PulseAudio (ce qui n’empêche pas certains utilisateurs de Jack de s’en servir comme d’un serveur de sons généraliste, mais ça n’a jamais été le but).
Mais pourquoi ? C’est quoi le problème avec Jack ? C’est quoi le problème avec ces outils qui font très bien leur boulot ?
# Hors-sujet : escape-game avec notion de traîtrise
Posté par gouttegd . En réponse au journal Quid de l'escape-game open-source ?. Évalué à 10.
Sans répondre à la question posée, je profite du fait que je tiens ici un créateur de salles d’escape-game pour soumettre une idée qui m’est venue après ma première (et seule, pour l’instant du moins) expérience dans un escape-game.
Et s’il y avait un « traître » dans une équipe d’escape-game ?
Je pensais à quelque chose dans ce genre :
La présence d’un traître dans une équipe ne serait pas systématique : dans certaines parties, tous les papiers distribués aux joueurs seraient vierges. Mais bien sûr l’équipe n’en saurait rien…
Z’en pensez quoi ? C’est une idée à la con, ou non ? Existe-t-il des escape-game ayant implémenté ce genre de principes ?
# Effet de surprise
Posté par gouttegd . En réponse au journal Quid de l'escape-game open-source ?. Évalué à 6.
Ça me paraît difficilement conciliable avec le simple fait de publier le scénario, même sans parler de le publier sous une licence libre (tu le publierais sans licence, donc sous le coup des règles habituelles du droit d’auteur, que le problème se poserait déjà).
Je dirais que c’est aux joueurs de décider ce qu’ils veulent faire. Je suppose que les amateurs de ce genre de jeux s’abstiendront volontairement de consulter le scénario d’une salle s’ils savent qu’ils ont l’intention de la faire tôt ou tard.
S’il y a des joueurs qui étudient le scénario à l’avance dans le seul but d’exploser le record de la salle, bah c’est dommage mais à mon avis c’est plus dommage pour eux que pour toi…
[^] # Re: Utilisation bureau.
Posté par gouttegd . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 4. Dernière modification le 20 juin 2017 à 20:19.
Bah l’idée « Debian stable = pas pour le bureau » est quand même pas mal répandue par les Debianneux eux-mêmes…
Par exemple, Raphaël Hertzog et Roland Mas, dans les Cahiers de l’admin – Debian Wheezy, écrivent :
N’étant pas moi-même utilisateur de Debian (quelque version que ce soit) sur le desktop, c’est ce passage qui m’a fait demander, mi-ironiquement mi-sérieusement, s’il y avait des utilisateurs de Stable sur bureau…
# GnuPG 1.4 → 2.1
Posté par gouttegd . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 10.
Le passage de la version par défaut de GnuPG de 1.4 à 2.1 est très important, et pourrait surprendre les utilisateurs de Debian Stable sur desktop (il y en a ?), alors quelques petites remarques sur ce qui change, pêle-mêle.
a) Là où GnuPG 1.x était monolithique (le binaire gpg faisait tout), GnuPG 2.1 a une architecture modulaire (déjà amorcée avec GnuPG 2.0, mais c’est vraiment la branche 2.1 qui a achevé cette transition), comprenant au minimum les composants suivants :
(On peut éventuellement y ajouter scdaemon, le démon d’accès aux cartes à puce, si vous utilisez ce genre d’outils.)
L’utilisation des démons auxiliaires est obligatoire (l’utilisation de gpg-agent était facultative avec GnuPG 1.x, ce n’est plus le cas avec GnuPG 2.x). Pas la peine de jouer avec l’option
--no-use-agent, elle est silencieusement ignorée.b) Les clefs privées sont désormais stockées dans le dossier
$GNUPGHOME/private-keys-v1.d. Le fichier$GNUPGHOME/secring.gpgn’est plus utilisé. À la première utilisation de GnuPG 2.1, les clefs privées présentes danssecring.gpgseront silencieusement migrées versprivate-keys-v1.d.c) Tous les démons auxiliaires (gpg-agent, dirmngr, scdaemon) sont démarrés automatiquement quand ils sont nécessaires. Cela peut éventuellement surprendre ceux qui utilisaient précédemment GnuPG 2.0 (que Debian fournissait dans le paquet gnupg2), où un script
/etc/X11/Xsession.d/90gpg-agentse chargeait de démarrer l’agent au démarrage d’une session.Similairement, la variable d’environnement
GPG_AGENT_INFO, précédemment utilisée pour localiser la socket de l’agent, n’a plus lieu d’être.La socket en question, d’ailleurs, n’est plus placé dans $GNUPGHOME, mais dans
/var/run/user/$(id -u)/gnupg, dossier qui est géré par Systemd. Vous n’avez normalement pas besoin de le savoir, mais ça peut occasionner des surprises voire des désagréments si vous aviez l’habitude de faire des choses un peu « exotiques » avec l’agent GnuPG (aeris devrait pouvoir vous en dire quelques mots — je crois qu’il s’est arraché quelques cheveux sur cette question).d) Les clefs OpenPGP au format v3 (qui datent de l’époque de PGP 2.6, au milieu des années 1990) ne sont plus du tout prises en charge. Si vous avez encore des données qui traînent chiffrées avec une clef v3, vous aurez besoin de GnuPG 1.x (que Debian fournit désormais sous le nom gnupg1) — auquel cas je vous invite instamment à déchiffrer ces données et à les re-chiffrer avec une clef plus récente.
e) GnuPG 2.1 a introduit un nouveau format de stockage des clefs publiques, le format keybox (fichier
$GNUPGHOME/pubring.kbx), plus efficace que l’ancien keyring (fichier$GNUPGHOME/pubring.gpg). Néanmoins, si vous avez déjà utilisé GnuPG ≤ 2.0 et que vous avez donc déjà un fichierpubring.gpg, GnuPG 2.1 continuera à utiliser le fichier existant. Pour migrer vers le nouveau format (ce qui n’est pas obligatoire, remarquez), l’approche recommandée est la suivante :f) La procédure de génération de clefs a été simplifiée : GnuPG génère par défaut des clefs « standard » sans plus demander à l’utilisateur de choisir lui-même l’algorithme, la taille, la date d’expiration (la seule chose demandée est l’identité à associer à la clef). Utilisez la commande
--full-gen-keyau lieu de--gen-keypour retrouver l’ancienne procédure où vous pouvez spécifier vous-même les caractéristiques de la clef.g) GnuPG 2.1 prend en charge la cryptographie elliptique, mais par défaut la création de clefs ECC n’est pas accessible, même en utilisant la commande
--full-gen-key. Il faut ajouter l’option--expertpour se voir offrir la possibilité de créer une clef ECC.[^] # Re: Et l'ergonomie de gpg, on en parle ?
Posté par gouttegd . En réponse au journal GnuPG lance une nouvelle campagne de financement. Évalué à 5.
Il y a eu des tentatives, mais qui n’ont pas vraiment décollé (les enregistrements CERT, dès 1999, ou les enregistrements PKA de GnuPG — cf. mon précédent journal).
Une des causes probables (sûrement pas la seule) est la lenteur du déploiement de DNSSEC. Peu de spécialistes étaient prêts à confier la distribution des clefs au DNS en l’absence de moyen d’authentification.
(C’est un cas somme toute assez classique du mieux ennemi du bien : sans DNSSEC, la publication des clefs dans le DNS n’est pas parfaite, donc on n’en veut pas, parce que pas de sécurité vaut mieux qu’une sécurité imparfaite — ce qui dans certains contextes n’est pas idiot : si les enjeux sont élevés, une technique presque-sûre-mais-pas-complètement peut être dangereuse, si elle fait prendre à ses utilisateurs des risques qu’ils ne prendraient pas autrement.)
Oui. Les premières réactions à l’annonce du modèle TOFU n’ont pas été très positives.
[^] # Re: Et l'ergonomie de gpg, on en parle ?
Posté par gouttegd . En réponse au journal GnuPG lance une nouvelle campagne de financement. Évalué à 5.
Pas à ma connaissance en effet.
De toute façon, étudier l’ergonomie d’un outil en ligne de commande que l’utilisateur lambda n’utilise jamais directement (l’utilisateur lambda passe par un front-end graphique, standalone ou intégré à un client mail), quel intérêt ?
Ce serait comme vouloir étudier l’ergonomie d’un compilateur au lieu de celle de l’environnement de développement : quel sens y aurait-il à étudier l’ergonomie de vc.exe, c’est l’ergonomie de Visual Studio qui compte…
Quand la critique est à ce point à côté de la plaque…
Citer des études de PGP ou Mailvelope pour critiquer l’utilisabilité de GnuPG, c’est à côté de la plaque pour au moins deux raisons :
Je ne peux pas interpréter ça autrement que comme une volonté gratuite de cracher sur un logiciel, sans la moindre intention d’être constructif.
Tu veux être constructif ? Alors adresse tes critiques aux bonnes personnes. L’implémentation X d’OpenPGP est inutilisable ? Plains-toi aux développeurs de X au lieu de geindre que les développeurs de Y n’écoutent pas leurs utilisateurs.
Pour information et à ma connaissance, les seuls programmes graphiques (destinés à tous les utilisateurs et non pas seulement à ceux que la ligne de commande ne rebute pas) dans lesquels les développeurs de GnuPG sont plus ou moins impliqués sont :
Si tu as des critiques sur ces logiciels-là, tu peux te répandre et accuser les développeurs de GnuPG.
Ancien ne veut pas dire obsolète. ET en général, on attend d’un outil en ligne de commande que son interface reste stable, surtout s’il sert de backend pour des outils plus proches de l’utilisateur.
Mais c’est le problème des développeurs d’implémentations purement graphiques (comme PGP ou Mailvelope) ou de front-ends graphiques de GnuPG (comme Enigmail) ! GnuPG fournit le backend.
Toutefois les problèmes d’utilisabilité ne sont pas ignorés par les développeurs de GnuPG. Au contraire une grosse partie des travaux de ces dernières années (listés dans le journal) vise à améliorer l’utilisabilité pour les masses.
Un exemple : l’authentification des clefs. Tout le monde sait que la toile de confiance est trop compliquée à comprendre (encore plus à utiliser) pour le commun des mortels. Aucune interface graphique n’a jamais réussi à rendre ça intuitif, et je pense personnellement que c’est impossible.
Du coup, Neal Walfield a implémenté dans GnuPG un modèle de confiance plus simple, celui de la « confiance au premier contact ». Pour information, lors des premières discussions autour du modèle TOFU, plusieurs personnes ont fait valoir que cette fonctionnalité n’avait rien à faire dans GnuPG et que c’était plutôt le rôle des clients mails. Mais la position des développeurs de GnuPG était que TOFU serait plus utile s’il était implémenté une fois pour toutes dans le backend, plutot que de laisser chaque front-end faire sa sauce. Cette position a prévalu.
Alors certes, pour l’instant, TOFU ne change en rien la vie de l’utilisateur final. Il faut d’abord que les front-ends suivent le mouvement, et exploitent cette nouvelle fonctionnalité du backend (ce qu’aucun front-end ne fait encore à ma connaissance, à part GPA). Mais les développeurs de GnuPG ont fait leur boulot, maintenant la balle est dans le camp des développeurs de front-ends.
Pareil pour la question de la distribution des clefs. Tout est en place, dans GnuPG, pour permettre la publication et la récupération automatique d’une clef, sans aucune intervention de l’utilisateur. Maintenant il faut d’une part des front-ends qui exploitent ça, et d’autre part des fournisseurs de messagerie qui le supportent (on en trouve en Allemagne, comme posteo.de que j’avais cité dans mon précédent journal). Mais au niveau de GnuPG, la fonctionnalité est là.
Ça ne se voit peut-être pas, mais on va arriver progressivement à une situation où les messages de « Johnny » seront chiffrés sans qu’il n’ait rien à faire.
Tu peux cracher ta bile tant que tu veux, mais je réfute catégoriquement l’idée que les développeurs de GnuPG sont sourds aux remarques des utilisateurs et se moquent éperdument des questions d’utilisabilité.
[^] # Re: Et l'ergonomie de gpg, on en parle ?
Posté par gouttegd . En réponse au journal GnuPG lance une nouvelle campagne de financement. Évalué à 7. Dernière modification le 09 juin 2017 à 00:15.
Ce papier concerne PGP, pas GnuPG.
(Je savais que j’aurais du inclure dans mon journal un petit historique pour rappeler aux gens que GnuPG ≠ PGP. Il faudra que j’y pense la prochaine fois.)
Ce papier concerne Mailvelope, une implémentation d’OpenPGP pour navigateurs web, sans aucun rapport avec GnuPG.
(Note pour le prochain journal : rappeler que OpenPGP ≠ PGP ≠ GnuPG, le premier est un protocole, les deux autres en sont des implémentations. Tip : peut-être rappeler que c’est comme SMTP ≠ Thunderbird ?)
Un commentaire malgré tout sur le papier en question parce que c’est quand même du lourd :
Ça ressemble à un syllogisme foiré :
Il s’agit simplement d’un bref commentaire de Schneier sur le papier précédent, donc qui ne concerne toujours pas GnuPG.
Je note tout de même que la « solution » de Schneier est de laisser purement et simplement tomber l’email, et de passer par des solutions centralisées de type Signal.
Merci aux développeurs de GnuPG et des autres implémentations d’OpenPGP de ne pas se résigner si facilement et de faire quelque chose, pendant que les chercheurs pondent leurs jolis articles pour dire que ce qu’on leur propose ne les satisfait pas.
[^] # Re: Promouvoir en dépêche !
Posté par gouttegd . En réponse au journal GnuPG lance une nouvelle campagne de financement. Évalué à 5.
Bah à la base j’étais parti pour un journal bookmark : le lien vers le site de la campagne, deux-trois mots de contexte autour et rien de plus. Je ne sais pas ce qui s’est passé, les « deux-trois mots » se sont transformés en deux-trois sections…
(Et puis la dernière campagne avait elle aussi fait l’objet d’un journal initialement.)
[^] # Re: 15.000€/mois pour 3 dev ?
Posté par gouttegd . En réponse au journal GnuPG lance une nouvelle campagne de financement. Évalué à 3.
Si j’en crois cette page, les cotisations patronales outre-Rhin seraient plutôt de l’ordre de 20%. Ça ferait un brut à environ 4 000 euros par mois, après je ne sais pas du tout où ça se situe par rapport à ce que peut espérer un développeur en Allemagne…
[^] # Re: Bonne initiative
Posté par gouttegd . En réponse à la dépêche Nouvelles versions logicielles du projet GNU avril et mai 2017. Évalué à 4.
Tous les formats de documentation à l’exception de celui des pages de manuel permettent les liens hypertextes, je ne vois pas ce qui te manque ou ce qu’un nouveau format apporterait.
Pour avoir de la bonne documentation (avec des tutoriels et « un bon ouvrage de référence »), il faut… écrire de la documentation. Les formats pour ça ne manquent pas. Ajouter un n-ième format ne vas pas automagiquement faire apparaître de la documentation ou subitement faire naître des vocations de rédacteurs.
[^] # Re: Bonne initiative
Posté par gouttegd . En réponse à la dépêche Nouvelles versions logicielles du projet GNU avril et mai 2017. Évalué à 6.
Pour information, à partir d’une source en Texinfo on peut déjà générer au choix (en plus de l’info) du HTML, du PDF, du DocBook.
Et puis, si on voulait une source de base en XML plutôt qu’en Texinfo, pourquoi inventer un nouveau schéma au lieu de partir sur du DocBook qui est quand même fait pour ça ?
[^] # Re: linux, statx et Unix proprio
Posté par gouttegd . En réponse à la dépêche Sortie du noyau Linux 4.11. Évalué à 4.
Oui. Et pour ça, les pages de manuel sous Linux ont généralement une rubrique CONFORMING TO indiquant quel standard définit les fonctions décrites dans les pages ou sur quel(s) système(s) elles sont disponibles.
Par exemple, la page de manuel de stat(2) indique :
Les subtilités pouvant poser problème à des programmes se voulant portables (par exemple, une fonction qui existe sous plusieurs systèmes mais dont le comportement n’est pas complètement identique) sont aussi en principe indiquées dans cette rubrique.
[^] # Re: linux, statx et Unix proprio
Posté par gouttegd . En réponse à la dépêche Sortie du noyau Linux 4.11. Évalué à 9.
Non, à ma connaissance POSIX définit
statmais passtatx. L’appelstatxfournit par AIX est une extension non-standard, exactement comme lestatxqui vient d’être ajouté à Linux.C’est plutôt qu’on ne se limite pas à implémenter uniquement ce que propose POSIX. Tous les systèmes ajoutent leurs propres extensions à un moment ou à un autre, Linux et AIX sont loin d’être les seuls à le faire. Parfois chacun fait ça seul dans son coin, parfois il y a un peu de concertation entre les différents systèmes, parfois encore un système invente une extension et elle est reprise par les autres…
[^] # Re: Non
Posté par gouttegd . En réponse au message Logiciel chiffrement . Évalué à 7.
GnuPG, ou tout autre logiciel implémentant le RFC 4880 (OpenPGP). C’est un format standard.
# Non
Posté par gouttegd . En réponse au message Logiciel chiffrement . Évalué à 8.
En supposant qu’il s’agit de ce logiciel,
Non. Le logiciel en question utilise bien un algorithme de chiffrement standard (AES), mais le format de fichier lui n’est pas standard. Pour qu’un autre logiciel puisse déchiffrer des fichiers chiffrés avec AESCrypt, il doit spécifiquement implémenter la prise en charge de ce format.
Et la description du format m’a l’air un peu trop succinte. En particulier, il manque l’info relative à la dérivation de la clef (comment la phrase de passe entrée par l’utilisateur est-elle transformée en clef de chiffrement utilisable par AES).
Puis quand je vois ça :
Ça ne m’inspire pas trop confiance : l’IV n’a normalement pas besoin d’être chiffré, que l’auteur ait cru bon de le faire n’est pas rassurant à mon avis.
[^] # Re: GPG impossible en IPv6 ?
Posté par gouttegd . En réponse au journal De la distribution des clefs OpenPGP. Évalué à 2.
Donc ce serait un problème de résolution DNS. Pourtant le domaine
sks-keyservers.neta bien des serveurs de noms répondant en IPv6, une machine « IPv6-only » devrait pouvoir résoudreipv6.pool.sks-keyservers.net.Difficile d’en dire plus sans davantage d’infos sur ta machine, notamment sa configuration DNS (tu utilises le résolveur du FAI ? ton propre résolveur ?)…
[^] # Re: 2 questions
Posté par gouttegd . En réponse au journal De la distribution des clefs OpenPGP. Évalué à 5.
Pas à ma connaissance.
Dans le cas du pool hkps.pool.sks-keyservers.net, non, spécifier explicitement le certificat racine ne sert (plus) à rien (même si ça ne fait pas de mal non plus). Dès lors que tu utilises ce pool (que ce soit parce que tu l’as explicitement demandé ou parce que, depuis GnuPG 2.1.16, tu utilises le réglage par défaut), GnuPG ne tentera de valider les certificats des serveurs que contre le certificat racine du pool SKS (qui est directement inclus dans le code de GnuPG). Si quelqu’un tente de se faire passer pour un serveur du pool SKS avec un certificat signé par n’importe quelle autre autorité (y compris une autorité « reconnue » comme Verisign & Co), ça ne passera pas.
Dans le cas d’un éventuel autre serveur/pool, là oui, il peut être judicieux de spécifier explicitement le certificat racine, même s’il s’agit d’une autorité reconnue et donc présente dans le magasin du système).
[^] # Re: dirmngr.conf / gpg.conf
Posté par gouttegd . En réponse au journal De la distribution des clefs OpenPGP. Évalué à 4.
Toutes les options relatives aux serveurs de clefs doivent aller dans
dirmngr.conf:keyserverpour indiquer le serveur de clefs à utiliser (seulement utile avecGnuPG < 2.1.16 ou, avec GnuPG ≥ 2.1.16, pour utiliser autre chose que le pool hkps.pool.sks-keyservers.net) ;hkp-cacertpour le certificat racine des serveurs HKPS (là aussi, seulement utile si tu ne veux pas utiliser le pool par défaut) ;use-torpour accéder aux serveurs de clefs via Tor.Dirmngr a d’autres options dont l’utilité est plus rare, cf
man dirmngrpour une liste complète.À partir de la version 2.1.16, le cas le plus courant est en fait de ne même pas avoir besoin d’un fichier
dirmngr.conf, car les options par défaut devraient être satisfaisantes pour la plupart des utilisateurs.Toutes les autres options citées (notamment
--auto-key-locate) vont dansgpg.conf.[^] # Re: petite coquille
Posté par gouttegd . En réponse au journal De la distribution des clefs OpenPGP. Évalué à 3.
Euh, ça ce n’était pas une coquille, c’était l’expression voulue, dans le sens où « quiconque est capable de faire gpg2 --send-keys est capable de déposer une clef au nom de n’importe qui ».
Mais il y a hélas d’autres corrections à faire si un modérateur passe par là :
Section Le protocole HKP, 1er paragraphe : « il utilise le port TCP 11371 ou, dans sa version sécurisée par TLS (HKPS),
parle port HTTPS standard 443 »Section Les serveurs LDAP, 1er paragraphe : espace manquant entre les deux liens « plusieurs endroits »
Section Les enregistrements PKA, 4ème paragraphe : Les enregistrements PKAv1 ne sont plus supportés depuis GnuPG 2.1.3 (et non 2.1.13)
Section Le Web Key Directory, 3ème paragraphe : « La première étape est de demander le (ou les) enregistrement(s) SRV associé(s) a nom… »
[^] # Re: petites questions
Posté par gouttegd . En réponse au journal De la distribution des clefs OpenPGP. Évalué à 6.
Dans le cas d’un (petit) groupe de personnes qui se connaissent tous et qui se contactent directement (c’es-à-dire que A envoie lui-même le message à B, C, et D sans intermédiaire, B répond directement à A, C, et D sans intermédiaire, etc.), il n’y a rien de spécial à faire.
Chaque personne génère sa paire de clefs personnelle et s’arrange pour communiquer sa clef publique aux autres. Ensuite, à chaque envoi, le message sera chiffré avec la clef de chaque destinataire, et chaque destinataire le déchiffrera avec sa clef privée.
(En interne, ce qui se passe est que le message sera chiffré une seule fois avec une clef de session unique, et c’est la clef de session qui sera chiffrée plusieurs fois avec les clefs publiques des différents destinataires. Le message final de A à B, C, D ressemblera à ça :
les clefs de session chiffrées étant normalement petites comparées au message lui-même, cette méthode n’augmente pas significativement la taille du message final.)
[^] # Re: HTTP remplacent ?
Posté par gouttegd . En réponse au journal Debian va débrancher ses dépôts FTP. Évalué à 1.
« Qui diable de sérieux voudrait faire ça en premier lieu ? »
Une telle désynchronisation t’expose à pas mal de problèmes indépendamment des mises à jour de ton antivirus. Notamment, vis-à-vis des périodes de validité des certificats X.509 (et dans une moindre mesure les signatures DNSSEC, mais comme rares sont ceux qui signent leur zone et encore plus rares sont ceux qui vérifient les signatures, je reconnais que c’est moins gênant).