WhatsApp lance son mode Lockdown et adopte Rust à grande échelle

De rouille et dors

WhatsApp lance son mode Lockdown et adopte Rust à grande échelle

Afin de sécuriser WhatsApp, Meta a procédé au « plus grand déploiement jamais réalisé de code Rust sur un ensemble diversifié de plateformes et de produits », et annonce vouloir accélérer l'adoption du langage de programmation sécurisé Rust au cours des prochaines années. La messagerie intègre par ailleurs un mode anti-logiciels espion ou malveillants.

Le 30 janvier à 10h25

Commentaires (20)

votre avatar
Beaucoup sont passé sur Rust ici ? Je ne potasse plus mes petits projets avec Claude/Codex qu'avec ça (ça me semble un cran mieux que le C++ côté sécurité), en association avec quand nécessaire du bon vieux script bash. (Parce que bon, Python, pour la pérennité...)
votre avatar
Tu maîtrisais déjà un peu Rust auparavant ?
Parce que l'idée de faire quelques tools avec en "vibecode" m'a tenté. Mais sans connaissance du langage (et c'est pas le plus évident à appréhender - la syntaxe !), c'est hors de question pour plein de raisons (sécurité, qualité du code, etc).

Même si globalement j'ai l'impressio que les LLM arrivent à cracher du code correct de base.
votre avatar
D'ailleurs, moi je ne programme pas, mais je me demande pourquoi les LLMs font du mauvais code? A priori, il suffit de leurs donner à bouffer la documentation d'un langage pour que tout se passe bien, non?
votre avatar
Pour vous répondre à tous les deux, non, je ne faisais pas de Rust avant, j'apprend au fur et à mesure.
Mais clairement, Rust est tellement bien pensé niveau sécurité comparé à C/C++ que... C'est beaucoup moins problématique/risqué de recourir aux LLM à ce niveau là.
Mais il ne faut pas hésiter à demander à différents LLM un audit, en croisant ces derniers, à la fin, pour les éventuels bugs et soucis de sécurité, généralement ça aide bien.
Mention spéciale pour Codex qui se débrouille particulièrement bien en la matière, même avec codex 5.2 low. À côté Gemini se plante une à deux fois sur trois, ne passant pas le cap de la compilation et devant re-corriger les erreurs derrières. Pareil pour Claude, il est verbeux et explique bien, mais omet/oublie beaucoup de choses et doit corriger et re-passer à la moulinette régulièrement.

Par contre, quelqu'un n'y connaissant rien en C qui demanderait à faire un projet from scratch aux LLM, là, ouille, gros risques... Modifier/adapter quelques projets ouverts, pourquoi pas, mais sinon... À moins de se faire un truc perso dans un environnement cloisonné, là pourquoi pas.
votre avatar
J'ai fais 2 ou 3 tests de Co-Pilot en entreprise.
Une demande en batch pour supprimer des fichiers identifiés à partir d'une expression régulière : je n'ai pas eu d'expression fonctionnelle ; j'ai lancé la génération de la réponse plusieurs fois, sans changer la demande et il ne me renvoyait pas la même construction de l'expression.
Une autre pour du powershell, et c'était pas mieux. C'était juste quelques lignes de script ; j'ai oublié de quoi il s'agissait, mais je cherchais une cmdlet que je ne connaissais pas. La cmdlet était bien ce que je cherchais, mais sa proposition d'usage incluait un argument qui n'existait pas ; et il s'est emmêlé les pinceaux dans le type d'identifiant à mettre à mettre derrière un autre argument.
votre avatar
Je ne sais pas ce que tu cherches à accomplir mais Get-ChildItem peut être utilisé avec des regexp..
votre avatar
les LLMs font du mauvais texte. Hallucinations, contradictions, mauvaise compréhensions, contresens, etc.

En général, ils arrivent à donner bonne illusion.

Le code, ce n'est rien de plus qu'un cas particulier de texte. Donc oui, ça fait de la merde et tout ne se passe pas bien non.

C'est d'autant plus difficile que lorsqu'on code, il y a beaucoup d'implicite dont on ne se rend même plus compte. Dans les prompts, il faut alors préciser l'implicite de manière... explicite ! c'est un exercice loin d'être évident, et pour un résultat non garanti.
votre avatar
Le contexte est clairement la clé, les LLM s'en sortent beaucoup mieux en bossant sur quelque chose qui existe déjà, qu'à créer quelque chose à partir de zéro.
Par contre quelque chose qui m'a vraiment surpris, c'est que les plus gros LLM sont très bons pour faire du reverse engeenering sur des formats de fichiers non documentés... J'ai pu par exemple potasser sur la traduction d'un jeu récent, extraire et recompresser et parser le texte d'un format propriétaire d'un jeu narratif japonais récent, alors que sans ça le travail aurait été dingue... En moins d'une heure, c'était bouclé...
Même sur des executables ils bossent bien, et peuvent utiliser ghidra
votre avatar
Ce n'est pas aussi simple :)

Tu peux voir le LLM comme le stagiaire, qui a bouffé de la théorie en veux-tu en voilà, mais qui est incapable de comprendre un contexte donné si tu ne prends pas le temps de lui expliquer. Donc il va pouvoir coder... mais si tu fournis mal le contexte, c'est la catastrophe 9x/10.

Et puis comme avec un stagiaire, ou pas, il est important de review le code qu'il te sort (et le plan auparavant). Et pour ça il faut comprendre ce que tu lis. Donc une connaissance minimale du langage, des bonnes pratiques, etc, restent indispensables selon moi pour éviter au maximum les effets de bord (sécurité, performances, maintenabilité...).

Tu peux toujours lui fournir de la documentation pour mieux le guider (ou plutôt utiliser des skills). Mais ça n'enlève pas la nécessité de vérifier, ni la possibilité qu'il fasse n'importe quoi pour X raisons.

Il ne faut pas oublier que le LLM reste une machine "prédictive", statistique.
Il ne connait rien du contexte dans lequel tu l'utilises, et est incapable de concevoir celui-ci. C'est au développeur de donner ces informations là... et donc de vérifier qu'il s'y est bien tenu.
votre avatar
Pour les mêmes raison qu'ils peuvent donner de mauvaise réponse dans n'importe quel domaine.
Déjà en entré le prompt peut être inadapté/incomplet/..., le contexte médiocre et quand tu ne connais pas ton sujet ça a de forte chance d'être le cas.
Puis ensuite faute de trouver une réponse pertinente le LLM peu inventer une réponse et de manière générale il n'y a aucune intelligence dedans donc logiquement le code peut être correct mais pas du tout faire ce qui est attendu, faire semblant de le faire....

Bref si tu ne comprend pas ce que fait le code c'est une mauvaise idée et mème si t'es un ingénieur chez Cloudflare avec probablement un peu d'expérience tu peux te ridiculiser en publiant n'importe quoi https://tech.lgbt/@JadedBlueEyes/115967791152135761
votre avatar
Merci pour vos retours, c'est très gentils d'avoir pris la peine de répondre !
Je comprends mieux maintenant.
votre avatar
Pour faire suite à ma réponse précédente, voilà un petit projet en Rust sur lequel j'ai bossé pour mes besoins, et libéré : https://gitlab.com/pepinature/git-noob
Ce n'est pas encore tout à fait finalisé, mais ça a bien pris forme.
votre avatar
Pour ma part, je ne suis toujours pas passé à Rust.

J'ai fait un premier essai, pour voir un peu le langage, et je trouve sa syntaxe inutilement complexe, avec des notions qui ne devraient pas exister dans un langage (par ex. les macro, et le fait de les appeler avec une syntaxe différente des fonctins, beurk).

Je suis plutôt orienté artisanat logiciel, et j'essai donc d'appréhender le développement logiciel comme un tout. Maintenance, évolutivité, sécurité, etc..

Si Rust a des atouts indéniables d'un point de vue sécurité, sa syntaxe et sa courbe d'apprentissage le rendent difficile à lire et à comprendre pour un non spécialiste Rust, pénalisant alors la maintenabilité. C'est un langage qui nécessite un réel investissement avant de pouvoir vraiment l'utiliser.

Après, je ne fais pas de C/C++ mais du C#. Les apports en sécurité sont donc un peu moindre qu'en C ou C++, puisque la gestion de la mémoire répond à un paradigme déjà différent.

J'attends de voir aussi comment évolue son outillage, les débogueurs, cargo, l'intégration dans les IDE, etc.
votre avatar
En venant du C++ moderne, tu retrouves très rapidement tes petits en Rust. Il y a deux trois trucs surprenants (mais pourquoi donc ont-ils appelé leurs variants des enums ?), mais globalement, rien de vraiment rédhibitoire, et clairement certains choix sont meilleurs qu’en C++ (l’avantage de partir « from scratch »).
votre avatar
je suis resté sur du C++ "legacy". J'ai switché vers le C# en 2010, tant je trouvais que le langage stagnait (forcément, il s'est mis à vraiment bougé 2 ans après :p).

