raphj a écrit 1787 commentaires

Ouais, ok, je vais essayer de faire ça ! Merci pour la suggestion. Et ça « règlera » le bug.

Je ne vois pas comment indiquer efficacement les corrections à apporter au commentaire sans devoir reposter entièrement le bon contenu de toute façon. L'espace de rédaction ne permet que d'envoyer des petits messages sur une ligne, ce n'est pas adapté.

J'ai un palliatif en place, à base de cron qui lance des requêtes régulièrement, mais ce n'est pas totalement fiable :

• Dès qu'on redémarre manuellement nginx après un changement de config, c'est niqué. Peut-être qu'on peut déclencher des actions avec systemd après le redémarrage d'un service. À creuser ! Ou pas, si ça disparait bientôt…

• Pour faire proprement, il faudrait certainement garder trace de l'expiration de l'agrafe et faire la requête au bon moment juste après l'expiration et espérer qu'aucune requête ne s'est glissée entre temps. Le problème, c'est que l'agrafe n'est mise à jour que quand elle est expirée, donc tu as beau faire des requêtes souvent, ça va quand même échouer entre l'expiration et la prochaine requête… si elle arrive assez tôt.

• l'alternative imparfaite, c'est de bourriner et lancer des requêtes vraiment très souvent à intervalle très court et quand-même espérer que des requêtes n'arrivent pas au bon moment.

Concernant le bug nginx, si j'ai bien compris, les dev nginx considèrent que la perf est plus importante et que cette requête à faire avant de répondre, c'est pénible, et apparemment ça demande une réarchitecture majeur, ou en tout cas beaucoup de boulot, donc c'est pas sûr qu'on voit le bug corrigé de sitôt. Ça fait déjà des années que les gens se plaignent.

Peut-être que quelqu'un pourrait fournir un patch, mais il faudrait déjà que les devs d'nginx soient convaincus que c'est une bonne idée.

Et au final, si ça disparait bientôt au profit d'une « meilleure » solution, peut-être autant pas trop s'embêter…

Gros bug d'édition, j'ai dupliqué des paragraphes… si l'équipe de modération veut bien corriger ça ce serait le top. Désolé pour le loupé.

Ah, c'est ballot 😅

D'abord, un petit résumé (edit: wou pinaise, pas si petit, déso) pour celles et ceux qui ne seraient pas familier avec le concept dont il est question, perso je n'en aurais jamais entendu parlé si je n'administrais pas moi même des site web donc je pense que ça peut être utile.

Pour sécuriser les connexions avec HTTPS, il faut un certificat qui dit "c'est bon, ce site web est bien servi par serveur vérifié, et la page n'a pas été modifié". Ce certificat est délivré par une autorité dont le navigateur (ou plus généralement le client HTTPS) fait confiance, et Let's Encrypt est l'une d'elle. C'est même la plus grosse aujourd'hui en termes de sites couverts.

Mais les certificats peuvent être révoqués, par exemple parce qu'ils ont été compromis. OCSP permet de vérifier qu'un certificat n'a pas été révoqué. Pour cela, le navigateur peut aller interroger une URL au moment de la première visite d'un site web depuis un certain temps pour aller voir si c'est le cas.

Problèmes :

• Ça demande une infrastructure coûteuse chez l'autorité de confiance, qui doit répondre à beaucoup de requêtes et doit avoir un uptime en béton.
  • que se passe-t-il si cette infra tombe ? On laisse passer ou on casse le site ?
• ça pose des questions de vie privée : l'autorité de confiance sait alors que telle personne a visité tel site. Elle n'a pas besoin de garder de logs (et Let's Encrypt s'efforce de ne pas garder les traces), mais elle est toujours susceptible d'être interrogée par des services de renseignements, et toutes les autorités ne sont pas aussi tatillonnes sur la protection de la vie privée, et même, on ne devrait pas avoir besoin de faire confiance à une autorité pour ça.

C'est pour ces raisons que Let's Encrypt veut se débarrasser d'OCSP.

En plus :

• ça ralentit cette première visite
• En pratique, parmi les navigateurs répandus, seul Firefox fait cette vérification

Il y a des parades :

