raphj a écrit 1624 commentaires

Soyons sérieux un instant.

D'accord, mais comment ? Je regrette aussi la collecte de données, les dysfonctionnements trop nombreux et les prix qui ne correspondent pas au service, et notamment au fonctionnement tout pourris de la carte avantage adulte beaucoup trop concentrée sur les weekends (on te dicte comment tu devrais te déplacer). Mais quelle est l’alternative ? Choisir la voiture au lieu du train ? Est-ce bien sérieux ? La voiture, elle pollue, il faut lui trouver une place en ville, elle coûte un max de blé et pose aussi des problèmes de retards (embouteillages, etc). Et c'est aussi un mode de transport beaucoup plus risqué, et également stressant (différemment, mais quand même stressant). Tes données personnelles, tu les donnes à ton assurance et pour l'immatriculation du véhicule, alors est-ce que c'est si différent finalement ?

Bien sûr, je n'en veux pas aux gens qui se sont rabattus sur une solution qui fonctionne après avoir été mis trop de fois en difficulté par l'état de nos transports publics. On fait comme on peut. Mais rebasculer à la voiture permet aux régions et au gouvernement de continuer à délaisser le train. Si d'un coup une grosse partie de la population se mettait à dépendre du train, des solutions seraient peut-être rapidement mises en place. L'argument écologique est également réel. Le transport public, c'est un droit et un confort qui s'use si on ne s'en sert pas.

En réalité, l'état de nos trains reflète la politique des gens qu'on a élu. Ça se voit particulièrement bien en Auvergne Rhône Alpes. La privatisation, l'ouverture à la concurrence et le manque d'entretien du réseau national en sont des excellents témoins aussi. C'est le même problème que pour les hôpitaux, l'éducation nationale, la sécurité sociale, la retraite, le chômage.

J'espère que les gens qui râlent sur l'état des trains n'ont pas voté pour les gens qui ont mené une politique destructrice pour les transports en commun, et d'ailleurs plus généralement pour le commun, et encore plus généralement sur tous les plans. Parce que ce serait un comble. Faudra bien réfléchir sur ce qu'on vote aux futures élections et vérifier qu'on n’encourage pas le « chacun pour sa gueule, tous pour le profit ».

(note : quand je parle de transports en communs dans ce commentaire, j'exclus l'avion, qui, techniquement, en est aussi un, je suppose)

Je sais qu'il faudrait que je me débarrasse de AdBlock+, mais c'est pas évident. On m'a conseillé uMatrix, que j'ai testé un petit peu : trop pour moi, je suis vieux, j'ai mes habitudes avec NoScript, et la finesse de uMatrix

Pourquoi pas uBlock Origin ? Adblock+ est de mèche avec les annonceurs, tu peux payer pour que ta pub ne soit pas bloquée et elle est mise dans une catégorie "publicité acceptable".

Ce genre de script qui créée des hard links pour faire des instantanés, ça a l'air d'être une bonne option quand on n'a pas accès a des fonctionnalités natives au FS (et d'ailleurs je vais garder l'idée sous le coude), mais ces dernières me semblent beaucoup plus confortables, fiables et robustes. Et probablement plus légères aussi.

Les bases de données permettent de créer des exports en respectant l'atomicité sans devoir les arrêter. C'est jouable si elles ne sont pas trop grosses.

Arrêter la base de données n'est pas suffisant, rsync ne garantie pas l'atomicité (tu as dit règle minimum, j'ai bien conscience que je ne contredis pas, mais ça semble important de l'expliciter). Je fais comme ça et je n'ai jamais eu de soucis non plus, et au pire une incohérence serait résolu lors de la sauvegarde suivante, mais je sais que ce n'est pas top et que je joue avec le feu.

Un FS comme btrfs sur le serveur permettrait justement de créer un instantané de manière atomique, et après tu lances ton rsync tranquillement sur l'instantané.

Je lance rsync du serveur vers un sous-volume btrfs, et j'en fait un instantané lecture seule avec la date dans son nom.

Ça fait une sauvegarde incrementale et complète. J'ai l'état complet du stockage pour chaque jour, mais ça ne prend pas la place de la somme des états de chaque jour grâce au fonctionnement des instantanés btrfs. Si seuls quelques mégas on changé sur le serveur depuis la dernière sauvegarde, l'instantané ne prend effectivement que quelques mégas sur le disque de sauvegarde. Mais, à l'utilisation, c'est aussi pratique qu'une sauvegarde complète. Ça permet de faire de très nombreuses sauvegardes pas chères et ultra rapidement.

