Sommaire
Après s’être sorti d’une mauvaise passe il y a quelques années grâce à une campagne de financement réussie et aux contributions de quelques grosses entreprises, GnuPG cherche aujourd’hui à pérenniser ses ressources et lance à cette fin une nouvelle campagne de financement où l’accent est mis sur la récurrence des dons et l’importance des donateurs individuels.
PGP, OpenPGP, GnuPG : petit rappel des faits
Au début des années 1990, Phil Zimmerman écrivit PGP (Pretty Good Privacy), un logiciel de chiffrement et signature de fichiers et de messages. C’était alors l’un des premiers, sinon le premier, logiciels mettant la cryptographie à la portée du grand public, ce qui ne fut pas sans valoir quelques ennuis à Phil Zimmerman de la part du gouvernement américain. Quelques années plus tard, afin de permettre le développement de logiciels compatibles avec PGP (tout les éditeurs de logiciels n’ont pas forcément l’obsession d’enfermer leurs utilisateurs), le format des messages manipulés par PGP fut décrit successivement dans les RFC 1991 puis 2440, où il fut alors appelé format OpenPGP.
PGP n’était pas un logiciel libre. Le code source était, à l’époque, diffusé avec chaque copie, mais sans les libertés traditionnellement associées aux logiciels libres (notamment, la liberté d’utilisation commerciale). Et certains algorithmes utilisés (notamment RSA) étaient encombrés de brevets. Richard Stallman, initiateur du projet GNU et fondateur de la FSF, reconnaissant l’intérêt d’un tel logiciel, exhorta alors la communauté des hackers à développer une implémentation libre du nouveau standard OpenPGP.
Détail important, cet appel était destiné aux développeurs non-américains et principalement européens, la législation de plusieurs pays du vieux continent étant globalement plus favorable à la cryptographie : un logiciel développé aux États-Unis par des hackers américains aurait pu se heurter à la législation américaine qui assimile les logiciels de cryptographie à des munitions de guerre — c’est ainsi que PGP fut initialement confiné aux USA, dont il ne put sortir que sous la forme d’un livre contenant son code source édité par le MIT, forme sous laquelle il était protégé par le premier amendement de la constitution américaine.
L’appel de rms fut entendu en septembre 1997 par un développeur allemand, Werner Koch, qui s’attela à la tâche et publia trois mois plus tard la version 0.0.0 de G10, The Free PGP Replacement.1 Le projet de Werner Koch fut par la suite renommé en GnuPG (GNU Privacy Guard),2 souvent abrégé en gpg qui est aussi le nom du binaire principal. La version 1.0.0 fut publiée en septembre 1999.
g10code GmbH
g10code GmbH est l’entreprise fondée par Werner Koch et son frère en 2001 pour fournir un cadre légal au développement de GnuPG. g10code propose du développement à la demande et du support autour de GnuPG. L’entreprise a notamment été mandatée par le ministère allemand des finances pour porter le logiciel sous Windows, et par le BSI (Bundesamt für Sicherheit in der Informationstechnik, l’équivalent allemand de l’ANSSI) pour implémenter la prise en charge de S/MIME, l’autre standard de chiffrement de messages « concurrent » d’OpenPGP — ce projet, nom de code Aegypten, a donné naissance à GnuPG 2.
À partir de la fin des années 2000, g10code va toutefois traverser une passe difficile. Le manque de contrats de développement et de support va conduire l’entreprise à se séparer de Marcus Brinkmann en 2012, Werner Koch restant alors le seul employé. En 2013, la situation devient critique au point que Werner Koch envisage de plus en plus de laisser tomber et de trouver un boulot de « développeur normal » (straight coder job).
Hasard de l’histoire, c’est à ce moment qu’un certain Edward Snowden, ancien contractant de la NSA, révèle au monde entier l’étendue des programmes de surveillance de masse des services de renseignement américains. L’affaire fait grand bruit, suscite un (relatif) regain d’intérêt pour les questions liées à la protection et à la violation de la vie privée, et surtout motive Werner Koch à ne pas abandonner le projet GnuPG.
Il faudra toutefois attendre le succès de la campagne de financement de début 2015, le support de la Core Infrastructure Initiative et de deux grosses entreprises (Facebook et Stripe) pour que la situation de g10code s’améliore.
L’envolée
Dès lors, GnuPG a connu un développement accéléré qui continue encore aujourd’hui.
Cela a commencé avec la sortie de la première version de la branche 2.1, en novembre 2014. Cette version a introduit, entre autres :
- une nouvelle architecture avec une séparation plus franche des responsabilités entre les différents composants (notamment, désormais seul ’agent GnuPG manipule directement les clefs secrètes) — la branche 2.0 avait déjà initié cette réorganisation mais sans aller jusqu’au bout ;
- un nouveau format de stockage des clefs publiques, plus efficace pour les trousseaux bien fournis ;
- la prise en charge des algorithmes basés sur les courbes elliptiques (RFC 6637).
C’est cette branche qui concentre depuis l’essentiel des développements (les branches 1.4 et 2.0 sont en maintenance) et accueille toutes les nouvelles fonctionnalités, parmi lesquelles :
- un nouveau modèle de confiance, le modèle Trust-on-first-use (TOFU) (dont votre serviteur a déjà parlé dans son journal sur les modèles de confiance) — une fonctionnalité majeure, susceptible de vraiment rendre GnuPG accessible au plus grand nombre en supprimant la nécessité de comprendre les arcanes de la toile de confiance (car, comme le disait Richard Feynman, « personne ne comprend la toile de confiance ») ;
- une nouvelle façon de publier les clefs dans le DNS, standardisée auprès de l’IETF — GnuPG permettait déjà ça depuis des années mais utilisait une méthode qui lui était propre (un sujet également couvert par votre serviteur dernièrement) — par ailleurs déjà mise en œuvre par certains fournisseurs de service de messagerie outre-Rhin ;
- une nouvelle façon de publier les clefs sur le web, le Web Key Directory ;
- la prise en charge de Tor pour la communication avec les serveurs de clefs ;
- un nouveau framework de tests unitaires assurant un meilleur contrôle qualité et une réduction des risques de régression ;
- beaucoup de travail sur les bindings Python de GPGME (GnuPG Made Easy, la bibliothèque permettant d’utiliser GnuPG depuis son code) ;
- (liste non-exhaustive).
Et maintenant, GnuPG a besoin de vous !
Après la campagne de financement de 2015 évoquée plus haut, les développeurs visent désormais la stabilité à long terme. L’objectif de la campagne 2017 est d’obtenir des promesses de dons récurrents garantissant à g10code au moins 15 000 euros par mois.
Cet argent permettra à g10code de continuer à employer trois développeurs à temps plein : Marcus Brinkmann (qui est de retour après son départ en 2012), Neal Walfied, et Justus Winter.
Pour en savoir plus, les anglophones peuvent consulter les vidéos à disposition sur le site de la campagne de financement. Les développeurs de GnuPG y expliquent leur travail, et des utilisateurs (activistes, journalistes, ONG, etc.) témoignent de l’importance de GnuPG pour leurs activités.
Rappelons par ailleurs, comme le fait Daniel Kahn Gillmor (mainteneur de GnuPG pour Debian), que la plupart des distributions GNU/Linux s’appuient sur GnuPG pour garantir l’intégrité de leurs paquetages et de leurs mises à jour.
-
Le nom « G10 » est une référence à la fois à l’article 10 de la constitution allemande (Grundgesetz, loi fondamentale), qui garantit que le secret des correspondances est inviolable, et à la loi sur les restrictions au secret des correspondances, elle-même surnommée « loi G-10 », qui autorise les services de renseignement allemands à ne pas considérer le secret des correspondances comme si inviolable que ça. ↩
-
Pour l’anecdote, rms a approuvé le nom GnuPG mais aurait préféré un nom plus drôle ou plus coquin. ↩
# 15.000€/mois pour 3 dev ?
Posté par Mimoza . Évalué à 3.
J'espère que cette somme n'est qu'un complément a d'autre ressources, car 15/3 = 5. 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 ?
[^] # Re: 15.000€/mois pour 3 dev ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
J'imagine que se contenter de 2.5k€/mois doit être leur contribution à la "cause".
"La première sécurité est la liberté"
[^] # Re: 15.000€/mois pour 3 dev ?
Posté par gouttegd (site web personnel) . É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: 15.000€/mois pour 3 dev ?
Posté par RyDroid . Évalué à 10.
Les individus ne sont heureusement pas poussés à agir que pour l'argent. 2500€/mois, c'est au dessus du salaire net médian (1800€) et du revenu moyen net (2250€) en France (j'ai arrondi au-dessus), même s'il faudrait bien sur comparer avec la différence sur ce qui est financé par le salaire indirect (les cotisations qui financent notamment la Sécurité Sociale). C'est probablement peu pour un informaticien ou une informaticienne niveau ingénieur/recherche dans ce pays, c'est néanmoins loin d'être petit quand on compare au reste de la population. Je tenais à faire ce petit rappel, j'ai bien noté les guillemets dans la phrase.
http://www.journaldunet.com/economie/magazine/1166094-salaire-moyen/
http://www.lefigaro.fr/economie/le-scan-eco/dessous-chiffres/2017/01/28/29006-20170128ARTFIG00096-les-francais-gagnent-en-moyenne-2225euros-nets.php
[^] # Re: 15.000€/mois pour 3 dev ?
Posté par Anonyme . Évalué à 3.
Merci pour ce commentaire.
C’est toujours bon de relativisé un peu. Pas pour atténuer nos critiques, mais plutôt pour bien comprendre qu’on est pas dans la norme quand on fait un métier où le plein emplois est la règle.
[^] # Re: 15.000€/mois pour 3 dev ?
Posté par Maclag . Évalué à 5.
Ahum! C'est GnuPG, c'est pour une bonne cause alors on peut payer sous le marché?
Si demain matin je poste une annonce ici pour recruter un dév expérimenté à 2500€ brut par mois mais sur du Libre, je ne vais pas me faire incendier?
L'argument "tout le monde ne travaille pas pour l'argent", c'est celui utilisé par les recruteurs peu scrupuleux pour justifier qu'ils paient leurs employés au lance-pierre!
Enfin, si ces dévs sont contents avec ça, tant mieux pour eux!
[^] # Re: 15.000€/mois pour 3 dev ?
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 08 juin 2017 à 16:49.
On peut parler sérieusement et pas troller?
Ca parle de "brut chargé" de 5000€/mois (15 divisé par 3). le brut allemand serait de environ 4000€/mois, l'équivalent brut français est dans les 3500€/mois (donc net avant IR de 2500 €/mois).
Personne à part les trolleurs ne parle de 2500€ brut par mois.
Le sujet m’intéresse, mais si les gens partent dans des nombres farfellus, c'est du troll inutile.
[^] # Re: 15.000€/mois pour 3 dev ?
Posté par Zenitram (site web personnel) . Évalué à 0.
Question idiote : à quoi peut vous servir de connaitre le salaire brut?
Perso, je ne vois pas, car il ne correspond ni à l'enveloppe totale, ni à ce que le personne reçoit au final.
Troll, à ce niveau pour arriver au brut par rapport au brut chargé (le total), c'est 30% en moins.
50%, c'est en moyenne du brut chargé (le total) au net net (net après IR), que ce soit en France ou en Allemagne.
(après, "petit" est tout relatif, c'est petit pour un mec trouvant plus haut et pouvant se la péter en disant ça, c'est grand pour une personne au chômage cherchant un taf plutôt que se complaire à se plaindre de ne pas trouver de taf alors qu'il peut en avoir; et c'est sans doute pour eux ce qu'ils peuvent espérer avoir ou arrêter, tout est un juste milieu entre ce qu'on peut demander et ce qu'on peut avoir, si vous voulez qu'ils soient payés plus vous n'avez qu'à filer plus de sous)
[^] # Re: 15.000€/mois pour 3 dev ?
Posté par Sufflope (site web personnel) . Évalué à 4.
Moui enfin faut pas exagérer non plus, quand tu mets sur ton CV "oh je suis juste le développeur de gnupg" je pense que t'es assez à l'abri du chômage de masse.
[^] # Re: 15.000€/mois pour 3 dev ?
Posté par Kerro . Évalué à 4.
Pas gagné, franchement.
Un recruteur qui n'y connais rien peut l'écarter en se disant que c'est vraiment un barbu/geek/associal car il fait un truc pour « crypter » les messages des pédo-terro-nazi-machins. Il va aller sur la page du projet et voir que ce n'est pas sexy du tout, mais alors vraiment pas du tout. Et qu'en plus ça ne marche pas commercialement vu qu'ils demandent du pognon. Avec un peu de bol il tombera sur un truc en rapport avec Stallman et là c'est plié direct.
Si c'est un recruteur qui s'y connais, il va se poser deux questions :
- ce développeur va bosser pour ma boîte ET va continuer à développer son logiciel favori pendant des heures par semaine. Puis-je compter sur le fait qu'il soit intellectuellement en état pour faire le job qui lui sera demandé dans l'entreprise ? Car la double semaine, peu de gens peuvent la supporter
- ce développeur est probablement habitué à être très libre, et à produire du très bon code. Est-il en mesure de travailler avec des contraintes qui lui semblent arbitraires, des délais trop courts, et de livrer des produits pas fiables comme le font 99 % des entreprises de notre domaine ? Et aussi de reprendre du code dégueux pour corriger quelques problèmes sans pour autant tout réécrire ?
[^] # Re: 15.000€/mois pour 3 dev ?
Posté par Renault (site web personnel) . Évalué à 2.
Dans toutes les bonnes boîtes que j'ai croisé, les commerciaux / RH revoyaient les CV avec un gars compétent techniquement dans l'entreprise. Et j'ose croire qu'un gars technique sait ce qu'est le chiffrement voire GnuPG directement.
[^] # Re: 15.000€/mois pour 3 dev ?
Posté par Kerro . Évalué à 2.
Donc on passe à la seconde possibilité : ce n'est toujours pas gagné.
Ils auraient fait quoi avec une telle candidature dans ces « bonnes » boîtes ? Je n'en connais pas, donc je ne suis pas habitué à leurs fonctionnement dans ce domaine.
[^] # Re: 15.000€/mois pour 3 dev ?
Posté par Alex G. . Évalué à 1.
Et ben je sais pas de quel monde tu viens mais c'est pas brillant. Moi je connais des tas de boite qui évaluerons son aptitude relationnelle sur la base d'un entretien et celle technique en regardant son code / ses contributions / ses expériences passées.
# Promouvoir en dépêche !
Posté par Alex G. . Évalué à 1.
Hello, l'importance du sujet, la qualité de ta rédaction font que ce journal devrait être une dépêche à mes yeux.
Pourquoi as tu choisis le format journal ?
[^] # Re: Promouvoir en dépêche !
Posté par gouttegd (site web personnel) . É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.)
# Et l'ergonomie de gpg, on en parle ?
Posté par showtime . Évalué à -4.
Je n'ai rien lu jusqu'ici qui parle de l'ergonomie de gpg, vraiment très mauvaise.
http://docplayer.net/10300209-Why-johnny-can-t-encrypt-a-usability-study-of-pgp.html
https://www.schneier.com/blog/archives/2015/11/testing_the_usa.html
https://arxiv.org/pdf/1510.08555.pdf
Donc en effet, GnuPG a besoin de vous, encore faudrait-il que GnuPG vous écoute.
Et vous, que pensez-vous de l'ergonomie de GPG ?
Quelles pistes d'amélioration proposez-vous ?
[^] # Re: Et l'ergonomie de gpg, on en parle ?
Posté par gouttegd (site web personnel) . É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: Et l'ergonomie de gpg, on en parle ?
Posté par showtime . Évalué à -2.
En parlant de raisonnements logiques foirés:
Première formulation:
Deuxième formulation:
Il est par contre extrêmement simple de démontrer que l'affirmation "les clients PGP modernes sont inutilisables" est fausse, c'est soit de citer une étude de l'ergonomie d'un client qui a eu de très bon scores, soit donner le nom d'un client PGP ergonomique qui fasse à peu près consensus, et c'est là que la communauté de linuxfr.org avec toutes ses connaissances et ses experts sur le sujet devrait être en mesure d'apporter des éléments constructifs. Voilà, j'attends…
En effet, c'est du très très lourd:
JDCJDR: peut-être d'ailleurs que ce n'est pas uniquement aux développeurs de concevoir l'interface d'un outil, particulièrement critique, qui est destiné à une communauté bien plus large et bien moins experte dans le domaine…
PS: J'avais déjà lu tes 2 derniers articles de-la-distribution-des-clefs-openpgp et de-la-confiance-dans-le-monde-openpgp que j'ai trouvé très instructifs et bien rédigés.
[^] # Re: Et l'ergonomie de gpg, on en parle ?
Posté par gouttegd (site web personnel) . É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 Moonz . Évalué à 5.
Le combo TOFU + DANE/OpenPGP Web Key Service, ça a un excellent potentiel effectivement, et je suis très heureux de voir que ça bouge dans cette direction.
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. Je n’ai que suivi de très très (très) loin, mais pour ce que je peux en dire, la culture de « WoT sinon rien » qui a longtemps prévalu en est grandement responsable.
[^] # Re: Et l'ergonomie de gpg, on en parle ?
Posté par gouttegd (site web personnel) . É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 Maclag . Évalué à 3.
Effectivement, beurk!
Oui mais y'a pas que l'email et Signal dans la vie. XMPP, par exemple, permet aussi de gérer des messages riches hors-ligne, et le chiffrement y est déjà mieux intégré. On pourrait imaginer un client adapté à cet usage, ou mieux: des modules pour les clients mail existants!
Peut-être que le remplacement de l'email est la bonne voie, mais que l'alternative proposée est à revoir.
Si c'est pour rester sur l'email, il faut que tous les acteurs se mettent d'accord sur une procédure standard et automatisée, puis l'implémentent et en forcent l'utilisation.
[^] # Re: Et l'ergonomie de gpg, on en parle ?
Posté par claudex . Évalué à 4.
Il y a pas une fonctionnalité de SMTP qui soit implémentée par tout le monde (aller, les différentes parties avec mime peut-être, mais je ne mettrais pas ma main à couper). Le monde du mail, c'est une grosse pile de workaround. Tu forward un mail, avec outlook, tu as winmail.dat, avec thunderberbird, tu as message/rfc822. L'encode 8bits, ça varie, le \n au lieu \r\n, pareil. Accepter un From: différent du mail from, pareil chaque serveur a sa conf…
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et l'ergonomie de gpg, on en parle ?
Posté par Maclag . Évalué à 2. Dernière modification le 10 juin 2017 à 16:56.
Alors autant arrêter d'entretenir ce bordel et passer une fois pour toutes à autre chose!
[^] # Re: Et l'ergonomie de gpg, on en parle ?
Posté par claudex . Évalué à 5.
Bien sûr, mais actuellement, je ne vois rien de mieux. Notamment, sur le fait de pouvoir communiquer avec quelqu'un sans que le receveur ait valider préalablement l'émetteur, ce qui est rédhibitoire quand on veut parler avec des gens qu'on ne connait pas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et l'ergonomie de gpg, on en parle ?
Posté par Renault (site web personnel) . Évalué à 2.
Personnellement, plus que de changer la philosophie du courriel, réorganiser les standards pour nettoyer tout cela en tenant compte des progrés opérés depuis.
Un peu comme le Web, fondamentalement le fonctionnement du Web n'a pas grandement évolué. Mais les langages et protocoles ont subi de gros changements : HTTP2, HTML5, JavaScript… On pourrait faire un SMPT2 + IMAP2 + autres qui permettent de bénéficier des éléments plus modernes de manière plus intégrée (et obligatoire aussi).
[^] # Re: Et l'ergonomie de gpg, on en parle ?
Posté par claudex . Évalué à 3.
IMAP2, c'est "facile". Il suffit d'écrire le protocole, de coder un client et un serveur et c'est bon. Pour SMTP2, c'est beaucoup plus compliqué, il faut mettre suffisamment de monde d'accord, dont une partie qui fait énormément de trafic mail (Google, Microsoft), n'ont pas trop intérêt à ce que ça deviennent plus performant que leur solutions de communications.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et l'ergonomie de gpg, on en parle ?
Posté par Renault (site web personnel) . Évalué à -1.
Après je ne sais pas s'il faut distinguer SMPT et IMAP comme on le fait aujourd'hui. Cette distinction entre les deux peut expliquer une partie des difficultés actuelles de faire évoluer le courriel comme une solution de communication plus moderne.
[^] # Re: Et l'ergonomie de gpg, on en parle ?
Posté par claudex . Évalué à 6.
Je ne vois pas pourquoi. SMTP, c'est de la communication interserveur (à part la partie client-serveur pour envoyer le message, mais ce n'est clairement pas là qu'est le problème). IMAP, c'est de la partie client-serveur avec gestion de dossier, de flag (lu, important…), de template (même si c'est un contournement). Je ne vois pas du tout ce qu'apporterait une fusion des deux, à part une rigidité plus grande vu qu'on devrait les faire évoluer ensemble.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et l'ergonomie de gpg, on en parle ?
Posté par Anonyme . Évalué à 3.
Le problème c’est qu’une nouvelle RFC ne fera que déprécier une ancienne, mais elle ne pourra pas imposer l’usage du nouveau standard.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.