gouttegd a écrit 1805 commentaires

Comment fait-on pour révoquer un diplôme ?

C’est pas ça la difficulté. Il suffit de publier une attestation qui dit que le diplôme est annulé. Même principe qu’un certificat de révocation dans le monde de la cryptographie à clef publique (X.509 ou OpenPGP) — d’ailleurs cette « attestation » pourrait s’appeler exactement comme ça, un « certificat de révocation de diplôme ».

Non, le problème, c’est l’authentification : Comment sait-on que cette révocation (ou le diplôme original, d’ailleurs) vient bien de telle université ou école ?

Parce qu’elle émane d’une adresse (au sens de la chaîne de blocs : une adresse Bitcoin, une adresse Ethereum, etc.) qui prétend appartenir à l’université en question ? Mais comment sait-on que c’est réellement le cas ?

La chaîne de blocs n’apporte ici rien de plus (si ce n’est de la complexité !) par rapport à une signature cryptographique comment on sait en faire depuis trente ans.

Là tu démontres l’intérêt des signatures cryptographiques. Aucun de ces problèmes ne nécessite une chaîne de blocs.

L’intérêt des cryptomonnaies (parce que oui, il y en a un en fait, j’avais oublié), c’est de se payer des barres de rire en observant les libertariens découvrir pourquoi les régulations bancaires existent.

L’intérêt des jetons non-fongibles, c’est de se payer des barres de rire en observant les mêmes libertariens découvrir pourquoi il y a des lois qui régissent la propriété.

Mais bon, ça fait cher la barre de rire, quand même.

Apparemment beaucoup de gens pensent que c'est une super idée, alors que c'est surtout de la ploutocratie qui mènera comme le proof of work à une concentration du pouvoir dans quelques mains.

Disons que puisque le résultat final sera de toute façon le même, à choisir, la méthode qui n’implique pas de cramer de l’énergie pour rien m’apparaît, sinon comme une super idée, au moins comme une moins mauvaise idée.

je suis intéressé par l'intérêt éventuel des autres usages possibles des blockchains

Si tu en trouves (des intérêts), fais-le savoir !

Depuis le début, les chaînes de blocs sont une solution en quête d’un problème.

Je n’ai encore vu aucun problème réel pour lequel les chaînes de blocs sont une solution optimale, encore moins de problème pour lequel elles sont la seule solution…

En quelques mots :

Dans un système à preuve de travail, n’importe qui¹ peut ajouter un nouveau bloc à la chaîne, pour peu qu’il trouve une solution à un problème cryptographique qui n’est solutionnable que par force brute. Par exemple, trouver une valeur dont le condensat cryptographique répond à certains critères, ce qui ne peut se faire qu’en calculant des condensats sur un grand nombre de valeurs jusqu’à tomber sur une bonne. À chaque bloc, tous les mineurs s’attaquent au problème, le premier qui trouve une solution gagne.

Dans un système à preuve d’enjeu (proof of stake), l’ajout d’un bloc ne coûte rien (pas de problème à résoudre, de calculs difficiles à faire), mais n’est possible qu’à condition d’avoir un certain « capital » dans la chaîne de blocs (dans le cas d’Ethereum, d’avoir des ethers), et de mettre ce capital en jeu. Concrètement, des participants à la chaîne signalent leur intention d’être des validateurs de blocs, en payant pour ça avec une partie de leur capital. Chaque fois qu’un bloc doit être ajouté, plusieurs blocs possibles sont proposés et un groupe de validateurs est sélectionné aléatoirement pour décider quel bloc doit être ajouté. Le bloc qui obtient le plus de votes de la part des validateurs est finalement ajouté, et les validateurs qui ont voté pour les autres blocs (ou qui ont fait des trucs douteux, comme voter pour plusieurs blocs à la fois) sont pénalisés — ils perdent une partie du capital qu’ils ont mis en jeu quand ils sont devenus validateurs.

Dans les deux systèmes, on a des « perdants », mais ce qu’ils perdent est différent :