• l'option Must Staple lors de la demande d'un certificat, qui bloque ce mécanisme de demande à l'infrastructure OCSP au niveau du navigateur. Le serveur web doit alors lui faire la requête, et fournir "l'agrafe" - la preuve que le certificat n'a pas D’abord, un petit résumé pour celles et ceux qui ne seraient pas familiers avec le concept dont il est question, perso je n’en aurais probablement jamais entendu parler si je n’administrais pas moi-même des sites web, donc je pense que ça peut être utile.

Pour sécuriser les connexions avec HTTPS, il faut un certificat qui dit « c’est bon, ce site web est bien servi par serveur vérifié, et la page n’a pas été modifié ». Ce certificat est délivré par une autorité en laquelle le navigateur (ou plus généralement le client HTTPS) fait confiance, et Let's Encrypt est l’une d’elles. C’est même la plus grosse aujourd’hui en termes de sites couverts.

Mais les certificats peuvent être révoqués, par exemple parce qu’ils ont été compromis. OCSP permet de vérifier qu’un certificat n’a pas été révoqué. Pour cela, le navigateur peut aller interroger une URL au moment de la première visite d’un site web depuis un certain temps pour aller voir si c’est le cas.

Problèmes :

• Ça demande une infrastructure coûteuse chez l’autorité de confiance, qui doit répondre à beaucoup de requêtes et doit avoir un uptime en béton.
  • Eh oui, que se passe-t-il si cette infra tombe / que des requêtes OCSP échouent ? On laisse passer ou on casse le site avec un avertissement inquiétant ou obscure à l’utilisateur ?
