Stéphane Bortzmeyer a écrit 645 commentaires

Et comment on traduit "flow", très utilisé dans le RFC ?

Flux désigne autre chose. « À l'intérieur d'un ruisseau circule un flux ordonné d'octets. » Le gros problème de flot ou flux, c'est qu'ils sont utilisés pour des tas de choses différentes en réseau.

Oui, QUIC et HTTP/3 empruntent pas mal d'idées à HTTP/2, notamment celles des ruisseaux parallèles à l'intérieur d'une même connexion. Et le champ lexical de la vitesse n'a sans doute pas été choisi par hasard :-)

Attention, le lien pointe vers une vieille version du brouillon de norme. La vraie norme est le RFC 9000.

En effet QUIC chiffre (et ne crypte pas) en partie pour éviter que les intermédiaires ne se permettent de regarder et de se croire capable d'intervenir. C'est mentionné dans la dépêche (paragraphe sur la neutralité du réseau).

La grosse différence avec IPv6 est que la couche 3 affecte tous les routeurs sur le trajet alors que la couche 4 est de bout en bout. Il suffit que client et serveur le fassent.

Il est certain que le chiffrement ajoute de la complexité (dans le contexte des TP, utiliser Wireshark devient plus compliqué, il faut demander une écriture des clés dans un fichier, qu'on fera relire par Wireshark pour qu'il déchiffre le contenu). Mais c'est inévitable de nos jours, les connexions en clair sont vraiment trop vulnérables.
Philosophons un peu : c'est le sort de toutes les techniques. Au début du 20e siècle, un bricoleur pouvait construire un avion acceptable en assemblant un moteur, des ailes et hop. Aujourd'hui, ce n'est pas envisageable, et les TP pour les étudiants sont donc bien plus difficiles. Même l'ultra-simple Gemini impose TLS :-)
Et, oui, HTTP/3 ne fonctionne que sur QUIC, dont il utilise toutes les fonctions (vrai parallélisme, QPACK).
Si le répartiteur de charge termine TLS, pas de problème, il peut relayer comme il veut derrière (nouvelle session QUIC, HTTP/1 ou 2). Sinon, il peut utiliser le Connection ID de QUIC, qui est en clair, pour envoyer tous les paquets d'une même connexion au même dorsal. (Petit piège toutefois car le Connection ID n'est pas forcément constant.)

Pour les serveurs, ça se fera au fur et à mesure. Il y a de très nombreuses mises en œuvre qualité production, il reste à en faire de belles bibliothèques facilement disponibles sur le système d'exploitation de votre choix, puis à intégrer cela dans les logiciels serveurs (si on a déjà du HTTP/2, ce n'est pas trop difficile).
Pour les pare-feux àlakon, oui, c'est une plaie classique de l'Internet (et une des raisons pour lesquelles on fait tout tourner sur HTTP).

J'ai honte, mais je ne sais pas recadrer un PDF sur Ubuntu.

Importer le fichier ne semble pas marcher. "
Erreur
Aucun code QR ou 2D-DOC détecté dans le document. Essayez de recadrer le document pour que le code apparaisse clairement et dans une taille raisonnable."

Clairement un complot de Beijing.

l’application tousQontReleterrorisme © sera disponible pour tous les téléphones Android et iOS

En plus, je suis sûr que ça va être comme TousAntiCovid, ça ne marchera pas sur mon Fairphone 1 avec ma copie patchée de /e/ flashée à la main la nuit. Tout ça parce que Cédric O n'est même pas programmeur !

Le client en question est sans doute Lagrange.

quand tu dis que ces domaines sont illégaux, tu parles bien juste de ces règles de syntaxe pour ce domaine spécifique de premier niveau (.kz)

Non, pas du tout, je parlais des règles techniques internationales, qui s'imposent à tout acteur (mais comme il n'y a pas de police de l'Internet, certains font ce qu'ils veulent).

parce que techniquement avec les Internationalized Domain Name, un registry pourrait décider d'accepter les émoticones

Certains registres le font, mais c'est une violation de la norme technique (RFC 5892), qui limite les noms (en gros) aux lettres et aux chiffres.