• avec une preuve de travail, les « perdants » (ceux qui étaient en train de miner pour tenter de valider un bloc, et qui se sont fait coiffer au poteau par un autre mineur) ont perdu l’argent nécessaire à faire tourner leurs machines de minage (c’était ça en fait leur « enjeu ») ;

• avec une preuve d’enjeu, les « perdants » (les validateurs qui ont voté pour un bloc n’ayant pas été validé par la majorité des validateurs) ont perdu une partie de leur capital (mais énergétiquement parlant ça ne leur a rien coûté).

---

¹ Pour certaines valeurs de « n’importe qui ». En pratique, c’est réservé à un petit nombre, ça fait belle lurette que l’utilisateur lambda avec son PC ne peut plus espérer miner quoi que ce soit.

J'aurais eu tendance à croire que --option=argument et --option argument sont deux équivalences. Ce serait donc inexact?

Comme déjà dit par ailleurs, les options longues ne sont pas standardisées par POSIX, donc on ne peut pas vraiment compter sur un comportement identique partout.

Dans le monde GNU, l’usage (représenté notamment par getopt_long) veut que --option argument soit équivalent à --option=argument seulement si option est déclarée comme attendant un argument obligatoire. Si elle est déclarée comme attendant un argument optionnel, --option argument est interprété comme étant l’option option sans argument, suivi de l’argument positionnel argument.

Ici, jest semble suivre les conventions GNU : l’option --bail attend un argument optionnel (puisque la documentation précise que la valeur par défaut est 1, indiquant bien qu’on peut ne pas spécifier explicitement une valeur), donc si on veut passer un argument il faut utiliser la forme --bail=X.

respect pour ta ténacité

Je n’arrive pas à lâcher prise quand je suis confronté à un problème de ce genre. Ça devient une affaire personnelle entre moi et la machine, et comme disait Coluche, « c’est le plus intelligent des deux qui doit céder. » :D

Juste avant d'arroser copieusement le bouzin d'une poignée d'insultes

Un des avantages de travailler à domicile (oui parce que mon collaborateur était en réalité à 100 km de moi, le déboguage s’est fait dans une discussion Slack — ajoutant au passage à la frustration), c’est que personne ne me voit ou m’entend

• ni balancer des bordées d’injures quand ça ne marche pas ;
• ni esquisser un pas de danse lorsque ça marche.

En l’espèce, il se pourrait que dans le feu de l’action j’ai traité les développeurs de GNU Make de progéniture de péripatéticienne, et que je les ai invité à avoir des relations d’un genre que la morale chrétienne réprouve. Je profite de l’occasion pour leur présenter mes excuses, je ne le pensais pas vraiment.

Et toi, ami lecteur, as-tu été témoin de phénomènes vraiment bizarres?

J’en ai eu un hier.

Qui s’est avéré en fin de compte n’avoir rien d’inexplicable, mais qui sur le coup m’a fait me poser pas mal de questions…

Un collaborateur me signale qu’il n’arrive pas à exécuter une règle Make particulière :

$ make patterns
make: dosdp-tools: Permission denied
make: *** Makefile:155:patterns] Error 127

Huh ? Permission denied ?

Rapide coup d’œil sur la règle patterns dans le Makefile :

patterns:
        @dosdp-tools generate --table-format=csv [commande tronquée, elle est assez longue et ce n’est pas important]

Bon, euh, t’as bien installé dosdp-tools, t’as mis l’exécutable dans le PATH ?

$ which dosdp-tools
/tools/dosdp-tools/bin/dosdp-tools
$ dosdp-tools --version
name: dosdp-tools, version: 0.19.3, scalaVersion: 2.13.18, sbtVersion: 1.6.2

Ok… dans le contexte du Makefile le PATH est toujours le bon ?

patterns:
        @which dosdp-tools
        @dosdp-tools generate --table-format-csv […]