• ça pose des questions de vie privée : l’autorité de confiance sait alors que telle personne a visité tel site. Elle n’a pas besoin de garder de logs (et Let's Encrypt s’efforce de ne pas garder les traces), mais elle est toujours susceptible d’être interrogée par des services de renseignements, et toutes les autorités ne sont pas aussi tatillonnes sur la protection de la vie privée, et même, on ne devrait pas avoir besoin de faire confiance à une autorité pour ça.

C’est pour ces raisons que Let's Encrypt veut se débarrasser d’OCSP.

En plus :

• ça ralentit cette première visite, puisqu’il faut attendre que cette requête OCSP termine avant d'afficher le site
• En pratique, parmi les navigateurs répandus, seul Firefox fait cette vérification

Il y a des parades :

• l’option Must Staple lors de la demande d’un certificat, qui bloque ce mécanisme de demande à l’infrastructure OCSP au niveau du navigateur. Le serveur web doit alors lui faire la requête, et fournir « l’agrafe » - la preuve que le certificat n’a pas été révoqué très récemment - au navigateur.
  • en pratique, les serveurs répandus n’implémentent pas bien ce mécanisme. Notamment, Nginx ne fait la demande OCSP qu’après la première requête vers un site après son démarrage (ou après l’expiration des données OCSP), et cette requête part alors sans l’agrafe, ce qui fait échouer la vérification. Apache 2 n’est pas meilleur.
• CRL et CRLite, un mécanisme proposé par Mozilla où les navigateurs téléchargent la liste des certificats révoqués à intervalle régulier (4 fois par jour par exemple), avec des techniques de compression et de mises à jour incrémentales de fou pour que ça soit réalisable. Plus besoin alors d’OCSP si le navigateur sait déjà quel certificat est révoqué. Mais ce n’est pas encore en place.
• un temps de renouvellement très court des certificats. Si ton certificat a une durée de validité de 7 jours ou moins, finalement il y a beaucoup moins besoin de le révoquer. Mais ce n’est pas encore très répandu.

Actuellement, la situation n’est pas très rose :

• SSL Labs, qui fournit un diagnostic pour évaluer la qualité de la sécurisation de son site pousse à mettre en place Must Staple pour avoir un score parfait
• En théorie, c’est une bonne chose, parce que ça respecte mieux la vie privée des utilisateurs et c’est mieux au niveau des performances et de l’utilisation des ressources communes (chaque client n’a pas à faire sa requête OCSP, le serveur le fait pour tout le monde)
• En pratique, c’est tout moisi parce que ça ne marche pas bien : sa prise en charge par les serveurs est affreuse, les navigateurs sauf Firefox s’en tapent…

L’article dit que les gens qui hébergent des sites web ne sont pas concernés par ce changement, mais ce n’est pas tout à fait vrai : on ne sait pas encore comment cette option « Must Staple » sera gérée, et les solutions envisagées ont des inconvénients :

1. l’option pourrait être simplement ignorée. Le certificat sera créé, ça va continuer à marcher, juste qu’il n’y aura plus Must Staple ». Ça veut dire que si le système dépendait de ce mécanisme, ça va casser, et ça peut casser silencieusement. Mais au moins, la livraison des certificats va continuer à fonctionner sans changement partout où ça n’importe pas tellement.
2. l’option pourrait causer un échec de certificat. Dans ce cas, ce sera clair ce qu’il se passe, par contre ça va obliger plein de gens à déboguer et mettre à jour une configuration qui vivait toute seule depuis potentiellement longtemps.

De mon côté, je ne sais pas ce que je préférerais. Peut-être que les navigateurs adoptent un truc comme CRL, ou que les certificats aient encore une durée de validité plus courte, pour rendre OCSP et Must-Staple inutiles.

Ce qui est sûr, c’est que ça résoudra mes problèmes de gestion cassée de Must-Staple par Nginx sans devoir me poser la question de si je dois désactiver ça. Peut-être que SSL Labs mettra aussi à jour son diagnostic pour arrêter de pousser cette option. Au moins, si elle ne fonctionne plus, la question ne se pose plus. Donc je suis un peu pressé que ça arrive.
été révoqué très récemment - au navigateur.
- en pratique, les serveurs répandus n'implémentent pas bien ce mécanisme. Notamment, Nginx ne fait la demande OCSP qu'après la première requête vers un site après son démarrage (ou après l'expiration des données OCSP), et cette requête part alors sans l'agrafe, ce qui fait échouer la vérification. Apache 2 n'est pas meilleur.
- CRL et CRLite, un mécanisme proposé par Mozilla où les navigateurs téléchargent la liste des certificats révoqué à intervalle régulier (4 fois par jour par exemple), avec des techniques de compression et de mises à jour incrémentales de fou pour que ça soit réalisable. Plus besoin alors d'OCSP si le navigateur sait déjà quel certificat est révoqué. Mais ce n'est pas encore en place.
- un temps de renouvellement très court des certificats. Si ton certificat a une durée de validité de 7 jours ou moins, finalement il y a beaucoup moins besoin de le révoquer. Mais ce n'est pas encore très répandu.

Actuellement, la situation n'est pas très rose :

• SSL Labs, qui fournit un diagnostic pour évaluer la qualité de la sécurisation de son site pousse à mettre en place Must Staple pour avoir un score parfait
• En théorie, c'est une bonne chose, parce que ça respecte mieux la vie privée des utilisateurs et c'est mieux au niveau des performances et de l'utilisation des ressources communes (chaque client n'a pas à faire sa requête OCSP, le serveur le fait pour tout le monde)
• En pratique, c'est tout moisi parce que ça ne marche pas bien : sa prise en charge par les serveurs est affreuse, les navigateurs sauf Firefox s'en tapent…

L'article dit que les gens qui hébergent des sites web ne sont pas concernés par ce changement, mais ce n'est pas tout à fait vrai : on ne sait pas encore comment cette option "Must Staple" sera gérée, et les solutions envisagées ont des inconvénients :

1. l'option pourrait être simplement ignorée. Le certificat sera créé, ça va continuer à marcher, juste qu'il n'y aura plus Must Staple". Ça veut dire que si le système dépendait de ce mécanisme, ça va casser, et ça peut casser silencieusement. Mais au moins, la livraison des certificats va continuer à fonctionner sans changement partout où ça n'importe pas tellement.
2. l'option pourrait causer un échec de certificat. Dans ce cas, ce sera clair ce qu'il se passe, par contre ça va obliger plein de gens à déboguer et mettre à jour une configuration qui vivait toute seule depuis potentiellement longtemps.

De mon côté, je ne sais pas ce que je préférerais. Peut-être que les navigateurs adoptent un truc comme CRL, ou que les certificats aient encore une durée de validité plus courte, pour rendre OCSP et Must-Staple inutiles.

Ce qui est sûr, c'est que ça résoudra mes problèmes de gestion cassée de Must-Staple par Nginx sans devoir me poser la question de si je dois désactiver ça. Peut-être que SSL Labs mettra aussi à jour son diagnostic pour arrêter de pousser cette option. Au moins, si elle ne fonctionne plus, la question ne se pose plus. Donc je suis un peu pressé que ça arrive.

Si vous avez peut être de bonnes raisons d'imposer l'installation d'une application tierce sur mon appareil personnel

Félicitations pour la formulation humble et prudente.

Je pense moi qu'il n'y a pas de bonnes raisons de supposer que quelqu'un qui va voir des JO a nécessairement un smartphone, Android ou Apple qui plus est, et en tout cas d'obliger l'installation d'une application.

Générer un QR Code contenant les informations de réservation signées à l'aide d'une clé privée qui garantie que le billet n'est pas trafiqué, qu'on peut montrer avec n'importe quel appareil et même imprimer, c'est facile. En tout cas plus simple que de coder une application cliente pour deux OS et tout le backend derrière.

La SNCF génère des PDF avec des QR Code pour les trains, ça marche très bien.

Ensuite, il n'y a pas de bonne raison pour que l'application ne soit pas libre. Ça m'importerait plus que la disponibilité sur tel ou tel magasin d'application. Même si :

• c'est bien de se battre contre le monopole du Play Store.

• c'est bien de passer un magasin d'application avec lequel on peut interagir avec un client libre (je découvre l'existence d'Aptoide, et son caractère client libre - c'est la base d'F-Droid) (à noter quand même l'existence de clients libres pour le Play Store qui permettent de se passer de compte Google, même si ce n'est pas très approuvé par Google)

Petite note de fin :

en utilisant Aptoide - La boutique alternative d'applications Android

Ce "La" me chagrine un peu. Elle n'est pas la seule, et d'ailleurs je ne la connaissais pas, et si l'application était libre, tant qu'à faire ce serait pas mal qu'elle soit sur F-Droid.

La question est là pour savoir sur quelle version de l'application le feedback s'applique. Quand on utilise Lineage, il faut choisir Android sans aucun doute. Il n'y a aucun doute sur le fait que Lineage est une distribution basée sur Android et que pour Lineage, c'est l'application Android qui te concerne. Ensuite, rien n'empêche de préciser plus loin.

Du coup, si tu refais la démarche, si tu peux aussi réclamer la libération de l'application, ça pourrait être cool. D'autres institutions française s'y mettent, comme IGN, ce n'est plus un truc de geek qui plane à 2000.

PipeWire semble fonctionner beaucoup mieux que PulseAudio.

Sur le PinePhone original, la différence, c'est un son en Bluetooth saccadé avec déconnexions en permanence rendant l'ensemble inutilisable. Avec Pipewire, tout fonctionne. Saccades occasionnelles.

Ce n'est pas aussi violant sur ordinateur classique, mais je me dis que ça doit être moins gourmand et plus stable.

Je suppose que PipeWire a été conçu avec la connaissance et l'expérience accumulée avec PulseAudio et, en à l'esprit, le besoin de gérer aussi les flux vidéos. Le remplacement est drop-in ou quasi, les APIs fonctionnent telles quelles et le niveau de compatibilité m'impressionne. Globalement, les trucs dépendant de PulseAudio n'ont rien eu à faire. Le remplacement a l'air plutôt transparent pour l'utilisateur, et a été effectué dans les distributions au moment où ça fonctionnait bien. Ça me parait sain comme démarche. J'ai l'impression que c'est une bonne manière de remplacer une brique technique, pour les bonnes raisons, au bon moment.

Comme tous cela : https://sourceware.org/bugzilla/buglist.cgi?query_format=specific&order=Importance&no_redirect=0&bug_status=__open__&product=glibc&content=

Et donc ?

Parfois c'est (c'était ?) même mensonger : "Garanti sans virus".