je ne vois pas trop de raisons pour interdire cela au niveau des normes

Les émojis ne sont pas explicitement interdits, c'est juste que la norme est conservatrice, n'autorisant que ce qui est explicitement permis. Les émojis n'étant pas autorisés sont donc interdits.

Il y a bien les problèmes de ne pas mélanger les scripts pour un nom de domaine donné (et ainsi éviter les attaques homographes)

Ces attaques sont un argument largement pipeau.

Il aurait fait un système entièrement à lui (un nouveau réseau social centralisé, par exemple), OK. Ces adresses auraient alors peut-être été inutiles mais sans être une escroquerie. Mais, là, il les présente comme des adresses de courrier électronique, ce qu'elles ne sont pas, puisque je ne peux pas y écrire depuis ma machine Debian avec son Postfix.

Mailoji est une pure escroquerie car les adresses de courrier achetées par les pigeons ne marchent que dans un environnement fermé et contrôlé par le vendeur. En effet, ces noms avec des émojis sont techniquement illégaux (il vont donc être refusés par plusieurs logiciels) et, quoiqu'il existe des normes pour cela depuis des années, très peu de serveurs de courrier acceptent les adresses de courrier en Unicode.

Bref, autant acheter des NFT, au moins il y a « blockchain » dedans.

« sans reverser une seule ligne de code upstream » Rappelons quand même qu'il y a plein de façons de contribuer au logiciel libre ; envoyer du code, bien sûr, mais aussi envoyer du fric, écrire de la documentation, faire des bons rapports de bogue, embrasser des chatons, etc.

(À ma connaissance, AWS est très mal placée sur tous ces points.)

les terminaux pèsent très lourds dans cette aventure comparée aux serveurs.

Source ? C'est justement un des gros problème des discussions « informatique et climat ». On a peu de données fiables sur lesquelles s'appuyer. (Au moins pour les ordiphones, je pense que leur consommation est pas mal optimisée car la durée de fonctionnement entre deux recharges est un critère important.)

Le prochain million était sans doute le next Billion dans la version originale, sinon ce n'était pas très ambitieux…

L'un des buts importants de Gemini est la simplicité, notamment pour permettre le développement de clients légers. Donc, non, pas de passage par HTML, qui irait directement contre ce but. Le format étant très simple, il n'y a pas non plus besoin de partager le moteur de rendu (sur le Web, il n'y a quasiment plus que deux moteurs de rendu, depuis que Microsoft a renoncé au sien, ce qui aggrave la concentration).

Pour Lagrange, l'analyseur et moteur de rendu est dans src/gmdocument.c. 1147 lignes de C dont beaucoup triviales.

Lagrange gère bien les autres protocoles… en envoyant l'URL au navigateur Web (ce qui est certainement le choix le plus raisonnable).

Ah, ce journal m'a touché car c'est pareil ici, je n'installe plus de trucs rigolos, je ne configure plus tout en détail et je ne recompile pas mes propres noyaux.

Par contre, mon courrier est toujours auto-hébergé. À part quelques universités et quelques libristes qui configurent n'importe comment leur Postfix, la grande majorité des serveurs de messagerie de la planète acceptent mes messages (même Outlook.com !) Il est vrai que je n'héberge pas de listes de diffusion, ça aide.

Et je connais l'équivalent de 'tail -f /var/log/messages' : 'journactl -n -f' :-)

Question autres projets, je travaille sur Gemini https://linuxfr.org/tags/gemini/public

Beaucoup de listes noires sont privées et ne peuvent pas être interrogées de l'extérieur.

Un outil que j'aime bien, ce sont les auto-répondeurs, pour vérifier à quoi ses messages ressemblent, vus de l'extérieur. https://www.bortzmeyer.org/repondeurs-courrier-test.html

Et vous avez réussi à installer GNUnet et à le faire fonctionner ? (Pas moi.)

« pendant 10 ans » Non, pas de mon expérience. Par exemple, pour un serveur Internet, n'avoir que les vieilles versions de TLS n'est pas acceptable, les clients, notamment les navigateurs ne les acceptant plus. Et c'est pourtant ce qui arrive si on reste sur de vieilles RHEL.