$ make patterns
/tools/dosdp-tools/bin/dosdp-tools
make: dosdp-tools: Permission denied
make: *** Makefile:156:patterns] Error 127

Bon, quelque part, ça a du sens, si le problème était que dosdp-tools était introuvable à cause d’un mauvais PATH ou quelque chose dans le genre on aurait un No such file or directory (ENOENT), pas un Permission denied (EACCES)…

On a vérifié que l’exécutable était bien exécutable ? Il est pas en 644 ? Et tous les dossiers parents sont bien traversables ? Ah ben oui, tout ça c’est bon, puisque ça marche quand on invoque dosdp-tools directement depuis le shell, on l’a vu plus haut…

Bon, et si on passe le chemin complet dans le Makefile, il se passe quoi ?

patterns:
        @/tools/dosdp-tools/bin/dosdp-tools --version

$ make patterns
name: dosdp-tools, version: 0.19.3, scalaVersion: 2.13.18, sbtVersion: 1.6.2

Wopitain ça marche. Donc on dirait bien que Make n’arrive pas à trouver l’exécutable, mais dans ce cas pourquoi il nous sort une Permission denied ???

(À ce stade vous avez peut-être déjà une petite idée… Moi, à ce moment-là, non.)

Je vous passe un certain nombre d’essais et erreurs, mais parmi les essais, deux ont été « intéressants » :

patterns:
        if [ true ]; then dosdp-patterns ... ; fi

Fonctionne !

patterns:
        exec dosdp-patterns ...

Fonctionne ! WTF ? Appeler dosdp-patterns tout court échoue avec un Permission denied mais l’appeler via exec fonctionne ?

Là, je suis à deux doigts de suggérer de décoller et d’atomiser le site depuis une position en orbite, parce que c’est le seul moyen d’être sûr. Mais avant d’en arriver là, je teste un dernier truc (plus par frustration qu’autre chose) : renommer l’exécutable dosdp-tools en dosdp-wtf (en changeant évidemment l’invocation dans le Makefile), et… ça fonctionne !

En fait, si l’exécutable s’appelle n’importe quoi sauf dosdp-tools, ça fonctionne.

Ok… est-ce qu’il y aurait un autre dosdp-tools ailleurs dans le PATH (ça n’expliquerait pas pourquoi Make trouverait cet autre dosdp-tools, mais bon, on ne sait jamais) ? Non.

Là, je commence (enfin) à avoir une idée, sauf que l’explication à laquelle je pense ne devrait en principe pas arriver.

$ echo $PATH
/tools:/tools/dosdp-tools/bin:tools/apache-jena/bin:/usr/local/bin:/usr/bin/bin

Vous voyez le problème ? Le dossier /tools, qui contient un dossier dosdp-tools, est aussi dans le PATH ; et il est avant le dossier /tools/dosdp-tools/bin, qui contient le fichier exécutable dosdp-tools.

Normalement, ce n’est pas censé être un problème. Lorsqu’on invoque un exécutable sans son chemin complet, le shell sait qu’il doit chercher un fichier exécutable et non un dossier, donc s’il trouve dans le PATH un dossier du même nom que la commande invoquée, le shell l’ignore simplement et continue sa recherche dans le reste du PATH.

Mais ça, c’est valable pour le shell.

Il se trouve que GNU Make, lui, a sa propre logique pour trouver un fichier exécutable dans le PATH, indépendamment de celle du shell. Et que depuis la version 4.3, cette logique… est boguée : Make ne vérifie pas si ce qu’il a trouvé dans le PATH est bien un fichier régulier. S’il trouve dans le PATH un dossier avec le même nom que la commande à invoquer, ben… il tente d’invoquer le dossier !

(Le bug a été corrigé depuis, mais le correctif n’est pas encore disponible dans une version publiée.)

Voilà, comme je disais au final il n’y a rien d’inexplicable ou de bizarre — un simple bug, par ailleurs déjà connu et même déjà corrigé au moment où je le découvre. Mais deux heures de perdues à cause de ça quand même…