C'est sûr qu'ils n'allaient pas formuler "Notre antivirus a été incapable de trouver un virus dans ce courriel", pourtant ça aurait plus techniquement correct.

Dans le genre, il y a aussi les "Envoyé depuis mon [modèle]".

Je déteste ces bouts de pub.

Oui, la plupart en ont, mais est-ce par choix de conception ou alors des lois comme celles-là l'obligeant existaient déjà ?

Et puis, faut voir la complexité d'un limitateur qui doit connaitre la limitation actuelle, ce n'est pas la même qu'un limitateur ou un régulateur que la personne qui conduit règle à la vitesse limite souhaitée. Ceux-là requièrent certainement un ordinateur de bord, mais probablement beaucoup plus rudimentaire, la fonctionnalité est beaucoup plus simple / moins complexe, avec peut-être moins de risque de bugs.

Globalement, ça oblige les voiture à avoir un ordinateur de bord, n'est-ce pas ?

J'ai appris hier que c'était de la propagande pour redorer son image.

… bon, ils auraient eu tort de ne pas essayer, j'imagine…

J'imagine qu'en se passant de viande à long terme, on se désaccoutume du cinquième goût, l'umami.

Nope. Une alimentation végétarienne est facilement riche en umami. Il y en a par exemple dans les chips, la sauce soja, la sauce tomate, l'ognon, le miso, les champignons. J'apprends aussi qu'il y en a aussi dans les petits pois, les fèves, le celeri.

