uso a écrit 306 commentaires

À part que personne n'utilise Rust comparer à JS, il fait quoi cargo pour se protéger contre ce genre d'attaque ?

Bon, j'ai 3 jours de retard, désolé.

Ceci dit, c'est une vraie question que je me pose.

y'a aussi un parle qui aurait du être remplacé par parlé je pense dans ton texte.

Oui, ça je l'ai rajouté à la toute fin, au moment de ma dernière relecture…
Et donc bah, j'ai fauté XD

Je dis que emscriptem a causé un conflit avec npm, par contre, je ne précise pas, que emscriptem, n'est pas une dépendance de v86, c'est moi qui l'avais installé pour compiler du C en wasm.
Donc normalement, v86 ne devrait pas poser de problèmes à la compilation.

Mais bon, j'ai passé beaucoup de temps sur ce bug à la con, donc j'en ai parlé.

Bien structuré,
Merci,

J'ai juste une remarque sur la forme tes verbes du premier groupe sont souvent mal écrit

Oui, je connais la règle.

Bon là, j'ai compté sur languageTool pour me dire mes erreurs, bah ça n'a pas suffi -_-'.

Est-ce que mylib est disponible si je change de distributions ?
Est-ce que mylib est disponible sous MSYS2,macos ?
Est-ce qu'elle est disponible en wasm ?

Si-non, comment je l'inclus dans mon projet ? je la build moi-même ?
Est-ce que j'ai vraiment besoins de mylib ?

Il y a quand même un petit avantage a avoir une lib qui fait beaucoup plutot que plusieurs petites libs qui font des petites choses : la confiance. Il est plus facile de faire confiance à une lib qui est maintenu par une équipe identifiée, même si cette lib fait plein de choses, que de faire confiance à un tas de petites libs éparpillées non ?

Entièrement d'accord avec ça.
Ce que je voulais dire, c'est que les avantages des petites libs, n'ont pas d'avantages pour se défendre des supply chain attaques. (en tout cas dans leur état actuel sur cargo)

C'est là ou moi (et d'autres) ne sommes pas d'accord. Dans l'absolu Rust n'est pas plus vulnérables au supply chain attack que n'importe quelle autre langage. LA différence avec C c'est que Rust est plus ancien, et qu'on a pas encore un ecosysteme de libs matures permettant de faire aussi bien que C en terme d'attaque par supply chain. C'est de mon point de vue la seule différence aujourd'hui (mais je peux me tromper).

Je suis d'accord, je parle de l'écosystème actuel de Rust, en soie le langage, n'est pas vraiment coupable, cargo peu être plus.

Cargo ne pousse absolument pas à se défendre contre les supply chaines attaques, rajouter des dépendances sur cargo, c'est magique, et c'est tellement magique, que si l'on rajoute une dépendance, qui a en dépendances une lib que l'on a déjà, mais a une version différente, tout va marcher, sans rien dire, on aura la lib présente deux fois.

suro-rs c'était poser la question du nombre de dépendances et ont essayé de réduire ce qui n'était pas nécessaire, par contre, ça a été un gros travaille de leur côté et Cargo ne pousse pas à le faire par défaut.

Ce défaut est particulièrement questionnable, car même si ce n'est pas fait volontairement, make C pousse à être conservateur sur ces dépendances, il le fait du fait que make est un outil pourrit pour les gérer.

Une manière de voir Rust, et son système de borrow, pourraient être de voir Rust comme un outil pourrit pour manipuler ces pointers, qui met des bâtons dans les roues des Dev quand ils veulent faire de la manipulation de pointeur.

Toute l'idée de Rust est d'avoir un comportement par défaut qui pousse le dev à se questionner sur ce qu'il fait de sa mémoire, et ne pas chercher à toujours dire "ok ça va marcher".
Pour cargo, c'est l'exact opposé, on cherche à avoir un outil qui dit juste "oui" au dev.
Make bizarrement lui quand tu rajoutes une dépendance, tu forces à te poser la question du besoin de cette dépendance. Même si contrairement à Rust, c'est un effet de bord de son manque de fonctionnalités.