Par contre il me semble que java ne s'exécute pas sans utiliser une virtualisation en plus sur M1, sur risc-v et sur ios.

Sur risc-v et ios, je ne sais pas, mais sur M1, non, on n’est pas obligé de passer par l’émulation x86_64 (même si c’est possible). Il y a des JVM ciblant directement l’architecture arm.

Et c’est heureux, parce que pour avoir testé les deux (JVM x86_64 sous émulation vs JVM arm64 native), les performances de la version native sont bien meilleures, malgré tout ce que peut dire Apple sur la qualité de son émulation x86_64 qui soi-disant autoriserait à utiliser des programmes x86_64 sur M1 sans qu’on ne puisse jamais voir la différence…

Oui, parce que s’il y a une chose que l’histoire des trente dernières années nous a apprise, c’est que c’est très facile de passer d’une version d’un protocole à une autre, finger in the nose …

(Pour rappel, on est ici sur un site qui ne supporte ni IPv6 ni TLS 1.3.)

With versioned protocols instead of cipher agility: If a vulnerability is discovered in protocol version 1, you simply upgrade to protocol version 2.

Cacher derrière ce simply toute la difficulté des transitions protocolaires est d’une malhonnêteté crasse.

Surtout quand on parle de protocoles cryptographiques, avec TLS qui nous donne justement un très bel exemple d’un protocole où la gestion de la version du protocole a été magistralement foirée (ce qui a rendu possible toute une série de protocole downgrade attacks).

sans laisser l'utilisateur final se tirer une balle dans le pied.

Supporter l’agilité cryptographique ne signifie pas nécessairement « laisser l’utilisateur se tirer une balle dans le pied ». On peut supporter plusieurs algorithmes sans pour autant laisser à l’utilisateur le soin de choisir lequel utiliser.

Et il faut surtout en retenir qu'il faut éviter de n'avoir qu'un standard supporté partout, mais imposer (comment) les outils à accepter dès le départ plusieurs standards

Pour info, on a très bien su le faire jusqu’à présent. La plupart des protocoles impliquant de la crypto (TLS, SSH, OpenPGP…) supportent la notion d’agilité cryptographique : ils ne sont pas liés à un algorithme précis, mais permettent de choisir un algorithme de chaque type (algo d’échange de clefs, algo d’authentification, algo de chiffrement symétrique, algo de vérification d’intégrité) dans une liste d’algorithmes possibles.

Par contre, ça fait plusieurs années que pas mal de cryptologues critiquaient justement l’agilité cryptographique. Ça introduit de la complexité (notamment puisqu’il faut une étape de négociation à un moment donné pour que les différentes parties à la communication se mettent d’accord sur quels algorithmes elles vont utiliser, parmi ceux disponibles), et donc des risques accrus de bugs – y compris des bugs qui peuvent permettre de casser la confidentialité normalement apportée par la cryptographie…

Face à ces bugs, de nombreux cryptologues ont appelé à la fin de l’agilité cryptographique, en expliquant qu’il était désormais préférable de choisir une bonne fois pour toute un algo, et de se débarasser de toute la complexité liée à l’agilité.

Personnellement je n’ai jamais été convaincu par cette approche « tout miser sur un algo », je me suis réjoui de voir que les auteurs de protocoles ne semblaient pas y adhérer, et je me réjouis de voir Schneier souligner la nécessité de l’agilité cryptographique.

L’authentification à deux facteurs n’a pas pour but d’apporter une « sécurité absolue », mais d’apporter plus de sécurité qu’en l’absence d’authentification à deux facteurs.

Sans authentification à deux facteurs, un attaquant qui parvient d’une manière ou d’une autre à obtenir ton identifiant et ton mot de passe (ce qu’il peut éventuellement faire de façon passive sans prendre de gros risques) a tout ce qu’il lui faut pour se connecter à ton compte.

