🚲 Tanguy Ortolo a écrit 12509 commentaires

Tu confonds avec awesome, je crois.

03:14:07 UTC 2038-01-19

Drôle de format, l'heure d'abord, puis la date… Ce serait plus compréhensible comme ça : 2038-01-19 03:14:07 UTC

Bah, en même temps, pas la peine de s'inquiéter, il y en aura pour tous les goûts : systemd pour ceux qui aiment, SysV init ou BSD init pour les autres. systemd ne signera pas l'arrêt de mort de ses prédécesseurs, qui continueront à être maintenus pour les besoins des BSD et de Debian.

Mais en attendant, quand quelqu'un me demande de m'inscrire sur Facebook, je réponds quoi ?

Que tu ne veux pas mais que lui peut très bien s'inscrire sur $whatever à la place. Comme ça tu retournes la situation, ce qui permet de lui montrer que ce qu'il te demande n'est pas anodin, pas plus que ce que tu lui demandes à la place.

Et comme déjà dit, tout le monde ne connait pas de dev' Debian : je fais comment moi pour la faire signer?

http://wiki.debian.org/Keysigning/Offers

Il y a plus de développeurs Debian, et dans plus d'endroits différents, qu'il n'y a d'autorités de certification SSL, je pense.

Tu as beau le répéter, ça n'en fait pas une solution : ta solution ne résout aucun problème de savoir comment deux personnes sur terre peuvent être sûrs qu'ils se parlent sans devoir faire 36 bidouilles.

En même temps, SSL ne résout pas non plus ce problème. Les autorités de certification signent n'importe quoi à condition de fournir de l'argent et un vague papier ressemblant vaguement à un truc officiel comme un relevé de compte en banque. Ce n'est pas étonnant, puisque leur intérêt financier est de mal faire leur travail de vérification.

Donc on est en train de comparer :

• SSL, un système où il est facile de se faire certifier, mais qui ne garantit absolument rien ;
• GPG, un système où se faire certifier nécessite une véritable vérification, ce qui est forcément plus compliqué, et qui garantit vraiment l'identité.

Merci, c'est précisément le genre d'explication que je cherchais. Tout s'éclaire.

Fail : il n'y a pas de pair de confiance "commun". Avec X509, si. C'est payant, oui, mais la fonctionnalité existe, j'ai un pair de confiance commun avec ceux à qui je veux parler. Pas avec PGP où c'est à toi de te démerder pour le trouver le pair.

Comme je l'ai déjà dit : téléchargez le trousseau de clefs de l'ensemble des développeurs Debian et utilisez-le comme pairs de confiance. Ils sont d'une façon générale plus fiables que les autorités de certification X.509 de toute façon.

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.