Je développe moi aussi beaucoup de C++, mais il faut arrêter d'essayer de présenter les inconvénients du langage (pas memory safe, pas de système de build standardisé, pas d'outil de gestion des dépendances, par de règle de formattage et de nommage standardisées) comme des avantages.

Peu être parce qu'une avancée n'a pas forcément à être binaire.

Il y a beaucoup, d'avantage à cargo, déjà les lib dynamique, ce n'était pas faisable dans le cas de Rust, demander aux distributions de packager les lib pour un nouveau langage, ça n'est pas faisable, et cargo permet à n'importe qui de créer ça lib, et qu'elle soit facilement utilisable par tout le monde ce qui est un avantage énorme.
Cargo permet de gérer facilement les versions des lib utilisé, quitte à avoir deux fois la même lib à des versions différentes, ce qui pour développer et packager son programme, facilite énormément la chose.

Maintenant dans tous les avantages de cargo que j'ai cité, lesquels à quelques choses à voir avec la choucroute que sont les attaques par supply chaines ? aucun.

Dans le fait qu'une grosse lib, a plus de chances d'avoir des bugs que plusieurs petites lib, et est plus chiant à maintenir, est-ce que ça un rapport avec les attaques par supply-chaines ? toujours pas. (Différents types de vulnérabilité ne sont pas applicables pour les mêmes applications)

Sur une échelle du nombre de dépendances moyenne qui va de C a NPM en passant par pip, au milieu, Rust est quelque part entre pip et NPM.

Et voir cargo et rust, comme quelques d'autre que juste "bien/pas bien",
Ça permet de passer du débat stérile de "30% D'ERREUR MEMOIRE", à quel programme tu es en trains de codée, quel sont les avantages de rust dans un contexte particulier.

Si tu fais un serveur web, alors tu vas surement avoir assez de complexité pour que le nombre de dépendances pose moins de risque que les bénéfices de Rust.

Si tu recodes sudo, là aussi, je suppose qu'éviter les erreurs mémoire reste globalement une bonne chose. (Même si la bonne réponse pour de la sécu reste doas, pas sudo-rs)

Si tu recodes coreutils, qui globalement n'est pas fait pour être utilisé en réseaux, et où la majorité des failles mémoire aussi graves soit elles seront difficilement exploitables, recoder en Rust pour de la sécurité, reste questionnable.
Et si on assume que Rust est plus vulnérable au supply-chain attaque, alors ça reste plutôt négatif en terme d'impact sécuritaire.

Car c'est beau aussi la théorie mais il faut constater en pratique, les soucis de mémoire en C ce n'est pas juste de la théorie, c'est ce qu'on mesure en vrai malgré l'évolution des bonnes pratiques, de l'outillage, etc.

Si pour toi la pratique, c'est de regarder le nombre de failles de sécurité, sans se demander quel point ces programmes en questions sont utilisé, et à quels points il y a un enjeu a trouver des failles de sécurité dans les dits programme.

Dans ce cas, je rentre dans ton jeu :
Seul Open BSD est sécure.

Mais l'écosystème de C et C++ ce sont aussi des milliers de projets différents avec encore plus de développeurs derrière qu'on ne connaît pas.

Oui, mais concrètement, tu prends SDL, glib, glibc, openssl.

T'a le gros des dépendances utilisé, par la plupart des projets C.

Tu peux rajouter des lib métier comme FFMpeg, json-c ou 2/3 autres.
Mais tu dépasses rarement la 10éne de libs.

En C t'a souvent des libs à tout faire, et rien que SDL, t'a des htable, des threads, une gestion du filesystem.
glibc, ta queue.h de BSD, hsearch_r pour les htable et regex.h.

Ça fait, que tu te retrouves avec des projets comme FAudio qui ne se base que sur SDL, et même pas la libc (même si indirectement si).

En Rust pour avoir l'intégralité des fonctionnalités de SDL, tu vas avec 2/3 libs pour chaque élèvement.