Seul un FS avec ce genre de fonctionnalités permet ça. C'est un de leurs intérêts. Il y a aussi la compression pour gagner encore de la place, et les vérifications de sommes de contrôle pour l'intégrité des données.

J'utilise beaucoup Btrfs, notamment pour la fonctionnalité de sous-volumes (et donc de Copy-on-Write) pour faire des sauvegardes incrémentales utilisables comme des sauvegardes complète.

Je m'attendais à ce que Btrfs soit plus lent qu'ext4 et autres FS sans CoW, mais pas autant. Je vois bien que l'objectif était de comparer l'état des FS sans ajustements, mais ce serait intéressant de savoir ce qu'il en est quand on active la compression et qu'on utilise noatime, c'est comme ça que je l'utilise, et j'utilise aussi noatime sur ext4. Je n'ai jamais eu besoin du dernier temps d'accès, et ça a l'air de faire beaucoup d'écritures inutiles, ça fait même peur pour la longévité des SSD (mais ce n'est peut-être plus un problème aujourd'hui ?).

Cela dit, mes serveurs sont sous ext4, seule la partie sauvegarde est en Btrfs. Donc les perfs ne sont pas critiques, par contre ext4 ne répondrait pas à mon besoin. Sur l'ordinateur portable, j'utilise Btrfs (pour la compression, et la possibilité de faire des sous volumes pour expérimenter et jeter), donc là, plus de perf serait sympathique :-)

Pour mes utilisations, ZFS serait une alternative sérieuse, donc une comparaison avec lui serait aussi intéressante. Cela dit, il faudrait vraiment un avantage écrasant que je pour m'embête avec ça, vu que ce n'est pas installé de base. On pourrait penser à la fiabilité, mais en pratique je n'ai pas eu trop de soucis avec Btrfs jusqu'à présent et je ne sais pas ce qu'il en est de la fiabilité de ZFS on Linux non plus.

En tout cas faut que je suive BcacheFS un peu sérieusement, ça a l'air intéressant, y compris comme alternative à Btrfs.

Debianeux dans l’âme, j’avais jusqu’à il y a peu opté pour Mobian sur le PinePhone. Je me disais qu’avec Debian, j’étais certain d’avoir tout ce qu’il faut dans les dépôts. J’avais aussi peur de l’aspect différente libc (PostmarketOS, basée sur Alpine, utilise Musl, et pas la glibc).

Mais Plasma Mobile n’est pas dans un état très utilisable sur Mobian, et je voulais l’utiliser, surtout dans sa version 6.

J’ai fini par essayer PostmarketOS. J’ai donc découvert Alpine par la même occasion.

C’est top :

• pmbootstrap, pour construire des paquets ou des images installable avec les paramètres que l’on souhaite, est un superbe outil. Il peut être utilisé sur la machine sous PostmarketOS, ou sur n’importe quel ordinateur faisant tourner n’importe quelle distribution Linux répandue, permet de cross-compiler, et aussi de faire du développement en lançant des choses dans qemu.
• tout semble léger : j’ai l’impression qu’on peut installer un tas de chose et ça prend moins de place / c’est plus léger
• on a des paquets très à jour, y compris pour Plasma 6 pour lequel il y a un mainteneur qui fournit des quasi nightlies
• il y a une prise en charge plus ou moins poussée de beaucoup d’environnement de bureaux
• leur récapitulatif par appareil (tablette, téléphone) donne une bonne vue sur le bon fonctionnement du matériel avec PostmarketOS, et, presque par extension, une prédiction raisonnable pour les autres distributions (peut-être dans le futur)
• il y a une forte volonté de garder une base libre aussi pure que possible, point que j’aime bien aussi chez Debian
• tout semble marcher mieux : vidéos plus fluides, son par Bluetooth plus stable, Plasma Mobile est effectivement utilisable alors que ça n’arrête pas de crasher sur Mobian, etc
• il y a un écran d’accueil lors du premier démarrage sur Plasma 6, et ça donne l’impression qu’il y a un peu de peaufinage. Mais peut-être que c’est un truc Plasma Mobile plus que PostmarketOS. Cela dit, j’ai bien l’impression qu’il y a une belle intersection ici : les gens qui travaillent sur Plasma Mobile sont probablement beaucoup sous PostmarketOS.
• j’ai été étonné à quel point Musl n’est pas une source d’ennui. J’avais supposé que comme tout est développé et testé sous glibc, il y aurait des petits soucis à droite à gauche, mais non, apparemment pas. J’imagine qu’il y a déjà eu beaucoup de correctifs partout pour ça et que maintenant, ça marche tout simplement bien.

