• # « un vilain unwrap en Rust »

    Posté par  . Évalué à 7 (+7/-0).

    
 plus une requĂȘte SQL erronĂ©e et des dĂ©ploiements en prod sans tests (suffisants).

    
 et probablement quelques autres détails plus mineurs, vu que la liste de remédiation inclut des points non discutés.

    • [^] # Re: « un vilain unwrap en Rust »

      Posté par  . Évalué à 5 (+3/-0).

      La meilleure remĂ©diation est de na pas ĂȘtre entiĂšrement dĂ©pendant de ce type de service (CLoudflare).

    • [^] # Re: « un vilain unwrap en Rust »

      Posté par  (site web personnel) . Évalué à 7 (+5/-0). DerniĂšre modification le 19 novembre 2025 Ă  14:07.

      Pour moi, c’est une partie de l’explication seulement. C’est l’explication technique du crash.

      Mais le vrai “bug”, Ă  mon avis, c’est qu’une telle erreur de programmation ne devrait pas avoir une telle consĂ©quence. unwrap est au cƓur de cet incident, mais n’est pas le cƓur du problĂšme.

      Pour moi, le problĂšme est organisationnel ou architectural en premier lieu.

      D’abord, on pourrait imaginer des rĂšgles de programmations qui interdisent les unwrap, avec une vĂ©rification statique du code qui impose leur application. On peut imaginer qu’ils vont ajouter ce genre de vĂ©rification pour ce type d’erreur suite Ă  l’incident. Ça, c’est une solution technique pour tuer une telle erreur dans l’Ɠuf, mais ça ne fait pas tout.

      On pourrait imaginer une revue attentive obligatoire pour augmenter les chances d’attraper plus d’erreurs, dont celles qui ne peuvent pas ĂȘtre remarquĂ©es par la vĂ©rification statique ou les tests automatiques. C’est une des solutions organisationnelles possibles.

      Ça ne fait toujours pas tout, d’ailleurs j’imagine qu’ils ont dĂ©jĂ  ça, or, l’erreur est passĂ©e quand-mĂȘme. Dans tous les cas, il y aura toujours des erreurs de programmations qui passeront, tant que le code n’est pas vĂ©rifiĂ© formellement et exhaustivement (ce qui ne serait probablement pas rĂ©aliste, si c’est mĂȘme possible).

      Donc lĂ , l’architecture de Cloudflare devrait ĂȘtre conçue pour ĂȘtre tolĂ©rante Ă  ce genre de bugs, avec un dĂ©ploiement progressif des Ă©volutions du code ou des configurations. On peut supposer qu’il y a de la redondance chez Cloudflare, et qu’il serait possible de dĂ©ployer la plupart des changements sur certains nƓuds, et les choses continuent Ă  fonctionner quand ils tombent en panne. Et on stoppe le dĂ©ploiement si on constate des crashes Ă  ce niveau.

      Et toutes les solutions architecturales et organisationnelles pour limiter les erreurs humaines et sinon leurs conséquences.

      C’est Ă©videmment plus facile Ă  dire qu’à faire. D’un autre cĂŽtĂ©, c’est spĂ©cifiquement le cƓur de mĂ©tier de Cloudflare. Et ce qui est un peu prĂ©occupant, c’est qu’il n’est fait mention que des solutions techniques dans leur section Remediation and follow-up steps. C’est bien d’éviter le genre d’erreur qu’on vient de rencontrer Ă  l’avenir, mais aucune amĂ©lioration du processus de dĂ©ploiement n’est mentionnĂ©e, ou autre amĂ©lioration visant Ă  gĂ©rer les erreurs de programmations ou autres erreurs humaines qui passent inĂ©vitablement les filtres. On peut espĂ©rer que c’est juste qu’ils ne communiquent pas lĂ -dessus pour une raison qui m’échappe.

      • [^] # Re: « un vilain unwrap en Rust »

        Posté par  . Évalué à 4 (+1/-0).

        Au delà de ça ça pose la question de l'environnement de test.

        Pour une infra critique comme celle lĂ  on aurait pu penser que l'infra de test soit un minimum complĂšte par rapport Ă  la prod, vu que c'est critique. Je me trompe probablement mais j'ai l'impression qu'un tel bug aurait pu ĂȘtre dĂ©tectĂ© dans les tests si les volumes de donnĂ©es de test et les serveurs simulĂ©s sont dimensionnĂ©s de maniĂšre crĂ©dible par rapport Ă  la prod ?

        • [^] # Re: « un vilain unwrap en Rust »

          Posté par  (site web personnel) . Évalué à 3 (+1/-0). DerniĂšre modification le 19 novembre 2025 Ă  14:22.

          Oui, en effet. L'environnement de test est une solution technique et organisationnelle qu'on imagine déjà en place pour attraper ce genre de chose.

          • [^] # Re: « un vilain unwrap en Rust »

            Posté par  . Évalué à 9 (+7/-0).

            D'un autre cĂŽtĂ©, vu leur taille, est-e qu'il est possible d'avoir un environnement de test qui simule tous les cas possibles et imaginables rencontrĂ©s sur un environnement de prod ? Je pense que ça doit ĂȘtre bien diffcicile. Et mĂȘme si c'est faisable, il faut penser justement Ă  tous ces cas possible et les simuler.

            Autrement dit, des tests c'est bien, mais les tests ne sont pas la garantie absolue de ne jamais rencontrer de bugs. On réduit juste la probabilité de les rencontrer.

        • [^] # Re: « un vilain unwrap en Rust »

          Posté par  . Évalué à 8 (+6/-0). DerniĂšre modification le 19 novembre 2025 Ă  14:51.

          [
] les volumes de données de test et les serveurs simulés sont dimensionnés de maniÚre crédible par rapport à la prod

          Est-ce vraiment possible chez Cloudflare ?

          Edit : pour le dire autrement, comment simuler 20% du trafic mondial de maniÚre crédible ?

      • [^] # Re: « un vilain unwrap en Rust »

        Posté par  (site web personnel, Mastodon) . Évalué à 1 (+1/-2).

        Cloudflare, encore un autre gĂ©ant aux pieds d’argile, comme Crowdsec


        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # ~~Prem's~~

    Posté par  . Évalué à 4 (+6/-4). DerniĂšre modification le 19 novembre 2025 Ă  13:00.

    J'Ă©tais venu Ă©crire un journal avec le mĂȘme lien et le titre

    Plot twist : le plantage de Cloudflare est de la faute de Rust !

    Mais tu m'as dĂ©passĂ© avec ta version bien moins trollifĂšre. Dommage, je voulais voir les rustacĂ©es sortir les pinces pour enfoncer des portes ouvertes ("Non mais en fait Rust ne peut pas t'empĂȘcher de coder n'importe comment et en plus unwrap ne devrais pas arriver en prod, comme le dit le crĂ©ateur de LinuxFR.")

    • [^] # Re: ~~Prem's~~

      Posté par  (site web personnel, Mastodon) . Évalué à 0 (+4/-6).

      Et au vu des commentaires d’un prĂ©cĂ©dent journal, les cRUSTacĂ©s vont t’expliquer que malgrĂ© les bogues qu’ils crĂ©ent ils sont automagiquement plus sĂ»r parce-que c’est comme ça.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: ~~Prem's~~

        Posté par  . Évalué à 3 (+1/-0). DerniĂšre modification le 21 novembre 2025 Ă  17:31.

        les cRUSTacĂ©s vont t’expliquer que malgrĂ© les bogues qu’ils crĂ©ent ils sont automagiquement plus sĂ»r parce-que c’est comme ça

        Et pourtant, ils le sont (plus sûrs) !

        LĂ , c'est un exemple typique de ce que j'expliquais quand je disais que les programmeurs faisaient de l'axiomatique sans le savoir (API, c'est Axiomatique Pour Informaticien).

        Le type Result <T,E> est l'équivalent logique d'une disjonction : on a un résultat de type T ou une erreur de type E. L'axiomatique minimale et complÚte pour ce type est celle-ci :

        val ok : 't -> ('t,'e) Result