Si tu considères que chaque libs maintenues pas une personne différente est un vecteur d'attaque pour des supply-chaines attaques, Rust est juste plus vulnérable.

Bref, des attaques par supply chain tu peux en avoir partout dans ces écosystèmes techniquement, le C n'apporte aucune garantie de ce côté.

Bof, c'est comme dire que Rust n'apporte pas de garantie sur la gestion de mémoire, car tu peu faire que du code unsafe.
Cargo pousse à utiliser beaucoup de lib, make/cmake pousse à rester conservateur sur le nombre de lib utilisé, quitte à recoder des choses que tu pourrais trouver en libs.
Ça rajoute des chances de rajouter ces bugs, mais enlevés des chances de tomber sur une lib corrompue.

Et les lib dynamique sont une garantie que si une lib casse, on n'a pas besoins de rebuild ton binaire pour fix ta faille de sécu.

ok, mais l'avantage des lib dynamique, ce n'est pas d'éviter les faille de sécurité au moment du build, c'est de les éviter après, quand t'a wget ou pacman -S ton binaire, et que tu n'as pas fait gaffe que dans les lib statique utilisé, t'en a une de cassée.
Avec une lib dynamique, bah une mise à jour de la lib va réparer le problème, avec une lib statique, il va falloir penser à mettre à jour tous tes binaires impactés. (et si c'est un package AUR, bah, il faut espérer qu'il y a eu une MAJ)

Et puis quand ta distribution ne package pas le logiciel dont tu as besoin, en C ou C++, tu te retrouves avec… ben rien du tout pour faire le suivi, il faut gérer ça soi-même. Et de mon expérience, ça arrive relativement souvent.

C'est vrai, mais c'est aussi la raison pour lesquels les projets C/C++ sont souvent plus conservateurs sur le nombre de libs, si t'est pas sûr que ta lib est distribué de partout, bah, tu vas devoir la build toi-même, et généralement, tu préfères éviter ça.

Dalleur quand on regarde le CV de Alyssa: https://rosenzweig.io/resume-en.pdf

On voit qu'elle a travaillé sur Apple pour valve.
Si on regarde ces contributions, elle a aussi beaucoup travaillé sur FEX.
À se demander si valve n'a pas utilisé Asahi comme machine de tests pour leur casque VR.
parce que je ne pense pas que les utilisateurs steam Asahi soit assez nombreux pour justifier du temps de dev dessus, par contre, il y a assez d'utilisateurs pour avoir un certain nombre de retours utilisateurs sur FEX, et améliorer leur couche de compatibilité avant que le casque ne sorte.

S'ils ont fait ça, je trouve ça très intelligent.

Et un vieux projet en C, avec make, utilise des lib dynamique, donc mise-a-jour par les mainteneurs de ta distribution Linux, ce qui les rend très différents de PHP et ces lib statique.

Ça reste un problème avec les single-header librairies, mais vu qu'il faut les gérer soi-même, bah t'en utilise juste moins que des lib que tu rajoutes dans ton yaml, et qui te tire 15 dépendances, et reste une pratique moins courent que pkg-config --libs

Ce que tu ne comprends pas dans le propos, c'est que si tu prends un programme C donné et que tu le convertis en Rust

C'est absolument faux, tu convertis du code C en Rust, tu te retrouves avec du code Rust 100% unsafe.

Les pratique de codage de Rust et C sont différents, donc les algorithmes utilisés en C ne sont pas forcément simples à convertir en Rust safe.

Tu ne convertis pas un programme C en Rust, tu le recodes, avec des pratiques de codages différentes, et des dépendances en plus, beaucoup.

GNU coreutils, c'est principalement deux dépendances : glibc et GNUlib.
uutils, c'est ça : https://deps.rs/repo/github/uutils/coreutils
Si tu additionnes uu_core et coreutils, t'en a 14.
Et si tu prends uu_touch, tu en rajoutes une qui a elle-même 10 dépendances.