Dans les défauts, je noterais que :

• il peut manquer certaines petites choses par défaut. Par exemple, je n’avais pas de connectivité internet par Bluetooth (PAN), ce qui ne m’était jamais arrivé jusqu’à maintenant. En fait, c’est juste que le module Bluetooth de Network Manager n’était pas installé. c’est quelques Kio, ça pourrait venir par défaut quand on installe network-manager ou Plasma 6. J’ai mis un certain temps à comprendre parce que la documentation prétendait que ça pouvait marcher, mais que ce n’était pas activé par défaut dans la stack Bluetooth de la distribution. En fait, ça l’était, donc j’ai creusé une mauvaise piste pendant un petit moment. J’ai bien sûr corrigé la doc.
• vu que c’est basé sur Alpine, le système de boot est OpenRC, et perso, je préfère largement systemd. Ça démarre plus vite, c’est robuste, et je sais l’utiliser. Je ne vois pas d’avantage clair à OpenRC, que des inconvénients, sinon ce dernier point serait moins pertinent, je n’ai pas trop de soucis à apprendre à utiliser un nouvel outil s’il est mieux. Mais ce problème va disparaitre, parce que l’équipe de PostmarketOS semble d’accord avec moi. Ils sont en train de passer à systemd, déviant plus fortement d’Alpine, alors qu’en général, ils préfèrent être le plus proche d’Alpine et remonter le plus de choses possible.

J’ai aussi découvert qu’Alpine fonctionne aussi très bien comme distribution de bureau. Je l’ai essayée sur une vieille tablette Intel (sur laquelle il vaut mieux installer une distribution x86 32 bits, donc ça limite les choix – en particulier pas de postmarketOS pour cette raison), ça marchait bien, sauf un bug d’affichage très bloquant. J’ai donc basculé sur openSUSE Tumbleweed. Même bug bloquant finalement, probablement lié à une mauvaise interaction avec le pilote graphique et QML, mais donc ce n’était pas un bug d’Alpine finalement.

Ça donne envie de pouvoir utiliser PostmarketOS sur bureau, étant une Alpine bientôt basée sur systemd avec un pmbootstrap super pratique, permettant de faire du développement sur les paquets de la distribution très facilement. Et même si le but n’est pas de packager, pour travailler n’importe quel logiciel un peu répandu, il y a probablement un paquet qui permet de télécharger les sources, les dépendances, et de compiler les modifications ultra-facilement, et sinon le format des paquets est méga simple. Les paquets Alpine semblent aussi très « vanilla », il n’y a pas l’air d’avoir beaucoup de patchs appliqués par la distribution. Non pas que je trouve que ce soit une mauvaise chose, c’est cool que la distribution fasse de l’intégration, mais ça peut simplifier le développement et le débogage.

Bon, pour finir, le PinePhone, ça reste lent, et le PinePhone Pro n'a pas encore une très bonne gestion de la batterie. Globalement, les deux appareils avec les distributions actuelles ne me paraissent pas encore assez fiables et autonomes (niveau batterie) pour être utilisés au quotidien et pour qu'on puisse compter dessus en cas d'urgence. Côté téléphonie, le son était catastrophique surtout côté correspondant quand j'avais testé. J'attends un peu avec impatience un matériel fiable pour faire tourner du Linux mobile dessus, sans blobs propriétaires devant tourner sur le CPU principal.

“It's going to be nearly undetectable and nearly unpatchable.” Only opening a computer's case, physically connecting directly to a certain portion of its memory chips with a hardware-based programming tool known as SPI Flash programmer and meticulously scouring the memory would allow the malware to be removed, Okupski says.

C'est difficile à détecter, d'accord, mais est-ce qu'il ne suffit pas de reflasher la SPI complètement ne suffirait pas à s'en débarrasser ?