Avec authentification à deux facteurs, il lui faut en plus franchir la barrière supplémentaire posée par la vérification du second facteur. Ce n’est certes pas impossible, mais ça augmente le coût et la difficulté de l’attaque, ne serait-ce qu’en imposant une attaque active.

Même le plus faible des protocoles d’authentification à deux facteurs (le SMS, assez facilement contournable vues les vulnérabilités des protocoles liés aux SMS) est un poil plus sécurisé que pas de second facteur du tout.

Si j'avais lu plus attentivement, j'aurais également remarqué:

espace insécable  Unicode : 00a0,

qui est assurément une erreur (0xa0 : saut de ligne)

Euh, non, le saut de ligne (“line feed”) c’est 0x0A ; 0xA0 c’est bien l’espace inter-mots insécable.

Dans un « 3615 USUL » il y a des années, ledit Usul avait proposé « adversairissime » pour “boss” au sens de « adversaire de fin de niveau », ça avait de la gueule je trouve.

Si tu utilises un terme que tu considères de respect mais que son/sa destinaire considère que ça n'est pas respectueux, tu manques de respect.

Encore faut-il savoir quel terme l’autre considère comme non-respectueux. Et non, ce n’est pas forcément « mademoiselle » : même en 2022, il y a encore des femmes non-mariées qui n’apprécient pas de s’entendre donner du « madame ».

Je suis d’accord que continuer à utiliser l’une ou l’autre des formules après que ton interlocutrice a signalé sa préférence pour l’autre est clairement irrespectueux. Mais lors de la première interaction, si l’interlocuteur a utilisé la « mauvaise » formule, au lieu de conclure immédiatement à un manque de respect on peut aussi laisser le bénéfice du doute…

(À quand un équivalent français au Ms. anglais, qui à la différence de Mrs. et de Miss ne sous-entend rien du statut marital de la personne ?)

Je viens de visiter le Centre for Computing History de Cambridge (UK). Au milieu des Acorn BBC Micro, Silicon Graphics O2, Commodore 64, ou autre DEC PDP-11, figure l‘opposé d’un microprocesseur : le méga processeur.

Un processeur complètement fonctionnel, entièrement construit avec des transistors individuels et avec des LEDs de partout pour visualiser à chaque instant l’état du moindre registre et du moindre bit de mémoire.

Imaginé et construit par James Newman, le mégaprocesseur tourne à environ 20 kHz (mais on peut aussi le faire fonctionner en mode step-by-step, un cycle à la fois) et est associé à 256 octets de RAM.

Il est évidemment programmable (même si malheureusement Newman ne fournit l’assembleur que sous la forme d’un binaire pour Windows), et lorsque je l’ai visité aujourd’hui faisait tourner une version de Tetris.

Voilà, je ne crois pas avoir vu passer le mégaprocesseur sur DLFP, je pense que ça valait le coup d’être signalé même si l’assembleur n’est pas libre.

Et depuis, on n'en est qu'à la théorie

C’est bien là le problème (et c’est plus ou moins ce que dit l’ANSSI) : le domaine en est encore au stade de la recherche théorique, mais le NIST lui en est au stade de la standardisation, et il y a de quoi se demander si ce n’est pas beaucoup trop tôt.

C'est très bien de s'y pencher maintenant mais faut pas en attendre la lune non plus !

Dès lors qu’il est question de standardisation, on devrait au moins en attendre des algorithmes au moins aussi résistant à des attaques non-quantiques que les algorithmes que l’on a déjà ! Que des finalistes s’avèrent être des trucs que je peux craquer sur mon vieux portable en tâche de fond pendant que je moule sur DLFP, ça n’inspire pas vraiment confiance…

Pour élaborer un peu :

On peut évidemment se féliciter que ces attaques (contre RAINBOW ou contre SIKE) apparaissent pendant la compétition (où il est encore temps d’éliminer ces algorithmes) plutôt qu’après la sélection éventuelle d’un de ces algorithmes.