Et globalement les trucs fermentés.

Il n'y a aucun risque de manquer de protéine, au contraire, on en consomme beaucoup trop !

On en mange beaucoup de trop, c'est absolument certain mais en manquer n'est pas bon non plus

Globalement, la protéine, c'est un faux problème. Elle ne manque dans aucun régime varié, même végétalien. Il y a plein d'ingrédients à base de plantes riches en protéines. C'est même difficile d'en manquer, je suppose qu'il faut se limiter aux fruits et légumes ou un truc dans le genre, ou manger toujours la même chose non diversifiée qui fait que tu n'as pas tous les acides aminés qu'il faut. Il faut vraiment avoir un régime tout pété, faut presque faire des efforts conscient pour avoir des soucis avec les protéines. Ou avoir des gros troubles de l'assimilation mais là, ce n'est plus purement une question de régime alimentaire, on entre dans le domaine du médical.

L'industrie de la viande nous a bien lavé le cerveau avec ces questions de protéines. "Mais et les protéines, comment tu fais ?" Ben… ça juste marche.

Les gens ne savent pas ce que sont les protéines en fait, et répètent ce qu'ils entendent. Et comme on l'entend partout, bah ça fonctionne. Et comme ça rassure ("ah oui, si j'arrête la viande, je vais manquer de protéine, donc je ne peux pas arrêter la viande. Ouf."), c'est plutôt plaisant comme théorie, donc on ne se bouscule pas pour la vérifier.

Il y avait pourtant des cibles plus efficaces : le fer (un peu moins bien assimilable en version végétale - mais bon, on s'en sort quand même et l'anémie, ça ne concerne pas que les végétariens en réalité), la B12 (absente dans un régime végétalien), quelques autres vitamines où il faut éventuellement faire un peu attention… en variant.

je ne parles pas du veganisme qui a pour principal "but" de réduire l'impact écologique

C'est un des buts possibles, mais je ne dirais pas que c'est le principal.

Un des motivations les plus importantes (la plus importante ?) dans la cause est la cause animale.

Cela dit, je ne sais pas dans quelle mesure ça impacte ta démonstration, j'ai du mal à comprendre comment cette remarque s'insère dans ta démonstration.

Par ailleurs :

malgré tout manger biologique ne fait pas toujours l'unanimité

Dans le cadre de la santé : par qui, pour quelles raisons ? (ici je ne remets pas en cause, juste que ça m'intéresserait d'avoir plus de détails là dessus)

Même manger des fruits et légumes est contesté

Par qui, quelles raisons ? Je pensais que ça faisait consensus. Faut pas abuser du sucre et ne pas manger que des fruits et légumes, sinon ça se passe mal, mais après ?

avec plus de fibres

et moins de sucres rapides