Sauf que les attaques par supply chain sont malgré tout bien plus rares et concernent aussi les applications C et C++.

Sauf que les attaques mémoire concernent aussi Rust…

Si les attaques par supply chaine sont rares, c'est aussi peu être, car C se repose sur moins de dépendances que du Rust ou JS.
XZ, ça a été un gros travaille d'ingénierie sociale pour choisir l'une des rares libs C utilisée un peu partout, et peu maintenues.
En Rust des lib comme XZ utilisé un peu partout, tu n'en as pas 10 comme en C, mais plus 300.

Aussi, entre une erreur mémoire dans un programme comme ls, qui de toutes manières demande d'avoir accès à ton ordi en physique pour être exploité, et un bout de code ajouté par une dépendance derrière ton dos, qui va te modifier sshd_config à l'init de ls si tu es en root.
Bah, je prends 30% de chances d'erreur mémoire à 0.5% de chances de supply chaine attaque.

Ma comparaison avec npm, c'est car cargo ressemble plus à npm que make, donc ma remarque, c'est que cargo ajoute aussi une surface d'attaque que make n'a pas.

Le nombre de vulnérabilités n'est pas forcément une valeur intéressante parce que la base d'utilisation de programme en C, et les enjeux a introduire des portes dérobées sont plus grandes que ceux pour leur équivalent en Rust.
En gros si libc/coreutils/curl devraient se voir remplacer par du rust, on va surement enlevé 29% de faille de sécurités lié à la mémoire, par contre le pourcentage de CVE lier à des attaque par supply chain, il va augmenter, mais vu que des coreutils qui utilise cargos pour build, ça reste quelques chose de marginal aujourd'hui, on ne peu pas prédire l'impact que ça auras.

Une lib dynamique packager par APT donc un mainteneur de ta distro (donc fix sur un apt update), c'est la même chose qu'une lib static tirer par une autre dépendance que tu as utilisé, et maintenue par 1/4 de personnes qui sait même pas que ça lib est utilisé sur ta distro ?

Parce que en Rust la majorité de tes dépendances sont statiques, et tu peux avoir plusieurs fois la même, mais a des versions diférents dans le même projet. (ce qui arrive à peu près jamais en C).
Et si ta dépendance casse, bah, tu gardes la faille tant que ton binaire n'a pas étais packager.

Aussi en C t'est en général beaucoup plus minimaliste qu'en rust sur les dépendances utilisées.
Car cargo est meilleur que make pour récupérer tes lib et faire en sorte que ça marche, sans rebuild la lib toi même si elle n'est pas packager partout.
Donc cargo est meilleur pour te prendre pleins de dépendances que tu sais même pas que tu les utilises, et qui sont maintenus par personnes.

C'est quand même 33% des failles de sécurité rapportées. Ce n'est pas un détail et je ne crois pas qu'une classe d'erreur passe devant en fait.

En même temps, la majorité de la base de ton Linux est en C/C++.

Vu que C/C++ son assez vulnérables aux erreurs mémoire, bah c'est la que les gents cherches les vulnérabilités.

Tu prends un autre langage beaucoup utiliser comme JavaScript, on a peu d'erreurs mémoire, mais une armée d'attaque par chaines de dépendances.

Rust (comme open BSD) restent pour l'instant assez niches (on n'a pas des curl/coreutils/libc utilisé partout en rust), Rust se retrouverait à la place de C, il y aurait surement moins d'erreurs mémoire, mais c'est aussi possible qu'il y ait plus d'erreurs par supply chaines.

Parce que cargo ressemble beaucoup plus à npm qu'à make.

Aussi, Rust est tellement vendu comme langage sécurisé par Default, que les développeurs preuves faire moins attentions aux failles de sécurité, en se cachant derrière ce faux sentiment de sécurité qu'offre le langage.

https://www.gamingonlinux.com/2025/11/valve-reveal-the-new-steam-frame-steam-controller-and-steam-machine-with-steamos/

2026, l'année du desktop sous ARM/GNU/Arch Linux ?