Bien sûr, il faut déjà pouvoir flasher la SPI, ce qui n'est malheureusement pas viable dans beaucoup de situations (ça demande souvent des outils spécifiques, souvent d'ouvrir l'ordinateur, etc - et le faire depuis l'OS, si c'est possible, ne serait pas fiable puisqu'un bootkit suffisamment élaboré pourrait faire mentir le processus de flashing si je comprends bien - et si on n'est pas spécialiste qui a les bons outils, il faut déjà avoir entendu parler de la faille et en avoir assez quelque chose à faire pour aller trouver et payer quelqu'un pour le faire - si tant est qu'on a le bon binaire à flasher à disposition).

Tout ça laisse penser que tous ces mécanismes qui permettent de flasher des choses dans le matériel sont des portes ouvertes à ce genre de vulnérabilité - y compris des mécanismes comme Secure Boot, qui par construction demandent de pouvoir enregistrer des données, et qui donc sont susceptibles d'apporter des vulnérabilités alors qu'ils sont là pour le contraire…

For systems with certain faulty configurations in how a computer maker implemented AMD's security feature known as Platform Secure Boot—which the researchers warn encompasses the large majority of the systems they tested—a malware infection installed via Sinkclose could be harder yet to detect or remediate, they say, surviving even a reinstallation of the operating system

C'est quand même con, une fonctionnalité là pour la sécurité qui réduit la sécurité. Je comprends bien que le problème se situe lors de l'intégration de cette fonctionnalité, mais quand-même.

devnewton, jamais décevant ! :-)

"Tu sais où tu peux te la mettre, ton application de merde ‽" prend tout son sens.

Mais ça ne posera problème que pour les gens qui ont acheté à un endroit non officiel, ou qui ont vendu leur ticket, donc finalement ça m'a tout l'air de marcher comme prévu finalement.

Il n'y aura jamais de problème pour quelqu'un qui a acheté son billet normalement.

Même le cas où quelqu'un se fait voler discrètement son ticket peut être géré : la personne pourrait montrer la transaction d'achat avec le site officiel.

Tu devrais savoir qu'il ne faut pas acheter un premier billet n'importe où. Après oui, il y a toujours le phishing, mais de toute façon l'achat se fait sans l'application d'après le journal, donc l'application ne gère même pas ça sauf si j'ai loupé quelque chose.

Une application n'est pas nécessaire pour ça. Par exemple, les billets de la SNCF sont nominatifs, impossible donc de les revendre, et pourtant il n'y a pas d'application nécessaire.

L'article met sur le même plan OSM, OSMAnd et OrganicMaps, alors que ces deux dernières sont des applications mobiles basées sur la première (qui n'est pas une application, mais une base de données cartographiques).

L'article affirme qu'on privilégiera OSMAnd pour la navigation sans expliquer qui est "on" ni pourquoi, et affirme qu'on peut utiliser les données de Wikipedia, mais c'est aussi vrai pour Organic Maps.

De même, l'article affirme qu'il y a les sentiers de randonnée sur OrganicMaps, mais c'est vrai aussi sur OSMAnd, et les deux souffrent du même problème en France de l'absence des GR sur OSM, parce que la Fédération française de randonnée pédestre interdit leur réutilisation, c'est pourtant un point important à soulever (et qui mériterait probablement plus de publicité, ce qui permettrait peut-être de résoudre le problème un jour).

OSMAnd et OrganicMaps sont deux excellentes applications un peu complémentaires (caricaturalement : OSMAnd est plus complet, OrganicMaps est plus léger et beaucoup plus simple d'utilisation) qui mériterait une description plus approfondit, il suffirait de passer 5 minutes de plus pour avoir des choses plus intéressantes et exactes à dire. 5 autres minutes auraient permis une introduction bien plus utile et complète d'OSM, qui mérite plus qu'un petit paragraphe tout moisi.

Avec un tel niveau de vulgarisation, l'article arrive quand même à utiliser le mot fork sans expliquer ce que c'est, donc il loupe sa cible.

Allez, on va finir sur deux points plus positifs :

• L'article a le mérite de souligner que Waze appartient à Google
• et de faire voir aux gens qu'il y a d'autres choses que Apple et Google en matière de carte, et d'introduire OSM

Beaucoup de gens ne savent pas ces choses.

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…