le pain blanc n'est pas toxique pour autant cela dépend de ce que tu manges à côté

Oui, de la même manières que les bonbons et sucreries ne sont pas toxiques, mais ça ne dit pas grand chose.

(évidemment, il y a un bon fossé entre un bonbon 100% sucré et du pain blanc, mais je ne sais pas ce que tu cherches à démontrer)

https://www.youtube.com/watch?v=NzvsUJiQVKA

(c'est une vidéo courte, 17 secondes)

(difficile de résister à partager le texte)

ce qui est mieux d'un point de vue de l'optimisation

Ce n'est même pas clair que ça fonctionne en pratique : j'imagine que les FS du noyaux sont optimisés à mort, alors qu'il n'y a peut-être pas autant de pression pour le faire dans Grub.

Sur un sujet connexe, j'ai un disque totalement chiffré avec Btrfs, avec Grub c'est un peu la misère, il prend autour d'une minute à déchiffrer et parfois l'OS demande le mot de passe une deuxième fois selon comment tu navigues dans les menus dans grub. Alors que systemd-boot est capable de déchiffrer immédiatement et c'est mieux intégré.

vu que grub est en GPL 3+, et le kernel en GPL 2 uniquement, et je pense que c'est pas automatiquement compatible

Ça peut fonctionner si le code du FS est sous licence permissive ou sous GPLv2+ (ce qui reste possible, mais je ne sais pas quelles sont les règles exactes).

Je peux conseiller d'ajouter

apc.enable_cli=1

Juste après [PHP] (première ligne du fichier) dans /etc/php/8.X/cli/php.ini pour ne pas avoir à avoir à spécifier --define apc.enable_cli=1 dans chaque commande :-)

Merci pour l'article, j'ai scanné en diagonale, peut-être que je mettrait un truc comme ça en place à l'occasion.

et sensibiliser les participant·es (dont des enfants) au sujet.

J'utilise curl et wget assez souvent. Quel est le cas d'usage de wcurl ? Pourquoi ne pas juste utiliser wget quand on veut son comportement ? Est-ce pour pour pouvoir utiliser des options de curl en plus du comportement par défaut de télécharger vers un fichier comme wget ?

J'ai lu l'article de blog qui annonce wcurl mais je n'ai pas vu la motivation.

Il y a ces gadgets qui permettent de lire des morceaux sur une clé USB et diffuser en FM dans une voiture. C'est très faible portée. Ça doit être légal dans ce genre de condition ?

Après, il ne faut pas que la solution matérielle soit aussi ou plus coûteuse que le poste radio lui-même, ni trop consommatrice, pour que ça soit écologiquement / économiquement intéressant.

J'ai arrêté de batailler en me disant qu'il ne reste plus personne chez eux (beaucoup sont passés chez gmail…) mais de temps en temps ça ma bloque un envoi, c'est pénible. La procédure pour se faire déblacklister ou whitelister ou je ne sais quoi est absolument imbitable (et probablement conçue pour).

Ouais. Je me suis battu des années avec ça. À force d'échanges avec leur "support", j'ai fini par recevoir un message qui fait penser qu'ils utilisent un système antispam maison qu'ils n'arrivent pas à maitriser.

Et depuis peut-être un an, plus aucun problème, je peux envoyer des mails vers MS et ça fonctionne. Il y a eu des changements d'ip mais je ne corrèle pas les changements d'ip et ça.

C'est très opaque.

Je n'ai jamais eu de problème avec Gmail. Heureusement, parce que je ne sais même pas si c'est possible de les joindre (avec MS, c'est seulement horriblement compliqué).

Pas faux ! "Ne jamais redemander" serait un bouton plutôt ordinaire :-)

Je n'avais pas pensé à ce cas d'usage. J'avais Netflix en tête, clairement si tu t'opposes aux DRM tu n'y retournes pas une deuxième fois.

D'un autre côté, ça ne va pas marcher si on n'accepte pas, du coup ça sert à quoi de revenir sur le site ?

Il me semble que le message peut également être ignoré.

J'ai l'impression que c'est plutôt bien comme comportement, ça permet de comprendre pourquoi quelque chose ne fonctionne pas.