val error : 'e -> ('t, 'e) Result
val fold : ('ok -> 'res) -> ('err -> 'res) -> ('ok, 'err) Result -> 'res

        J'ai utilisé la syntaxe OCaml que je maßtrise mieux. Mais l'idée est qu'avec seulement ces 3 fonctions on peut implémenter toute l'API du type Result. Par exemple, le trait unwrap incriminé s'implémente ainsi :

        unwrap self = fold id panic self

        oĂč id est la fonction identitĂ© qui renvoie son argument et panic c'est ce qui est arrivĂ© en cas d'erreur.

        Que ces trois fonctions suffisent, on le doit à Gödel (théorÚme de complétude) et Gentzen (déduction naturelle). Le type de ces trois fonctions correspondent aux rÚgles de la déduction naturelle pour la disjonction : les deux premiÚres sont les rÚgles d'introduction de la disjonction (comment produire un Result) et la troisiÚme à la rÚgle d'élimination (comment consommer un Result).

        Ce qu'il y a, c'est que unwrap, qui de fait appel panic, ne doit ĂȘtre utiliser que sur des erreurs irrĂ©cupĂ©rables ! Il est peu probable que ce soit le cas ici, et unwrap n'aurait jamais du se trouver dans le code. C'est un bug de gestion d'erreurs, comme un exception non rattrapĂ©e mais qui aurait du l'ĂȘtre.

        Un programmeur C aurait pu faire de mĂȘme :

        if (ptr == NULL) { exit };