On peut même dire que c’est un des rôles de la compétition que de stimuler la cryptanalyse des algorithmes candidats, et là-dessus il semble clair que la compétition a bien eu l’effet escompté : RAINBOW a été décrit pour la première fois en 2005, SIDH en 2011, et pendant des années ils sont apparus comme solides. Commence la compétition du NIST en 2017, et quelques années après les attaques efficaces arrivent, ce n’est sûrement pas un hasard.

Sauf que quand même, je trouve un peu inquiétant que des algorithmes soient complètement et pratiquement cassés alors qu’ils sont au stade final de la compétition.

Si l’on compare avec la compétition AES, à ma connaissance aucun des finalistes de la compétition (RIJNDAEL, SERPENT, TWOFISH, RC6, MARS) n’a jamais été pratiquement cassé. Ils ont eu leurs lots d’attaques théoriques, certes (y compris et peut-être même surtout le vainqueur RIJNDAEL), mais jamais d’attaque pratique et dévastatrice du genre de celles dont on parle ici. Pareil à ma connaissance pour les compétitions CAESAR (sélection de modes de chiffrement authentifié), SHA-3 (sélection d’algorithmes de condensation), ou PHC (sélection d’algorithmes de condensation de mot de passe).

Ça conduit certains spécialistes sur Twitter à penser que le domaine de la cryptographie post-quantique manque de maturité. Dans la même veine l’ANSSI déclarait déjà en début d’année, dans ses vues sur la transition vers la cryptographie post-quantique que

the maturity level of the post-quantum algorithms presented to the NIST process should not be overestimated. Many aspects lack cryptanalytical hindsight or are still research topics

Dans le même genre, on a aussi eu RAINBOW, un algorithme de signature qui était parmi les finalistes du troisième tour de la compétition PQC… avant d’être complètement cassé il y a quelques mois par une attaque au titre un brin moqueur (« un ordinateur portable et un week-end suffisent à casser RAINBOW »).

On a déjà parlé ici d’algorithmes de cryptographie post-quantique (PQC, Post-Quantum Cryptography) récemment sélectionné par le NIST pour être standardisés.

La compétition PQC du NIST ne s’arrête pas là, néanmoins. Quatre algorithmes ont déjà été promus à la standardisation (KYBER, DILITHIUM, FALCON, et SPHINCS+) à l’issue du troisième tour de la compétition, mais celle-ci continue et d‘autres algorithmes sont toujours en lice pour un quatrième tour.

L’un de ces algorithmes est SIKE (Supersingular Isogeny Key Encapsulation). Il est basé sur SIDH (Supersingular Isogeny Diffie-Hellman key exchange), une variante du protocole Diffie-Hellman. Il a été proposé initialement en 2011 et était globalement bien considéré.

Jusqu’à ce weekend.

Deux cryptanalystes de l’Université Catholique (néerlandophone) de Louvain , Wouter Castryck et Thomas Decru, viennent en effet de publier une attaque dévastatrice (le lien ci-dessus). Une attaque totalement praticable, qui permet, avec un seul cœur de processeur même pas quantique, d’obtenir la clef privée d’une des parties communiquantes en l’espace de quelques heures.

SIKE est donc aujourd’hui complètement cassé (et Castryck et Decru sont a priori éligibles à recevoir le prix de $50 000 offert par Microsoft). Il n’est pas encore clair si l’algorithme plus général SIDH peut toujours être sauvé.

Bref, qu'es-ce que tu utilise toi ?

Un bidouillage perso dont je devrais probablement avoir honte.

Essentiellement basé sur un Makefile, beaucoup de macros m4,¹ et des scripts divers.

La plupart des pages sont écrites directement en HTML, avec les macros m4 pour insérer les boilerplates communs à toutes les pages et automatiser quelques trucs (genre une macro DOWNLOAD(file.tar.gz) qui se développe en

<a href="file.tar.gz">file.tar.gz</a> (application/gzip, 170K, <a href="file.tar.gz.asc">signature</a>)

).