Est-ce que la réforme de l'orthographe de 1990, c'est vraiment nos ognons ?

Pas vraiment d'accord, Hans Reiser aurait pu coder/maintenir sont filisystem depuis sa cellule, le monde de Linux serait surement mieux.

Après, on parle de quoi ? garder des personnes problématiques en position dominante ou juste dans un projet ?
Problématique lier à la position exercé ou non ?

Parce que sinon il y a 2/3 jours, je suis tombé sur ce projet https://git.coom.tech/drummyfish/raycastlib qui a l'air vachement sympas à utiliser.

Par contre 5mn à lire le site de l'auteur, et on peut voir à quel point il est problématique, mais ces lib single file, pour faire du jeu vidéo, ont l'air vraiment qualitatif.

Cela me semble un peu manichéen.

C'est quoi qui semble manichéen ?

De mettre en avant un conflit d'intérêt ?

Ou de faire un site pour dire que brave, c'est le seul gentil browser, et tout les autres sont méchants ?

Ton pote vient d'installer Windows Vista, et te monte tous les nouveaux effets graphiques, rien à foutre, toi t'a gnome 2 avec compiz, les fenêtres qui brulent, et le desktop cube !

Mais en général, "va voir dans le code", c'est pénible quand j'essaie d'utiliser le code de quelqu'un d'autre, qu'il n'y a aucune info sur ce que fait chaque fichier et dossier à part son nom, et que c'est écrit dans un langage de programmation que je ne connaìt pas.

Il n'y a pas longtemps, j'ai essayé d'intégrer kuroko a un projet perso, en tant que moteur de scripting.

Et si la doc explique comment appeler kuroko, pour intégrer tes struct C dans kuroko, c'est du gros RTFS, et peu être que ça aurais été plus simple avec une doc.

Mais maintenant que j'ai réussi à tout faire marcher comme je veux, est-ce qu'il n'est pas normal que mon syndrome de Stockholm, me force à dire que la documentation ne sert à rien, et à regarder avec mépris ce qui la demande ?
de la même manière que si on aime le fromage, on méprisse ce qui mange du kiri.

Et sinon pour revenir sur le sujet principal du lien, la pizza, la pizza historiquement, c'est le plat du pauvre, qui consiste à mettre les restes sur une pâte à pains, hors l'ananas, c'est un truc que l'on trouve pour pas cher dans un supermarché, ou t'a facilement une boite d'ananas en jus qui reste chez toi.
Alors que d'autre ingrédient comme la burrata ou le jambon à la truffe, eux, ne sont pas censés être dans la catégorie plat du pauvre.
Donc la truffe et la burrata, sont des trahisons bien plus grave que l'ananas à l'esprit de la pizza.

Non, la documentation, c'est chiant, ça ne sert à rien si tu peux aller dans le code directement.
C'est un peu plus dur en bouche que la documentation, mais on défend vraiment le babybel face à un bon vieux maroilles ici ?
Alors que l'ananas sur la pizza, c'est le petit plus qui est corolaire au noyau, mais pas directement à l'intérieur du fruit.

Oui et non, quand tu fais un nouveau projet, tu passes ton temps à le casser avant d'avoir une API stable.

La personne derrière le code, a clairement l'air d'être dans l'idée d'amélioré quitte à casser, ce qui ne va forcément pas plaire aux mainteneurs de xorg.

Il y a Brodie Robertson qui a fait une vidéo sur le fork: https://www.youtube.com/watch?v=iCU4W5Ab33c

Je l'ai trouvé pas mal, il explique que le mec qui a fork est le plus gros contributeur de x11 de 2024, donc il a une certaine experiance avec X11.

Par contre, beaucoup de ses contributions ne sont pas forcément appréciées, car il a tendance à casser les choses, dont l'ABI.

À part la politique, il y avait une grosse friction entre la personne qui a fait le fork, et les gents derrière X11, c'est que la personne derrière le fork veut améliore X11, quitte à casser des choses, alors que la majorité des dev et mainteneur de X11, préfère essayer de garder un code stable.