L'année dernière, j'ai décidé de me remettre au C++ (pour me mettre à jour) et de commencer le Rust. Je vais peut être commencer par le C++ alors ;)

Merci pour ton retour :)
votre avatar
Je serais tenté de te conseiller l’inverse. C++ est devenu un tel gros morceau à avaler qu’il est très compliqué de le recommander. Et globalement, il te faudra quand même oublier pas mal de ce que tu as appris auparavant pour faire du C++ moderne. Si tu fais du Rust avant, tu prendras de bonnes habitudes, qui seront valables aussi en C++. Si tu fais le chemin inverse, il est assez possible (mais pas obligé) que tu partes dans des chemins de traverse, pas forcément bien recommandés.
votre avatar
J'avais un très bon niveau en C++. Même si je sais que le C++ moderne a introduit de nouvelles fonctionnalités, conceptuellement, je les maitrise déjà via d'autres langages.

Et cela fait si longtemps que je n'ai pas fait de C++ que la partie "oublie des mauvaises pratiques" est déjà faite à 90% :D

Et puis, quoi qu'il arrive, je vais peut être reprendre un projet en C++, donc autant que je commence par là, rien qu'à cause de ça ;)
votre avatar
Pour recommander du C++, il suffit de se tenir aux derniers normes, en l’occurrence la 23.