Quelques pages sont générés à partir d’autres sources que du HTML m4-ifié :

• des fichiers texte en Markdown ou en reStructuredText ;
• des documents DocBook ;
• des carnets Jupyter.

La possibilité d’utiliser plusieurs formats sources indifféremment (HTML, Markdown, RST, DocBook, etc.) est une des principales raisons qui m’ont fait commettre ce bidouillage. Je n’ai pas re-vérifié depuis, mais à l’époque où j’ai commencé (il y a plus de dix ans) je n’avais pas trouvé de générateur de site statique qui permette ça, chacun ne supportait qu’un seul format source, sans mécanisme pour injecter des pages générées différemment.

---

¹ Le manuel de m4 contient l’avertissement suivant :

Some people find m4 to be fairly addictive. They first use m4 for simple problems, then take bigger and bigger challenges, learning how to write complex sets of m4 macros along the way. Once really addicted, users pursue writing of sophisticated m4 applications even to solve simple problems, devoting more time debugging their m4 scripts than doing real work. Beware that m4 may be dangerous for the health of compulsive programmers.

J’aurais probablement dû le prendre plus au sérieux. Hélas, c’est trop tard pour moi désormais. Je témoigne pour que d’autres programmeurs ne tombent pas dans le piège. Dites non à m4 !

J’admets que le terme « pénurie » est peut-être trop fort.

Mais si la simple rumeur d’une pénurie (non-vérifiée dans les faits, limitée à quelque chose de « juste un peu plus chiant ») suffit à provoquer des comportements comme ceux qu’on a observés (rués sur les étalages, vols à main armée, des toilettes publiques dans lesquels on enchaîne les rouleaux de PQ aux dispenseurs…), j’ai du mal à voir en quoi il n’y aurait pas des leçons à tirer sur le comportement des populations face à une pénurie réelle.

En tout cas il y a certainement des gens qui y voient plus que des anecdotes rigolotes, si j’en juge par les papiers qui ont été publiés sur la question, comme Garbe et al., 2020, Kirk et al., 2020, Micalizzi et al., 2021, David et al., 2021, Labad et al., 2021, …

Il y'a t-il vraiment eu une pénurie?

L’impact a certainement été variable d’une région à l’autre, mais par endroit il y a bien eu pénurie, oui. Par chez moi les étalages sont restés vides une bonne semaine, et après ça le rationnement (pas plus d’un paquet de 4 rouleaux par personne à chaque visite dans le magasin) a duré au moins un mois.

Après on ne sait toujours pas, pourquoi le PQ?

Bah attends, tu imagines, si tu te retrouves à devoir te torcher le cul avec une serviette ou un gant de toilette non-jetable, que tu vas devoir ensuite laver pour enlever la merde et pouvoir la ré-utiliser (la serviette, pas la merde) ?

Non non non, j’ai un cul-cul délicat moi, si je ne l’essuie pas avec du Moltonel® triple-épaisseur après ça me gratte. Désolé pour les autres mais là je n’ai pas le choix, il faut que je fasse des stocks maintenant avant qu’il n’y en ait plus, avant que ces abrutis de panic-buyers aient tout emporté.

Déjà ce serait bien de ne pas confondre une partie de la population avec toute la population.

Je ne confonds pas. Mais ce serait bien aussi de ne pas oublier que ce que fait une partie de la population peut avoir un effet sur toute la population.

En l’espèce, c’est bien la partie de la population qui a paniqué et s’est mise à acheter du PQ en masse qui a provoqué la pénurie pour toute la population qui n’avait pas paniqué.

en cas de catastrophe la foule est très solidaire en général

En cas de catastrophe où le danger pour la vie humaine (la sienne et celles des congénères) est évident et immédiat, comme une inondation, un incendie, un tremblement de terre, ou une invasion armée, je veux bien le croire.

Face à un danger plus latent, moins évident, où ce qui serait menacée n’est pas tant la vie humaine en elle-même que notre qualité de vie, j’ai un gros doute.