🚲 Tanguy Ortolo a écrit 12301 commentaires

C'est ça. Et le nommer mysqlnd pour « MySQL native driver », c'est donc débile.

Et la bibliothèque MySQL officielle aussi. Je maintiens : dans ce contexte (distinguer la bibliothèque MySQL officielle et la bibliothèque alternative), le terme « native » n'a aucun sens.

C'est bien ce que j'avais compris, et le terme « natif » n'a pas le moindre sens.

Ah, d'accord. Bon, alors le « native » n'as pas son sens intuitif (elle n'est pas plus native que la bibliothèque officielle), ni son sens inverse : il n'a tout simplement aucun sens. Parler de bibliothèque alternative serait plus pertinent.

Les extensions mysql, mysqli et pdo_mysql utilisent maintenant la bibliothèque native d'accès à MySQL mysqlnd, au lieu de la bibliothèque officielle de MySQL.

Comme ce n'était pas clair, je viens de regarder les dépendances des paquets Debian correspondants. Ma déduction : contrairement à ce qu'on pourrait penser, cette bibliothèque est « native » dans le sens où elle est rédigée en PHP, au contraire de la bibliothèque officielle de MySQL qui utilise la bibliothèque C.

Euh… Des lecteurs "ancien" ne savent pas lire la chose.

Non non non, pas des lecteurs anciens, juste des lecteurs merdiques. Un lecteur avec une prise en charge décente de MIME affichera normalement le corps du message, qui est présenté de façon tout à fait semblable à un message mixte texte/HTML.

Bof. Je ne connais pas de développeur Debian IRL. Encore moins 3.

Et ? Ça ne t'empêche pas de télécharger le trousseau de clef Debian et de le définir comme clefs de confiance.

Mais il n'y a pas de modèle avec une authorité de confiance un peu reconnue pour l'instant, donc c'est inutilisable pour moi.

Bah, tu n'as qu'à prendre le trousseau de clefs de l'ensemble des développeurs Debian par exemple, et t'imposer de ne faire confiance à une clef que si elle a été signée par trois d'entre eux : ils sont aussi dignes de confiance que les autorités de certification X.509, voire plus parce que ces autorités ont intérêt à mal faire leur travail.

Debian formant la plus grosse toile de confiance PGP de l'univers connu, ça te fait une autorité de certification sacrément puissante.

J'ai une bonne nouvelle à t'annoncer : les serveurs connus sont synchronisés entre eux. Tu trouveras exactement les mêmes clefs sur chacun d'entre eux, moyennant le temps de propagation.

Quitte à me répéter, dans la vraie vie il n'y a pas de connaissances communes.

Si. Tu as par exemple une connaissance commune entre toi et ta banque : VeriSign. Ou toute autre autorité de certification.

Mais comment faire cette vérification justement?

Par une ou plusieurs connaissances communes, considérées comme des autorités de certification.

Ce n'est pas pour rien qu'il y a des authorités de confiance en SSL, c'est pour éviter ce problème que ça a été créé.

Nawak : le modèle PGP est strictement supérieur à celui de X.509 (SSL). La seule différence entre un certificat PGP et un certificat X.509, c'est que le PGP peut être signé par plusieurs autorités alors que le X.509 peut être signé par une seule. Du coup :

• PGP permet d'implémenter un modèle pyramidal à la X.509 avec des autorités de certification, il suffit pour ça de se restreindre volontairement à une signature par certificat ;
• PGP permet aussi de faire mieux, en implémentant un modèle en toile de confiance.

Vous parlez bien de la même chose, les signatures PGP en ligne.

Attends, excuse-moi, il explique qu'il n'aime pas récupérer des clefs sur des serveurs publics. C'est son droit de se compliquer la vie, en attendant tu peux quand même les utiliser, toi. Ou te faire envoyer les clefs par courrier électronique, le médium importe peu du moment qu'on fait la vérification.

Oui, sauf que là, pas de chance, des solutions ils n'y en a pas, pour contourner les défauts de logiciels merdiques qui ne changeront jamais. Donc soit on ne fait rien, soit on se dit qu'on ne peut pas se permettre de laisser Microsoft se mettre en travers du progrès, et on avance.

Une façon de placer la signature en attachement, comme ça :

• multipart/signed (inline)
  • text/plain (inline) : le texte du message
  • application/pgp-signature : la signature

Pour un client ne prenant pas en charge PGP, ça apparaît au mieux comme un message normal, au pire comme un message avec un fichier attaché inutile. Pour un client pourri, c'est à dire un client Microsoft, ça apparaît comme un message vide avec un fichier attaché contenant le texte du message.

Pour le chiffrement, PGP/MIME ça ressemble à ça :

• multipart/encrypted (inline)
  • application/pgp-encrypted

Pour le chiffrement et la signature, une combinaison des deux, il me semble.

Si j'ai bien compris, PGP/MIME, c'est pratique pour le chiffrement. Pour la signature, quel intérêt d'envoyer un mail incompatible avec des lecteurs "normaux"

Rectification : incompatible avec les lecteurs anormaux, à savoir ceux de Microsoft. Tous les autres sont compatibles.

Tu as le droit de demander à tes amis de te fournir leurs clefs sur clef USB si ça t'amuse : les serveurs publics sont seulement là pour faciliter les échanges de clefs, mais il n'est pas obligatoire de les utiliser, si tu veux faire plus compliqué, tu peux.

C'est pareil avec PDF et le lecteur Adobe. Par exemple, je diffuse des photos par BitTorrent :

• Tanguy, tu fais chier, c'est compliqué d'installer un logiciel pour ça, tu ne pourrais pas les mettre sur un site Web normal ?
• Euh, dis-moi, juste pour savoir, tu peux lire des PDF ?
• Oui, pouquoi ?
• Avec quel logiciel ?
• Adobe Reader…
• Et il était fourni avec ton système ?
• Ah non, c'est un des premiers trucs que j'ai installé.
• Super, c'était compliqué d'installer un logiciel pour ça mais tu l'as bien fait au premier PDF que tu as eu à lire. Ben pareil pour mes photos.

Jamais entendu parler de PGP/MIME ?

Oups, moinssez-moi, je viens de dire une belle connerie. Pour signer, d'accord, mais pour chiffrer, on oublie. :-)

Si, ils pourraient. Les messages de contrôle des groupes de nouvelles USENET sont signés selon PGP dans un en-tête prévu à cet effet. C'est un processus semblable à celui utilisé pour DKIM.

garder de manière sécurisée le certificat de révocation de la clef

Celui-là, si tu te le fais voler, c'est très ennuyeux mais pas grave, comparé à ta clef privée. Le voleur peut révoquer ta clef, pas déchiffrer à ta place ou se faire passer pour toi.

Il y avait FireGPG pour faire cela dans Firefox. Malheureusement le projet a été abandonné. Il y a GPG4Browsers pour faire cela dans Google Chrome…

Comme dis dans un article, je me fous de savoir que Linus Torvalds est en fait Bill Gates, du moment que la personne avec qui je discute depuis le début est toujours la même.

Pas de chance, ce n'est pas encore équivalent à ça non plus. Tu peux te retrouver dans la situation où tu parles avec Bill Gates au lieu de Torvalds, ce qui semble bizarrement te convenir, mais avec en plus Richard Stallman qui lit toutes vos communications depuis le début.

Et accessoirement, si tu as commencé la conversation par un autre médium, la continuité n'est pas garantie non plus.

Ce sont des cartes à puce SSL. Et SSL, c'est basé sur X.509, et X.509, c'est mal parce que :

1. c'est un truc de téléphonistes ;
2. ça encourage les pires dérives (concentration sur un minimum d'acteurs de pouvoir qui ont intérêt à mal faire leur travail).