/* on peut déréférencer le ponteur dans la suite */

        mais lĂ  oĂč unwrap apporte tout de mĂȘme une sĂ©curitĂ© mĂ©moire, c'est qu'il ne dĂ©rĂ©fĂ©rencera jamais un pointeur NULL, lĂ  oĂč un programmeur C peut oublier d'Ă©crire le test. La fonction fold (rĂšgle d'Ă©limination, rĂšgle d'usage) exige un traitement pour le cas des erreurs, traitement qui dans le cas de unwrap est un panic. Cette exigence n'existe ni en C, ni en C++. ;-)

        Le cas des pointeurs est en fait Ă©quivalent au type Option, qui lui-mĂȘme est Ă©quivalent au type Result oĂč le type E des erreurs est un singleton.

        AprÚs, si tu regardes les rÚgles sur l'absurde sur la page wikipdéia (ce qui se passe ici, il y a une erreur parce que l'entrée est contradictoire avec les conditions dont à besoin la fonction pour avoir un résultat), en réfléchissant un peu tu pourras te convaincre que les rÚgles la concernant correspondent au fonctionnement des exceptions (en particulier le raisonnement par l'absurde qui décharge l'hypothÚse, c'est lever un exception avec sa backtrace : la série de raisonnement qui ont mener à la contradiction).

        Mais pour gérer les exceptions avec le type Result, il faut utiliser le ? en Rust. C'est la façon idiomatique d'utiliser ce que les programmeurs fonctionnels appellent le bind :

        bind v f = fold f error v

        Autrement dit on applique le traitement f en cas de succÚs et on fait remonter les erreurs à l'appelant, charge à lui de gérer l'erreur (si possible sans panic).

        Sapere aude ! Aie le courage de te servir de ton propre entendement. VoilĂ  la devise des LumiĂšres.

        • [^] # Re: ~~Prem's~~

          Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

          Justement, tu prĂ©cises « sĂ©curitĂ© mĂ©moire » ; ce n’est pas sĂ©curitĂ© tout court
 (ou toute la sĂ©curitĂ©) Et l’usage apparemment irraisonnĂ©e de unwrap ici a conduit au crash, malgrĂ© les crĂ©dos.

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: ~~Prem's~~

            Posté par  . Évalué à 2 (+0/-0).

            Justement, tu précises « sécurité mémoire »

            Et c'est ce que prĂ©tend apporter, Ă  raison, le langage Rust. Il n'a jamais prĂ©tendu ĂȘtre la panacĂ©e contre tous les types de bugs. L'erreur du unwrap peut se reproduire dans les autres langages, mais leurs bugs mĂ©moires n'ont pas d'Ă©quivalents en Rust.

            Ceux qui cherchent Ă  troller Rust inventent un adversaire imaginaire : ils combattent un homme de paille.

            Sapere aude ! Aie le courage de te servir de ton propre entendement. VoilĂ  la devise des LumiĂšres.

      • [^] # Re: ~~Prem's~~

        Posté par  . Évalué à 2 (+0/-0). DerniĂšre modification le 21 novembre 2025 Ă  17:45.

        J'ai oublié, panic c'est la rÚgle d'élimination de l'absurde : le programmeur est tombé sur une contradiction, et au lieu de chercher à la comprendre, pour proposer une solution, il a paniqué. ;-)

        Pour pouvoir valider le type de unwrap, il faut que panic produise le type T que l'on a en cas de succÚs, quelque soit le type E des erreurs. Le type de panic produit le type qu'il veut en sortie quelque soit son type d'entrée, c'est à dire l'élimination de l'absurde ou le principe ex falso quodlibet (du faux, fait ce qu'il te plait).

        Sapere aude ! Aie le courage de te servir de ton propre entendement. VoilĂ  la devise des LumiĂšres.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent Ă  celles et ceux qui les ont postĂ©s. Nous n’en sommes pas responsables.