Un grand sage a dit un jour : « le fait qu'il y ait un bug dans sudo ne garantit pas qu'il n'y ait pas de bug dans sudo-rs. »
Et bien il avait raison et on a pas attendu longtemps pour en trouver, des bugs. Ils sont gratinés
Two security issues were discovered in sudo-rs, a Rust-based implemention of sudo (and su), which could result in the local disclosure of partially typed passwords or an authentication bypass in some targetpw/rootpw
configurations.
Bref, memory-safe ne veut pas dire bug-free et rewrite everything in Rust ne fait pas repousser les cheveux ni revenir l'être aimé.
# Petite question à ceux qui "baignent" encore dans le C
Posté par totof2000 . Évalué à 8 (+6/-0).
Est-ce qu'il serait possiblede faire évoluer le C pour qu'il integre un système de contrôle de mémoire "à la rust", tout en gardant une certaine compatibilité avec le code actuellement écrit ? Est-ce qu'il y a des discussions/recherches/évolutions potentielles dans ce sens ? Est-ce que ça vaudrait le coup ?
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 8 (+6/-0).
Je pratique le C depuis les années 80, et c'est une idée qui refait surface régulièrement. Jusqu'à présent il n'y a pas eu de proposition universelement adoptée.
Oh que oui, un bon gazillion. Une des plus récentes, c'est https://fil-c.org/ qui annonce :
Fil-C is a fanatically compatible memory-safe implementation of C and C++. Lots of software compiles and runs with Fil-C with zero or minimal changes. All memory safety errors are caught as Fil-C panics.
Après, il faut voir ce que ça donne à l'usage…
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par thoasm . Évalué à 3 (+0/-0).
C'est pas vraiment "à la rust", le principe c'est de planter à l'exécution, au prix de moins de perf (et d'un gc dans certains cas, j'ai cru comprendre).
Discussion là dessus sur un site de Rustacés
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par abriotde (site web personnel, Mastodon) . Évalué à 4 (+3/-0).
En fait il existe 1000 choses mais ce ne sont que des patch de patch. Soit on perd énormément en performances (autant faire du Python, ou à minima du Go) soit cela n'apporte pas vraiment la sécurité de Rust (mais vraiment pas) mais une bonne complexité syntaxique.
En fait quand on connait Rust et l'ownership, on comprends très vite que c'est impossible. Autant refaire un langage. C'est comme faire un langage de script façon Python avec C ou même un langage de VM façon Java en C.
S'il n'y avait rien à changer au langage C, cela s'appel pas un nouveau langage mais une amélioration du compilateur. On a vu avec LLVM mais ça n'apporte quelques que erreurs/warnings en plus à la compilations.
Et s'il faut changer quelque chose à C, il faut reprendre le code, autant prendre un nouveau langage.
L'avantage de C, c'est que l'on est proche de la machine et que l'on peut faire tout et n'importe quoi. Pourquoi vouloir lui enlever son avantage si c'est pour devoir jetter le code?
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par serge_sans_paille (site web personnel) . Évalué à 4 (+2/-0).
Il y a des tentatives en cours (basées sur des dialectes):
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par thoasm . Évalué à 7 (+4/-0).
C'est pas une question nouvelle Ce fil reddit d'il y a quelques années l'évoque, je lie une des réponses
Si c'est possible de faire ça, et ça demanderait quand même sans doute des évolution pas neutre dans le langage parce que Rust s'appuie sur le système de type pour faire ça et des indications que le compilateur doit comprendre, et si tu veux garder une compatibilité, ça poserait le même type de problème que la distinction code "safe / unsafe" en rust.
Le code "unsafe" en Rust permet d'utiliser des pointeurs sans restrictions "à la C", mais l'approche de Rust est de limiter au maximum les sections "unsafe" dés le développement initial, pour avoir le maximum de trucs "tout bon" du point de vue sûreté mémoire dés le début. Si tu pars d'une base de code "toute unsafe" pour essayer de la rendre "safe" (en gardant la compatibilité C au max) tu te retrouves, intuitivement, à avoir le même problème que craignent certains mainteneurs du noyau Linux j'ai cru comprendre et à avoir à réécrire les API ou de grosses parties du code existant parce que les restrictions vont se propager dans le code dont il dépend, à la manière de la propagation des "async / await" dans du code qu'on veut rendre asynchrone dans certains langages comme le js. En plus velu parce que ça va rendre impossible l'utilisation de certaines constructions et peut être obliger à des changements d'architectures du code ou du gros refactoring.
Une autre approche serait d'utiliser des analyseurs statiques de code velus qui tentent de démontrer pleins de propriétés et ne pas laisser passer du code qui n'a pas ces propriétés. Mais ça pose sans doute le même type de pb de faire évoluer du code pré-existant vers plus de sûreté avec ce genre de techniques.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5 (+2/-0).
J'ai du mal à voir en quoi c'est une mauvaise chose. Le code Rust obligerait les interfaces à être propres et bien définies, et mettrait alors en évidences les endroits où ce n'est pas le cas et où il y a du code à retravailler.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par thoasm . Évalué à 5 (+2/-0).
Je sais pas si c'est une bonne ou une mauvaise chose mais j'ai l'impression que les mainteneurs n'aiment généralement pas les gros patchs sur du code existant et stable … Et là si ça se propage ça risquerait (je met un point d'interrogation, si ça se trouve c'est pas si pire et mitigeable) dans le pire des cas de se propager un peu partout d'un seul coup. Et ça certains mainteneurs, je pense, n'aiment pas du tout ça.
En tout cas c'est ce que j'avais retenu de l'affaire Christoph Hellwig , en particulier ce post mais à la relecture je suis pas sûr que ce soit spécifiquement dû à la gestion mémoire de Rust et il aurait peut être la même objection pour n'importe quel base de code multilingue.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par thoasm . Évalué à 5 (+2/-0).
Oups trompé dans le premier lien, je voulais lier https://lwn.net/Articles/1006805/ l'article de lwn.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par rewind (Mastodon) . Évalué à 10 (+13/-1).
C'est dingue comment "écrit en Rust" est devenu synonyme de "propre et bien définies". Alors non, on peut avoir des interfaces propres et bien définies sans que ça passe par Rust qui a quand même un paquet de limitations, parfois pas toutes légitimes (sinon unsafe n'existerait pas). Dit autrement, il n'y a qu'une vague implication et certainement pas une équivalence entre les deux propositions.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par thoasm . Évalué à 4 (+1/-0).
Il y aurait probablement du unsafe même si le démonstrateur de correction mémoire était parfait pour gérer tout ce qui est hors périmètre de Rust, le bas niveau avec lequel il interagit non ?
Genre pour interfacer avec une lib C par essence unsafe, un autre langage dont le modèle mémoire est totalement différent et pas modélisé ou pour faire des pilotes avec une mémoire qui n'a pas du tout de concept d'ownership. "Unsafe Rust" liste deux raisons dans son intro
Ça c'est celle que tu cites, le compilateur n'est parfois pas assez malin (et le sera ptete toujours, cf. le problème de l'arrêt) mais ça pourra sans doute à terme gérer quand même bien des cas …
Ça c'est la deuxième, gérer des trucs qui sont par essence pas couvertes par le modèle de Rust aux interfaces. Là l'intérêt de unsafe est de bien marquer les endroits ou c'est le cas et de les minimiser, cacher derrière des interfaces propres. Mais on peut faire sale aussi bien évidemment !
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par rewind (Mastodon) . Évalué à 5 (+4/-2).
Encore une fois, ce n'est pas parce que c'est une lib C qu'elle est forcément unsafe. Si on s'astreint à coder avec des règles strictes (par exemple, celles que le compilateur Rust vérifie), alors la lib C sera safe (pour le périmètre des règles utilisées). La seule chose qu'on peut dire dans le cas de la lib C, c'est que la sûreté n'a pas été vérifiée par le compilateur, mais certainement pas qu'elle est unsage par nature.
Et puis dans le cas de Rust, on parle bien de sage du point de vue de la mémoire, et l'exemple de ces bugs montre qu'il y a tout un tas d'autres manières d'être unsafe.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par thoasm . Évalué à 5 (+2/-0).
Je parlais évidemment de "unsafe" au sens Rust vu que c'était le sujet de discussion. Dans toute la discussion on discutait de comment justement être certain d'avoir les garanties mémoires de Rust éventuellement sans tout réécrire … D'où l'idée de partir sur du code existant éprouvé sur des bugs "métiers" qu'on spécifie pas dans les specs du langage, et se prouver qu'il est bien memory safe pour au moins avoir des garanties là dessus et se concentrer sur le reste. C'est des différentes approches pour faire ca qu'on discute il me semble.
Ça devrait être un minimum, en fait. Oui, on peut faire du sans but de gestion mémoire en asm, ca risque d'être largement plus compliqué de s'en convaincre, de convaincre les autres et d'en convaincre un compilateur.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par jsbjr . Évalué à 8 (+7/-0).
Pour Rust, une librairie en C et forcément unsafe. Parce que le mot clé unsafe est un contrat entre le développeur et le compilateur pour dire que c'est au développeur de vérifier que le morceau de code dans le bloc unsafe respecte certaines des conditions nécessaires pour que compilateur puisse générer un programme qui soit correct.
Ce n'est pas un jugement de qualité du code marqué unsafe.
Ça ne veut pas dire qu'une librairie en C est forcément buggée ou contient des erreurs.
Tant que Rust ne comprends pas le code C et ne peut pas vérifier par lui même que le code et la façon dont il est appelé et correcte, le code C doit forcément être marqué unsafe.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
La différence est entre "on peut avoir des interfaces bien définies" dans un autre langage et Rust oblige à avoir des interfaces bien définies (par exemple pour indiquer qui est propriétaire de la mémoire et responsable de la libération, ou assurer la synchronisation entre threads). Oui bien sûr c'est contraignant et parfois ça empêche de faire des choses qui pourraient très bien |onctionner par ailleurs. De la même façon que le C n'a pas de coroutines (alors que c'est facile en assembleur) ou que le C++ ne permet pas de modifier la vtable d'un objet à la volée pendant l'exécution (alors que c'est tout à fait possible en smalltalk, ou si on implémente des vtables en C à la main). Ce sont bien évidement des choix pour contraindre les choses à fonctionner d'une certaine façon: une exécutioneavec une pile d'appel unique par thread, des possibilités d'optimisation des appels de méthodes, par exemple.
La qaestion oevient donc: en pratique, quelles sont les fonctions du noyau Linux qui ont une interface bien définie (en terme de gestion de la mémoire et des threads), mais une approche "inhabituelle" qui fait que ça ne peut pas s'interfacer avec du Rust?
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par rewind (Mastodon) . Évalué à 2 (+1/-2).
C'est gentil d'expliquer ce qu'est une implication.
Donc, pour toi, il faudrait forcer les interfaces à pouvoir s'interfacer avec Rust pour les considérer comme bien définies ? C'est une variante de Rewrite in Rust. Mais tu vas avoir du mal à convaincre qui que ce soit. Parce que dans le cas des bugs de ce journal qui dénonce, le fait d'avoir des interfaces bien définies n'aurait absolument rien changé.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par thoasm . Évalué à 3 (+0/-0). Dernière modification le 13 novembre 2025 à 08:07.
Je pense plutôt qu'il implique que ce gi'enre d'interface n'est généralement pas une mauvaise pratique de génie logiciel, au contraire, et que des interfaces qui ne les respectent pas pourraient faire lever un sourcil sur un pb potentiel, genre séparation des responsabilités ?
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+7/-0).
Je ne suis pas développeur dans le noyau Linux et si je peux éviter de faire du C, j'en suis très content. Je n'ai donc pas de "il faudrait" à leur donner ou personne à convaincre. Siequelqu'un proposait l'intégrationde code Rust dans un projet auquel je participe (disons: Haiku), ça ferait par contre partie des questions que je vais poser afin de me faire un avis sur la question [il y en aurait plein d'autre, par exemple dans le cas de Haiku ce serait un problème pour le portage motorola 68000 qu'il faudrait officiellement abandonner dans l'état actuel des toolchains Rust). J'ai juste posé une question: quels sont les motifs utilisés dans le code du noyau Linux qui ne se prêteraient pas à un interfaçage avec Rust?
Avec une réponse à cette question, je pourrais apprendre des choses sur les limites de Rust et sur d'autres façons de gérer la mémoire, ou juste redécouvrir des façons de faire auxquelles je n'ai pas pensé. Ou peut-être que ce sema l'occasion de découvrir une interface qui est, en fait, mal définie. Je sais que dans Haiku, on a plein d'endroits où la resposabilité de libérer de la mémoire pointée par un pointeur est implicite et pas documentée, et il faut aller lire le code source pour vérifier, et en plus ce n'est pas forcément cohérent d'un objet à l'autre. Bien sûr c'est un problème qui peut être résolu oe plein de façons: avec du C++ "moderne" et des smart pointers, avec de la documentation, avec des outils d'analyse statique, … mais l'approche de Rust de vérifier ça à la compilation semble quand même être une très bonne idée?
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par David Demelier (site web personnel) . Évalué à 8 (+10/-4).
À un moment donné faut arrêter de considérer la gestion mémoire comme le problème principal des failles de sécurité. Oui c'en est une mais on peut faire des conneries dans tous les langages.
Le C n'évoluera jamais dans le sens de Rust parce que c'est un paradigme entier à revoir. En revanche, les sanitizers et analyse syntaxique aident déjà énormément au développement et le reste est bien sûr d'assurer des tests de non regression massive. N'oublions pas que les serveurs du monde tournent toujours sur un noyau entièrement codé en C, comme quoi c'est possible.
AI is a mental disorder
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par Renault (site web personnel) . Évalué à 8 (+6/-1).
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.
Cela ne résout pas tout mais élimine une bonne partie du problème.
Cela ne veut pas dire qu'on ne peut pas faire mieux. ;)
Ne pas oublier outre les bogues en eux même, limiter ces erreurs c'est aussi une charge mentale et un effort de maintenance à faire.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par thoasm . Évalué à 7 (+4/-0).
Héhé oui, l'argument "bah il y a d'autres bugs alors autant aussi laisser la place pour faire des erreurs de mémoire" (après tout, personne n'en fait …) est peu convaincant de mon point de vue. C'est pas comme si ça posait problème en pratique depuis des lustres, après tout.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 1 (+1/-2).
Je suppose quand même qu'une bonne partie des soucis attribués à une mauvaise gestion de mémoire n'est que la conséquence d'un mauvais choix d'algorithmique, qui est peut-être lui-même la conséquence d'une mauvaise spécification liée à une documentation un peu trop floue.
Le Dave Institute peut-il vérifier ces allégations hypothétiques avec la rigueur qui s'impose ?
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par Renault (site web personnel) . Évalué à 10 (+8/-0).
De mon expérience, non, souvent des races conditions ou des durées de vie ou gestion des objets qui ont été mal respectés.
De toute façon la cause sous-jacente du soucis de mémoire n'a pas une grande importance en l'espèce, si le compilateur peut te dire "attention ici ce n'est pas un comportement valide" tu vas relire et y réfléchir à nouveau avant de trouver une solution et de pousser ça dans le code final. C'est ça qui compte.
Un peu comme les tests automatiques avant de merger des commits, peu importe pourquoi un test est cassé dans le fond, le tout est d'être notifié et de travailler dessus pour régler le problème avant que le code incriminé ne pose des soucis chez quelqu'un.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . Évalué à 7 (+6/-0). Dernière modification le 13 novembre 2025 à 23:40.
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.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par barmic 🦦 . Évalué à 1 (+0/-1).
Les supply chaines ne sont pas des erreurs mes des attaques. C’est tout de même bien différent.
Ça ne me parait pas très pertinent, tu va récupérer tes dépendances par apt, dnf, pkgsrc ou autre ça revient au même. Tu peut même avoir écrit un logiciel sans la moindre faille et tes utilisateurs et utilisatrices se font avoir parce qu’une lib dynamique qu’ils utilisent s’est fait péter. Ça n’est vraiment pas à observer de la même manière.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . Évalué à 1 (+4/-4).
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.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Pas forcément un mainteneur de ta distro, tu peut avoir de multiples sources, tu peut aussi avoir une bibliothèque qui arrive par ailleurs en soit c’est la sécurité de ton système de fichier qui est en jeu.
Dans le même projet ? Tu veut dire qu’une crate aurait linké statiquement une dépendance que tu récupère par ailleurs ? Les crates étant non compilées je ne vois pas comment ça pourrait arriver.
Les usines de build sont la norme, ça n’est plus un si gros problème. Le linkage dynamique élève d’un cran la complexité des problèmes qui peuvent arriver comme l’a très bien montré CVE-2024-3094 sur xz l’an dernier.
Je trouve en soit toujours très surprenant quand dans une communauté autour du libre on pointe de doigt le fait de réutiliser du code comme un problème.
L’approche consistant à avoir peu de dépendances et ne pas trop gérer leurs versions en délégant ça aux distributions n’est pas sans conséquence. Il est mathématiquement largement plus simple de sécuriser une supply chain que l’ensemble des machines des utilisateurs.
Mais tout ça pour dire que c’est un problème indépendant du langage et qu’ils sont plus système que des problèmes de programmation. Ils apparaîtront plus si un jour on arrive à supprimer tous les problèmes mémoire, mais on sera bien content de voir ça arriver (tout comme tu es content de ne plus voir d’erreur de collision de hash arriver quand tu passe à une bonne fonction de hash).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par Renault (site web personnel) . Évalué à 9 (+6/-0).
Mais ça n'a en fait aucune importance.
Dans un code C ou C++, environ un tiers des failles sont liées à la mémoire en étant évitable en utilisant un langage tel que Rust. C'est ça qui est important. Cela signifie que techniquement un tiers de ces failles (et d'autres bogues par ailleurs) sont aujourd'hui évitables en utilisant un langage qui limite ces risques. ET ces garanties simplifient également le travail de maintenance en identifiant plus tôt les soucis.
On s'en fout pas mal de la comparaison avec JavaScript, Python ou autres car à priori les projets dont on parle ici ne sont pas concernés par de tels langages.
Donc est-ce que Rust est pertinent ? Oui. Est-ce la solution miracle à tous les problèmes ? Non, mais cela ne signifie pas qu'on doit ignorer ses atouts.
Je ne connais pas de développeurs Rust qui considèrent que Rust est magique et qu'il n'y a pas de soucis de sécurité en l'utilisant.
À dire vrai j'ai plutôt vu le contraire, des développeurs C ou C++ expérimentés qui pensent qu'ils sont à l'abri des problèmes de mémoire car ils codent bien, font attention et sont sérieux. Pourtant de nombreux projets gérés par des personnes compétentes font des erreurs et introduisent des failles que Rust et d'autres outils peuvent identifier…
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . Évalué à 2 (+3/-2).
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.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par thoasm . Évalué à 3 (+0/-0).
Tu parles d'outils relativement simples dont dépendent pleins d'autres trucs. Réimplémentés dans un objectif de sécurité. Donc la maîtrise des dépendances de ces outils devrait être un point aussi qu'ils regardent.
Comparer avec des logiciels implémentés en nodejs, c'est pas forcément le cas d'utilisation typique de créer les coreutils, et t'as des biblios pour faire bien bien plus de choses avancées que les coreutils, qui peuvent elles mêmes avoir des dépendances sophistiquées pour faire des trucs non triviaux … La surface d'attaque est là aussi parce qu'il y a piein de biblios qui font des choses diverses. Si tu réimplémentes des trucs bas niveaux comme le gros cas actuel d'utilisation des outils en Rust c'est plus stable, maîtrisable et monitorable que "tout ce qui peut se passer dans la galaxie js".
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par Renault (site web personnel) . Évalué à 5 (+2/-0).
Je ne vois pas trop la différence dans l'absolu. La gestion des dépendance en C et C++ est pénible, avec beaucoup d'étapes manuelles, maintenir à jour la bibliothèque en cas de compilation statique est loin d'être automatique, les attaques sur des dépendances en C ou C++ n'ont pas attendu cargo pour exister dont xz a été la preuve. Et ce n'est pas pour rien que de nombreuses distributions ont investi dans la compilation reproductible pour justement identifier plus facilement si cela arrivait. Cela concerne tous les langages.
En terme de volume les attaques de supply chains restent moins courants que les soucis de mémoire.
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, statistiquement tu peux réduire de 30% le nombre de failles. Et tu réduis aussi le risque de certains bogues, tu allèges la charge mentale des mainteneurs sur ces questions, etc. À périmètre fonctionnel constant. Ce n'est pas un détail. On ne parle pas de comparer un projet C d'un projet Rust qui n'ont rien à voir car cela n'a pas de sens.
Sauf que les attaques par supply chain sont malgré tout bien plus rares et concernent aussi les applications C et C++.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . Évalué à 4 (+4/-1).
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_coreetcoreutils, 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 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.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
De quoi parle tu ?
On peut très bien imaginer te faire télécharger un fichier qui si tu le donne à ls va lui faire exécuter du code arbitraire.
lsest assez simple pour que ça n’arrive pas, mais c’est un type d’attaque relativement classique d’avoir un fichier empoisonné qui une fois donné à un programme va faire n’importe quoi.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par damiend . Évalué à 2 (+1/-0).
Mais c'est bien plus facile de sécuriser une chaîne de dépendance, dont le principe est toujours le même, que tout le code.
C'est comme si tu comparais l'ensemble des dépendances (avec leurs devs, leurs machines, réseaux, autres ressources) avec l'ensemble des lignes de codes, dont toutes peuvent introduire une faille.
Il y a évidemment bien davantage de lignes de codes.
Ce que je constate dans les "vieux" projets PHP sans Composer, c'est que les libs non patchées restent présentes. Avec leurs failles et autres problèmes. Et qu'il n'y a pas de moyen de les détecter facilement (composer audit).
Certes le problème diffère un peu avec JS où il y a vraiment trop de dépendances, mais c'est plutôt l'exception.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . Évalué à 1 (+1/-1).
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[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par thoasm . Évalué à 3 (+0/-0).
La chaîne de compil de la distro peut aussi packager ces dépendances en bibliothèques comme on packgage les libs dynamiques. Dans ce cas une mise à jour dans un des paquets en dépendance dans la partie "source" devrait déclencher une recompilation des paquets dont elle dépend, et une mise à jour de la distro devrait tirer tout ce qui en dépend.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3 (+1/-1). Dernière modification le 14 novembre 2025 à 17:05.
Je ne vois pas trop bien pourquoi on fait une confiance aveugle aux distributions Linux mais pas à Cargo. Par exemple, Arch avec AUR ne fait pas mieux d'un point de vue validation de la sécurité des dépendences incluses? Qu'en est-il de Debian par exemple? Si Debian package une bibliothèque avec des failles de sécurité, volontairement ou non, qu'est-ce que ça change par rapport à une vulnérabilité arrivée par Cargo? Est-ce que Debian a un process de relecture complète du code de chaque version des logiciels qu'ils packagent pour que tu n'aies pas besoin de le faire? Je ne crois pas. Tout ça repose sur de la confiance.
Surtout que les dépendances dans les projets Rust ne se mettent pas à jour toutes seules dans le dos des développeurs, il faut faire soi-même la montée en version (et vérifier au moins que cela fonctionne bien).
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.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . Évalué à 4 (+3/-0). Dernière modification le 14 novembre 2025 à 17:20.
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)
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.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par cg . Évalué à 8 (+6/-0).
Je dirais pas "confiance aveugle". Les écosystèmes sont un peu différents.
Ça dépend de la distrib je pense. Sur Debian, le nombre restreint de devs, le fait que pour devenir dev sur Debian, il faut montrer patte blanche, le rythme lent et la pratique de rétroporter les patchs de sécu permet d'assurer une stabilité de l'environnement sur une version stable de la distrib, et donc d'instaurer une certaine confiance.
Cargo (ou npm, ou pip), c'est des milliers de comptes de dev potentiellement trouables facilement, et des mises à jour permanentes.
Je pense que c'est ça une partie de raison de la différence de traitement.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par Renault (site web personnel) . Évalué à 5 (+2/-0).
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.
Mais Debian le tout repose sur des mainteneurs qui génèrent eux mêmes les paquets sur leurs machines, faut s'assurer que leur système ne sont pas non plus attaqués. Ce n'est pas un hasard si Debian a poussé plus que les autres pour la compilation reproductible car c'est une source de vulnérabilité par rapport à des distributions qui génèrent des paquets sur des machines du projet et gérées par une équipe dédiée et compétente.
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é.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . Évalué à 1 (+2/-2).
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.
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/cmakepousse à 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.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par totof2000 . Évalué à 4 (+2/-0).
Bof …
Nul doute qu'avec l'essor de Rust on en vienne à avoir ce même genre de lib à tout faire.
Bof … pas convaincu : tu as une dizaine de lib directe mais des dépendances indirectes t'en a aussi. J'ai bien souvent été surpris des trucs qu'installait un apt-get pour un simple utilitaire en ligne de commande.
En fait, mis à part le fait que d'un côté il y a des tas de libs à tout faire qu'il n'y aap as de l'autre, je ne vois pas de grande différence entre les deux mondes : il y a des dépendances, et il est nécessaire de chaque côté d'e s'assurer que les dépendances utilisées soient fiables. Ensuite on se retrouve à gérer d'un côté des dépendances basées sur des libs dynamiques, et de l'autre des dépendances sur des libs statiques. L'un n'est pas mieux que l'autre.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par Renault (site web personnel) . Évalué à 5 (+2/-0).
J'ai ri, c'est tellement divers en pratique.
Cela dépend des projets. Puis vu la taille des libs dont tu parles plus haut, cela n'a pas forcément beaucoup de sens de comparer quelques mini libs Rust avec de grosses libs C ou C++.
Tu dis que c'est un avantage, mais c'est aussi un inconvénient : surface d'attaque plus grande, réinvention de la roue avec risque de bogues ou de failles en plus.
C'est d'ailleurs le problème en C, le peu d'abstraction offerte oblige à réinventer des structures de données élémentaires tout le temps. Code dupliqué, code moins bien testé, avec des garanties de sécurité ou d'utilisation plus faibles, etc.
Alors oui tu t'épargnes une lib parfois en le faisant à la main, mais tu perds aussi à côté.
Cela reste à démontrer.
Tu noteras que les problèmes du C sont connus, bien documentés et malgré tout avec les années on a toujours un taux de faille élevé dans un domaine qui pourrait être réduit à presque zéro dans d'autres langages. Les attaques de supply chain contre Rust ne semblent pas plus élevés en pratique que ce qu'on a connu pour le C ou C++ à ce jour.
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.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . Évalué à -1 (+0/-2).
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.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7 (+4/-0).
Il peut être réduit à strictement zéro, en fait, avec des environnements à machine virtuelle comme LISP (dont les supporters ralaient dans le;années 60 sur les développeurs utilisant des langages compilés unsafe avec exactement les mêmes arguments que les supportes de Rust utilisent aujourd'hui) ou SmallTalk. La raison pour laquelle ça n'a pas pris, c'est qu'il y avait un coût en performances relativement important. Rust a fait tomber cette limite (et encore, je vais faire grincer des dents des développears Ada en disant ça).
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.
Avec Cargo, on peut récupérer plein de bibliothèques bien implémentées pour tout un tas de trucs,et personellement j'ai tendance à avoir plus confiance dans ces bibliothèques oue dans ma capacité (ou celle de mes collègues) à réimplémenter les choses de façon sécurisée et avec de bonnes performances. Et puis en plus, j'ai autre chose à faire que développer pour la 72000ème fois un arbre binaire ou une autre structure de base…
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . Évalué à 1 (+2/-2).
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, passudo-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.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par totof2000 . Évalué à 4 (+2/-0).
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 ?
Bof .. Une elevation de privilege du à une erreur dez gestion de mémoire … c'est pas anodin non plus.
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).
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . Évalué à 1 (+1/-1). Dernière modification le 17 novembre 2025 à 00:15.
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)
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
makeest 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.
Makebizarrement 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.[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
De quel question tu parle ? Quelle est la question qui te vient à l’esprit quand tu fais
que tu n’a pas quand tu fais
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . Évalué à 0 (+0/-1).
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 ?
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par barmic 🦦 . Évalué à 6 (+4/-0).
Rien de tout cela n’ajoute de la sécurité. C’est des questions liées à la portabilité est beaucoup de dev s’en foutent.
C’est ce que fait cargo donc.
En vrai tu as même pleins de développeurs qui ne font pas vraiment attention à s’ils utilisent une bibliothèque qui est hors de leur projet. Il n’y a pas d’endroit où documenter la version des dépendances qu’ils utilisent.
Croire qu’on gère mieux les dépendances parce qu’on ne les gère pas c’est un leurre. Des dépendances ça doit être cloisonné, ça doit être versionné etc. Sans ça tu fait bon gré malgré comme tu peut (généralement avec d’autres outils). Ce n’est pas pour rien que make est souvent utilisé avec cmake ou les autotools.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par cg . Évalué à 4 (+2/-0). Dernière modification le 16 novembre 2025 à 11:17.
Oh, ça m'avait totalement échappé. En effet c'est problématique :-/. Merci.
(mais ceci semble le contredire : https://www.debian.org/devel/buildd/)
Totalement d'accord :).
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par totof2000 . Évalué à 3 (+1/-0). Dernière modification le 13 novembre 2025 à 15:53.
A un moment donné il faut arrêter de prendre les gens de haut juste pour se la ramener et cesser de faire dire aux gens ce qu'ils n'ont pas dit. Ou ai-je dit que la gestion mémoire est le problème principal des failles de sécurité ?
Oui mais si le compilo t'évite d'en faire ou te le signale c'est quand même un plus non négligeable. D'autant plus que la gestion mémoire n'est peut-être pas la cause principale des failles de sécurité (comme le démontre la faille de sudo-rs), mais ça reste quand même une grosse source de failles de sécu (30% => environs 1/3 c'est pas négligeable).
De plus ma question tient justement compte du fait que les failles de sécu ne sont pas la seule problématique lié à la sécurité et le fait de ne pas avoir tout à réécrire pourrait justement permettre de corriger ces problèmes sans pour autant en introduire de nouveaux (ou limiter l'introduction de nouveaux problèmes) en limitant la réécriture du code au strict nécessaire.
C'est justement pour avoir ce genre d'avis que je pose la question : la réponse aurait pu être donnée sans condescendance.
Si c'était suffisant, on n'aurait pas 30% de problèmes de sécurité liés à la gestion mémoire, icrosoft ne s'intéresserait pas à Rust, et d'ailleurs Rust n'aurait pas pris. Si les devs s'intéressent à Rust c'est justement parce qu'il répond à un besoin.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par xcomcmdr . Évalué à 4 (+2/-0).
C'est bien mais c'est un peu court quand même face à Rust et son changement total de paradigme, non ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3 (+0/-0).
Je confirme: on a beau mettre en places tous ces trucs, le nombre de bugs causés par une mauvaise gestion de la mémoire reste important (sans forcément parler de failles de sécurité, à ma connaissance personne n'en a trouvé dans le projet). On a plutôt de bêtes déréférences de pointeurs null, des use after free, ou des hroblèmes de partage de données entre threads.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par Pol' uX (site web personnel) . Évalué à 3 (+1/-0).
Surtout le soucis c'est que mettre en place de l'analyse statique ou autre demande une rigueur et un travail dont la charge est portée par le projet. Par défaut c'est absent, comme la CI et le reste.
En Rust, les propriétés vérifiées le sont par le compilateur, out of the box, et sans dérogation en dehors des blocs « unsafe ».
Il y a une différence pratique entre « ça peut être lessivé » et « c'est insalissable ».
Adhérer à l'April, ça vous tente ?
# titre
Posté par Maderios . Évalué à -2 (+6/-10).
Le titre devrait être: "Vulnérabilités multiples dans les anciennes versions de sudo-rs"
La récente 2.10 n'est pas concernée
https://archlinux.org/packages/extra/x86_64/sudo-rs/
[^] # Re: titre
Posté par Faya . Évalué à 10 (+8/-0).
Ancienne = 2 jours donc…
Arch est "cutting edge" mais ça n'est pas le cas de toutes les distros. Par exemple Ubuntu qui vient d'adopter sudo-rs par défaut est visiblement en 2.8
[^] # Re: titre
Posté par Maderios . Évalué à -7 (+1/-10).
C'est bien pour cela que j'utilise Arch qui met à jour les paquets le plus vite possible quand la sécurité est en jeu. Dans les autres cas, le paquet Arch reste en testing quelques jours puis passe en stable. Cas de figure notoire, Calibre que Arch bloque depuis des mois en version 8.7 pour des raisons de sécurité alors que la dernière version est la 8.14. Cause: un vieux bug qui traîne au fil des versions mais qui semble résolu avec la 8.14.
https://archlinux.org/packages/extra/x86_64/calibre/
[^] # Re: titre
Posté par Faya . Évalué à 8 (+6/-0).
Je suis aussi sous Arch, mais ce n'est pas le sujet. Tout le monde n'est pas sous Arch donc il y a actuellement des distros qui ont une version trouée de sudo-rs. Dire que ce sont "d'anciennes versions" c'est un peu exagéré quand le patch a 48H.
[^] # Re: titre
Posté par Maderios . Évalué à -10 (+1/-16).
Une version devient obsolète dès qu'elle met en jeu la sécurité et que l'on laisse traîner le bug alors qu'il est résolu upstream.
[^] # Re: titre
Posté par cg . Évalué à 6 (+4/-0).
C'est vrai, et comme chez Debian, lorsque le correctif est possible à rétroporter, c'est ce qui est fait : https://lists.ubuntu.com/archives/ubuntu-security-announce/2025-November/009938.html
Ce qui n'enlève rien à la pertinence de ton message, sur une machine pas mise à jour très régulièrement, c'est un problème.
[^] # Re: titre
Posté par steph1978 . Évalué à 4 (+2/-0).
Je crois que c'est le principe d'une "disclosure".
On annonce une faille après l'avoir corrigé de manière à ce que les utilisateurs fassent l'upgrade; et que ce soit pas juste la fête aux pirates.
Je ne vois donc rien de choquant dans la formulation. Ça veut dire : "il y des failles dans votre sudo-rs, il est urgent de lire le détail pour savoir quoi faire".
Si tu trouves des articles qui emploient ta formulation versus celle de l'OP, je veux bien les pointeurs.
# Go brrrrrrrr
Posté par Aldebaran (site web personnel) . Évalué à 6 (+6/-1).
Je lis les péripéties de sudo-rs sur Phoronix depuis son intégration à Ubuntu, là bas ça tire à balle réelle sur le langage, comme une bonne blague pour dire que le rust, au final ça pu la merde.
Alors qu'en soit, c'est assez normal d'avoir des bugs avec une ré-écriture d'un truc aussi sensible que sudo; la blague à mon avis aura été de l'inclure par défaut dans un truc aussi mainstream qu'Ubuntu.
Mais ça reste un bon rappel de ce que fait le rust et de ce qu'il ne fait pas ;)
Je trouve de plus la promesse de uutils coreutils plus intéressante en terme de ré-écriture, avec des benchs, des suites de tests de conformités et le fait de tourner directement sur pleins d'OS pour avoir à terme une panoplie vraiment multiplate-forme.
Et sur l'inclusion dans le noyau, je suis également partagé.
Y a de belles choses, comme les drivers des mac m1 (une super aventure de code à lire sur le blog de Asahi), mais ça à l'air de briser les parties génitales d'un paquet de devs c quand ils doivent s'adapter aux changements demandés par les dev rust.
J'espère que c'est un cap à passer, parce que j'aimerais bien voir le Rust briller, mais l'avenir nous le dira. Ça à l'air costaud de mêler du C et du Rust dans un projet de cette échelle quand même.
Et sinon il restera Redox ;)
[^] # Re: Go brrrrrrrr
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7 (+5/-1).
Il me semble que la difficulté de sudo est que cwst un hrogramme complexe avec beaucoup de fonctionnalités (pas forcément souvent utilisées). Par exemple on peut autoriser un utilisateur à lancer seulement certaines commandes avec sudo.
L'outil concurrent doas prend le parti de retirer certaines fonctionnalités pour que le code critique exécuté avec des privilèges élevé reste le plus simple possible. Alors que sudo-rs semble vouloir conserver toute les fonctionnalités.
[^] # Re: Go brrrrrrrr
Posté par Pol' uX (site web personnel) . Évalué à 7 (+5/-0). Dernière modification le 14 novembre 2025 à 07:48.
Beh ça c'est une fonctionnalité de base de sudo, je pense. Si le but de sudo c'était juste de remplacer le groupe wheel, je pense que ça serait pas très pratique.
Adhérer à l'April, ça vous tente ?
# "Vulnérabilités"
Posté par Colin Pitrat (site web personnel) . Évalué à 0 (+1/-3).
Parler de vulnérabilités est presque trompeur, en particulier pour celle où sudo-rs conserve le mauvais UID. Ce sont plutôt des bugs selon moi. Après, un bug dans sudo est presque automatiquement une vulnérabilité, mais quand on parle de vulnérabilité, on a plutôt tendance à penser buffer overflow, injection SQL, etc …
L'autre problème, où le mot de passe n'est pas capturé tant qu'on ne presse pas Entrée et se retrouve donc sur la ligne de command en cas de timeout correspond plus à ce qu'on considère quand on parle de vulnérabilité. Mais ça me paraît très difficile à exploiter, sauf dans des cas où il y a des meilleurs options (par exemple accès physique au clavier, autant mettre un key logger dans ce cas).
[^] # Re: "Vulnérabilités"
Posté par cg . Évalué à 3 (+1/-0).
Je vois :
Afficher un mot de passe sur une ligne de commande par surprise, ce n'est pas la vuln du siècle, mais ça reste sérieux pour s'intégrer dans autre chose de plus grand.
Après sur la terminologie, il y a des personnes qui considèrent quasi tous les bugs comme des failles de sécu, parce que petit bug + petit bug + petit bug = trou. Ça n'aide pas trop à prioriser et parfois c'est tangent, j'avoue :).
[^] # Re: "Vulnérabilités"
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3 (+0/-0).
Ça veut aussi dire que le mot de passe se retrouve dans le buffer du terminal, qui potentiellement se retrouve swappé et donc enregistré sur le disque dur, où on peut le récupérer une fois la machine éteinte (ou de façon sûre, en mettant la machine en hibernation prolongée). Normalement on fait attention que les mots de passe ne soient stockés que dans des zones non enregistrables sur disque et de bien l'effacer avant de libérer la mémoire en question.
[^] # Re: "Vulnérabilités"
Posté par Renault (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 19 novembre 2025 à 08:53.
Valable d'ailleurs pour les données cryptographiques type clés privées.
[^] # Re: "Vulnérabilités"
Posté par thoasm . Évalué à 3 (+0/-0).
Ça c'est plus dur, vu qu'on les tape rarement au clavier ;) Faut utiliser les TPM et pas les .ssh du home.
[^] # Re: "Vulnérabilités"
Posté par Renault (site web personnel) . Évalué à 4 (+1/-0).
Ce que je veux dire c'est que toute application qui manipule des données confidentielles, la bonne pratique c'est de garder en mémoire la dite donnée uniquement le temps nécessaire à son traitement et avant de libérer la mémoire il faut nettoyer cette zone avec des données.
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.