Le C++ moderne change par rapport à l'ancien C++ en étant plus propre, notamment sur la gestion mémoire. Il y a bien parfois quelques petits égarements dans la norme mais au global c'est propre.
Ah mon sens le seul atout de Rust, c'est son aspect fonctionnel qui est plus prédominant et de fait plus intéressant à récupérer comme on repasse au C++. Pour le reste, les concepts d'ownership et sémantique de move se retrouve en C++, et font parti des bonnes pratiques depuis le C++ 11.
votre avatar
Je veux bien qu’il suffit de s’en tenir aux dernières normes. Je fais du C++ quotidiennement, professionnellement, depuis plus de 20 ans. Je me tiens plutôt à jour (j’ai intégré l’introspection dans une lib que je développe, pour donner un exemple). Et pourtant…

Je ne vois pas comment expliquer à quelqu’un qui découvre le langage pourquoi il faut écrire decltype(auto) et pas auto (et je ne parle pas de auto(x) que nous a rajouté C++23). Je ne sais pas non plus expliquer la différence entre une lvalue, une rvalue, une prvalue, une rvalue reference. Je sais à peu près qui correspond à quoi, et j’en sais suffisamment pour retrouver mes petits quand je suis confronté à un problème où j’ai besoin de faire la différence. Des exemples comme ça, il y en a pléthore dans le langage, plein de subtilités (l’ADL, on en parle ? CRTP ?) qui font que pour moi C++ est un langage qui demande un certain niveau d’expertise.

Et par contre, je suis certain que chaque personne qui code en C++ sera un jour confronté à un message d’erreur du compilateur lui parlant de ça (généralement, c’est le moment où les collègues font appel à moi). C’est tout ça qui fait que j’ai du mal à recommander C++ aujourd’hui, malgré toutes ses qualités. Pour moi Rust est beaucoup plus simple à appréhender, et je pense qu’il vaut mieux apprendre Rust puis C++, qu’apprendre directement C++.

Et sinon, entre tokio et les coroutines C++, le choix est à mon sens vite fait :)

Après c’est forcément différent pour chacun, par exemple pour fdorin, qui a déjà un bagage.
votre avatar
Et la protection des métadonnées des messages, c'est pour quand Meta ? :transpi:

WhatsApp lance son mode Lockdown et adopte Rust à grande échelle

  • Une décision qui remonte à la faille Stagefright de 2015

  • Le « plus grand déploiement jamais réalisé de code Rust »

  • Une faille de sécurité corrigée, et une plainte « ridicule »

Fermer