karchnu a écrit 393 commentaires

De ce que j'en comprends, il est possible de sortir de son chroot sous linux, et le développeur est sensé ne pas considérer chroot comme une sécurité. Je me demande ce qu'un namespace peut apporter à ça. Sous OpenBSD il y a depuis peu la fonction unveil qui limite l'accès au système de fichiers.

Effectivement. J'ai écris cela pour la concision, montrer comment on pourrait faire ça avec cette syntaxe. Le reste est du détail technique.

Je pense que pour mieux comprendre et répondre à ce que vous voulez faire, il me faudrait l'accès au draft. Malheureusement je n'ai pas de compte sur opengroup.org.

J'ai zieuté un peu "Operating System Structures to Support Security and Reliable Software" (1976), j'ai pas eu le courage de lire les 37 pages mais je n'ai pas l'impression que cela reflète parfaitement ce que vous souhaitez faire de nos jours. J'en ai retenu un système un peu compliqué, dont les auteurs sont d'accord pour dire que des options de sécurité dans les compilateurs pourraient faire une partie du job.

Du coup, je ne peux me baser que sur les exemples que vous donnez, et qui me semblent trop éloignés de la réalité pour être utiles en pratique. Mais soit, je me demande ce à quoi cela ressemblera à l'avenir, et je vois l'utilité qu'on pourrait en avoir (même si c'est éloigné de l'objectif qui est annoncé).

Réponse un peu plus directe à votre question : on ne le fait pas. On vérifie que le programme en amont pour vérifier qu'il ouvre bien le port qu'on lui demande, et c'est tout. Un programme va, dans les cas observés et selon mes connaissances, se lancer en ouvrant les ports dont il a besoin puis pledge. S'il n'a pas ouvert les bons ports avant pledge, c'est une erreur de programmation mineure et évidente, et après il ne peut de toutes façons plus ouvrir de port. Si on parle réseau, de toutes manières il y a de fortes chances pour qu'on puisse gérer ça avec pf, même s'il ne fait pas le lien avec le programme ni l'utilisateur qui a lancé le programme.

S'il y a une place pour votre projet sur de vrais système, je ne considère pas nécessairement que ce soit lié à 100% à la sécurité, mais surtout pour la surveillance des programmes et leur debug. J'ai peur qu'il soit trop complexe de définir correctement les droits sans être soit trop laxiste, soit trop stricte, la balance est compliquée à obtenir (mais c'est mon avis, je serai ravis d'avoir tort).

En revanche, si je me souviens bien, les capacités sont gérées non pas au niveau du programme seul, mais aussi de ses fils. Ça c'est intéressant, toujours pour le debug en analysant ce qui se passe dans un environnement de test par exemple.

Seul root a le droit d'ouvrir un port < 1024. Dans la pratique je n'ai jamais, en 15 ans d'administration système, eu besoin d'ouvrir un port < 1024 pour utilisateur. Ce qui est fait en revanche, c'est que root lance un programme qui se sépare en deux pour gérer correctement la séparation de privilèges, avec d'un côté un programme qui gère le réseau et les appels systèmes en tout genre, et un programme qui n'a droit qu'à très peu de choses, avec un pledge qui lui coupe presque tout et est dans une racine séparée.

OpenBSD ne part pas du principe qu'on a le droit d'ignorer le code, le projet part au contraire du principe qu'il faut être très vigilent sur le programme qu'on écrit, qu'il faut faire activement des relectures même si on implémente des tas de parades dans le noyau pour contrer des attaques potentielles. Les deux sont complémentaires, et on ne peut pas prétendre gérer la sécurité si on ne fait pas les deux. S'il y a eu si peu de failles sur ce système en plus de 20 ans d'existence, ce n'est pas le fruit du hasard. Les mots clés sont : relecture et sécurité pro-active (séparation de privilèges, pledge, W^X, pageguard, diverses options de compilation…).

Si on a un programme dangereux à faire tourner, on peut toujours le mettre dans un chroot et le lancer via un autre utilisateur. On peut aussi s'amuser à lui créer une interface réseau pour qu'il fasse sa tambouille dessus, sous linux il faut voir les netns avec ip. Mais à aucun moment le réflexe est de lui donner tous les droits sur le système, il est contraint, au pire dans un sous-système minimaliste (vraiment minimaliste, un chroot n'a besoin de rien du tout, limite une copie de /etc/resolv.conf et peut-être un ou deux autres fichiers vite-fait).

Implémenter de la sécurité pro-active ne doit pas dispenser d'écrire du code en respectant les standards de sécurité. Et si on les respecte, il ne reste finalement que peu d'erreurs à intercepter, et elles resteront difficiles à analyser même avec votre solution. Donc oui c'est un complément, et le commentaire que je vous ai donné plus haut montre en quoi votre projet peut être intéressant (voir l'exemple de syntaxe pf adaptée à votre outil) avant tout pour voir ce qui se passe en historisant les appels système.

PS: Bon, mine de rien j'ai passé pas mal de temps à argumenter… donc soit on discute authorship soit je pars finir ma thèse ! :-D

Soyons d'accord sur ça : non, aucun programme actuel ne vérifie ce que vous souhaitez vérifier avec votre projet. Si je grossis un peu le trait (dites-moi si je me trompe, qu'on soit définitivement d'accord sur la question), votre projet est d'intercepter tous les appels systèmes pour vérifier à la fois si ce sont des appels autorisés, et les paramètres qui y sont passés. Au final oui, vous allez bien plus loin que ce qui existe. Mais je vois 2 problèmes majeurs : les outils (et méthodes) actuels se rapprochent d'une vérification à gros grain mais qui couvre une (très) bonne partie des problèmes, et la complexité pour décrire des autorisations.

Revenons sur vos exemples.
Concernant les ports ouverts, effectivement, pledge et doas ne peuvent pas vérifier cela. En revanche c'est le travail de pf (le pare-feux packet filter), et il le fait très bien, il va même au delà de ce que vous souhaitez faire : vous pouvez préciser les messages qui sont ou pas accepter (est-ce qu'il doit accepter d'ouvrir des connexions TCP à partir de ce port, ou seulement en recevoir ? Est-ce de l'UDP ? SCTP ? Quelle taille de buffer ? …).

Pour l'exemple que vous donnez d'un subprocess qui serait appelé par un programme d'awazan, et que ce programme aurait été modifié par awazan pour y ajouter des éléments dans pledge, c'est au final très peu réaliste. En réalité, il est hors de question de donner des droits root à un simple utilisateur sur un programme de l'utilisateur. C'est un non sens, littéralement une faille de sécurité.

Comme nous l'avons vu pour l'instant, les exemples couvrent l'usage du réseau, ce qui est important également c'est l'usage du système de fichiers, et pour ça la séparation de privilèges (que j'ajouterai volontiers : amorcée par le projet OpenBSD…) et le chroot. Rien qu'avec les outils que je viens de citer, on sait gérer en grande partie le réseau (quels sont les ports qui peuvent être ouverts), on ne laisse pas une application ouvrir des fichiers au hasard sur le système (elle est contrainte dans une racine séparée), et on ne laisse pas un simple utilisateur s'octroyer des droits (hors de question qu'on laisse des droits root sur un programme utilisateur, on donne le droit à un utilisateur de lancer un programme root avec des paramètres prédéfinis).

On peut dire également que votre projet permet à un simple utilisateur de lancer son propre programme de manière sûre… si on a fait un gros travail en amont pour contraindre le programme qu'il veut lancer à ne faire que ce dont on a décidé. Effectivement, vous pouvez aller jusqu'à préciser à la fois qu'un programme en particulier sera utilisé par un utilisateur en particulier et qu'il n'aura pas le droit d'ouvrir autre chose qu'un port en particulier. Mais tout ceci reste laborieux, et en pratique les paramètres vont changer très souvent. Là où les outils actuels font bien leur travail est qu'ils maintiennent une balance intéressante entre le temps pris pour l'administration/développement, et les vérifications qui sont faites. C'est simple, rapide à implémenter, et du coup c'est utilisé.

Ensuite, concernant la complexité de description des autorisations. Vous avez fait un travail pour alléger l'écriture des différentes règles en définissant des rôles à des utilisateurs et des groupes, ce qui est un moyen assez simple de regrouper des instructions qui ont un même sens sémantique. Ça ne va pas assez loin, c'est même bien trop simpliste. Les exemples qu'on peut voir sont également simplistes, et je ne vois pas votre projet fonctionner pour de grosses applications, il y a un manque d'expressivité. Je ne peux que vous conseiller de regarder la syntaxe de pf dans la FAQ OpenBSD pour vous en inspirer.

Pour que votre solution soit utilisable, il faudrait selon moi regrouper les appels système, pouvoir donner des indications "laxistes" où on dirait "vérifie que le programme X n'ouvre que le port Y, mais je m'en fous de tout autre paramètre lié au réseau". Sinon on sera obligé d'écrire des tonnes d'instructions pour couvrir tous les appels qui sont fait. Par exemple, si un programme a besoin de lire et écrire des fichiers, il va être un peu pénible de devoir faire une instruction pour préciser tous les appels de open avec tous les fichiers (ou alors il faut s'inspirer des tables dans pf). Bref, regardez la syntaxe pf, il y a déjà tout ce que vous voulez : des tables pour regrouper des capacités, utilisateurs, groupes, des instructions de blocage ou acceptation (block, pass) et la possibilité de dire "tout sauf" (via '!') ce qui est pratique, des macros pour simplifier la lecture, des listes, des ancres pour donner la possibilité à une application externe d'ajouter des instructions à la volée…

Allez, je ne résiste pas à donner un exemple :

table <webusers> { awazan, toto } # table = liste qui peut être màj à la volée via une commande
cap_net_web = "cap_net_bind_service port { 80, 443 }"
progweb = "/usr/local/sbin/webfail.py"

cap_fs = { toutes les capacités liées au système de fichiers }

pass cap_net_web to <webusers> prog progweb
pass log cap_fs to <webusers> prog progweb label "fs web" # autorise et log tous les accès aux fichiers
block # bloque tout ce qui n'est pas explicitement autorisé au dessus

Bon, si le projet se dessine au final comme ça, il m'intéresse. ;) Là il commencerait à devenir intéressant dans la pratique (pour le debug principalement).

PS: Vous ne pouvez pas le savoir… mais il y a un commentaire que j'ai posté il y a plus d'un an sous cette vidéo… :-D

Je viens de voir votre readme. La seule chose que je peux vous dire, c'est que vous vous embêtez vraiment beaucoup à définir des rôles, utiliser les capacités Linux, et tout un tas de choses compliquées pour au final remplacer pledge et doas. Tout votre exemple sur le script python autorisé à démarrer à partir de l'utilisateur awazan de lancer son serveur sur le port 80 revient à autoriser une personne à lancer une application avec certains paramètres, et c'est pratiquement tout. Donc vous demandez aux administrateurs de créer des fichiers XML pour décrire des rôles qui auront des droits, des utilisateurs qui pourront avoir ces rôles et les applications qu'ils pourront lancer avec en plus les paramètres autorisés.

Voici le même exemple avec pldege (voir pledge(2)) et doas (voir doas.conf(5)) :

pledge("inet", NULL);

Dans le fichier /etc/doas.conf :

permit nopass awazan as root cmd python /usr/local/Users/awazan/server.py -p 80

Et voilà… alors certes, vous pouvez toujours trouver des arguments un peu pointus pour montrer que cela n'est pas 100% équivalent, mais on en est vraiment pas loin, tout en ayant une bien moins grande complexité et donc en ayant bien plus de chances d'être effectivement intégré sur de vrais systèmes en production (ce qui est le cas pour tous les systèmes OpenBSD depuis plusieurs années maintenant).

Le second exemple que vous donnez implique de ne pas pouvoir faire du LD_PRELOAD, ce qui est déjà pris en compte par mon exemple de fichier doas, tout simplement parce qu'on doit préciser explicitement via keepenv si nous souhaitons garder les variables d'environnement de l'utilisateur au lancement de la commande. C'est un fonctionnement par défaut qui me paraît complètement raisonnable, et sûr par défaut.

Votre troisième exemple indique qu'il faut actuellement utiliser des commandes compliquées pour injecter des capacités dans le binaire des applications, puis ces privilèges sont supprimés dès que le binaire change, et donc votre solution apporte une certaine stabilité. Oui, comme doas.

Du coup, même en ayant creusé votre proposition, je ne peux que vous encourager à regarder ce qui est fait côté OpenBSD. C'est de loin pour moi un exemple du meilleur de ce qui se fait dans le domaine.

PS: j'ai l'impression que votre travail est lié à une publication scientifique. Je suis sincèrement désolé de voir à quel point vous avez travaillé pour arriver au final à moins bien que ce qui est déjà fait. Certes, c'est externe à l'environnement Linux, mais vous auriez sans doute pu vous en inspirer… bref. Je compatis. Moi aussi je suis dans le domaine et je ne fais pas toujours des articles intéressants. Courage pour la suite.

Je comprends bien ce que vous dites, et contrairement à un système comme pledge, vous partez du principe qu'on ne touche pas à l'application mais on la contraint par une autre manière que la perte de privilèges volontaire indiquée dans le code. L'hypothèse de départ est différente, dans un cas on a le code de programmes dont on veut assurer encore plus la sécurité, de l'autre on part uniquement des binaires pour gérer la sécurité.

Et c'est exactement ce que je disais : deux approches. Et là où on peut accepter qu'un programme "s'initialise" puis lâche ses privilèges avec pledge, le même fonctionnement est impossible avec les privilèges Linux et on doit séparer le programme en deux pour le même résultat : le binaire conserve ses privilèges même lorsqu'il entre dans sa boucle de fonctionnement donc l'initialisation doit se faire ailleurs.

Donc on a des hypothèses de départ différentes :

• avoir accès au code, pouvoir y ajouter une ligne pour limiter ses droits
• ne pas avoir accès au code, ou ne pas vouloir y toucher (ni s'en préoccuper)

Un fonctionnement différent :

• une ligne de code indiquant qu'on ne conserve qu'une partie de nos privilèges
• des outils externes au programme qui vont donner des privilèges

Des fonctionnalités et contraintes différentes :

• on peut avoir des droits au début pour l'initialisation puis y renoncer (fonctionnement normal de toutes les applications serveur), mais on doit toucher au code
• on donne des privilèges à une application sans pouvoir lui en retirer une fois la phase d'initialisation terminée, mais on n'a pas besoin de connaître l'application, et on veut juste s'assurer qu'elle n'aille pas fouiller le système et lui interdire des appels systèmes

Mais un même but final : contraindre une application aux seuls privilèges dont elle a besoin. On pourrait donc discuter des usages possibles de chacune des approches, certes, mais l'objectif est quand même identique.

Par ailleurs, dans les deux cas il faut bien qu'on sache ce que l'application est sensée faire pour y attribuer les bons droits… donc le fait d'avoir ou pas à modifier le code (quand on parle seulement d'ajouter une ligne de code), n'est pas un argument qui pèse lourd. Cet argument vaut surtout pour les applications non libres, où on n'a pas du tout accès au code source, sinon ajouter une ligne de code me semble préférable à la complexité des capacités Linux. L'approche (caricaturée) ici est donc "on ne gère pas la sécurité en amont, les admin feront le job plus tard".

L'objectif final est le même : rendre le système plus sûr en limitant le pouvoir de nuisance d'une faille. Et pour cela, dans tous les cas, on limite les droits d'une application. L'approche est certes différente, comme vous dites Linux capabilities est différent de seccomp, capsicum et pledge, mais on cherche à faire la même chose. Ce que je dis dans mon commentaire est justement ça : l'approche est différente, et en pratique moins intéressante à cause de sa complexité de mise en œuvre et du coup du peu d'intérêt pour les développeurs. Oui ça existe dans le noyau depuis longtemps, et le fait que pas grand monde l'utilise me semble révélateur de l'échec que représente cette approche.

Sur le système OpenBSD il y a le principe de pledge qui est très intéressant à noter et qui, comme ici, permet de limiter le pouvoir qu'a un programme sur la machine. L'idée de pledge est d'ailleurs largement plus simple que les capacités du noyau Linux.

On part du principe qu'un programme se compose généralement de 2 parties : la partie initialisation (on ouvre des sockets, des fichiers, on lit une configuration, etc.) et une boucle de travail (répondre à des requêtes HTTP par exemple). De ce fait, on sait ce qui doit et ne doit pas pouvoir se passer dans la boucle. On va donc dire qu'on assure n'utiliser par exemple que le réseau et le DNS avant d'entrer dans la boucle infinie, en indiquant dans le programme une simple ligne pledge ("inet dns"); et voilà.

J'ai regardé légèrement SELinux, les capacités Linux, et encore deux ou trois autres systèmes comme ceux-là… on est à des années-lumière de la simplicité de pledge, et du coup pas grand monde utilise ces mécanismes. Et au contraire, tous les programmes OpenBSD sont passés à pledge en l'espace de deux releases (une année), permettant de trouver des erreurs de programmation dans le code de certaines applications comme openbgpd.

(ma vie) C'est assez drôle d'ailleurs, la première fois que je me souviens avoir entendu parlé de SELinux était quand il fût responsable d'un problème de démarrage de programme sur ma machine.

Petit défi : gérer les mods des jeux.

Je galère comme pas possible à gérer des mods depuis NexuxMod (par exemple) pour mes jeux, comme Morrowind, Halo, … je pense qu'une gestion propre (et générique) des mods ça pourrait être excellent. Je ne connais aucun programme qui fasse ça bien, même pour un jeu en particulier. Bien sûr, il faudrait gérer quelques trucs, comme les dépendances dans les mods… mais si tout était facile, où serait le fun ? ;)

Je regarde depuis quelques jours l'ensemble des mods qui existent pour (Open)MW et au final il y a tellement de choses qui ont été modifiées que quasi tout a été remplacé tôt ou tard par un mod. Du coup, on pourrait totalement faire une distribution d'OpenMW avec un ensemble de mods qui au final remplacent tous les assets originaux. Du moins, je ne vois pas ce qui manquerait : l'ensemble de map a été modifiée/remplacée, les sons, les textures, les icônes, les modèles 3D ainsi que les animations… du coup il manque quoi ?

Parce qu'entre Morrowind Rebirth, Morrowind Overhaul - Sounds And Graphics, Morrowind Comes Alive… j'ai vraiment l'impression que tout a été changé. Allez, disons le texte et les quêtes qui sont encore à part peut-être… mais il y a quand même un certain nombre de quêtes en plus apportées par la communauté. Limite il ne doit pas manquer grand chose pour en faire un projet à part.

En tout cas, je viens de tester OpenMW et c'est excellent. Petit point négatif n'ayant rien à voir avec OpenMW en particulier, je n'aime pas du tout la gestion des mods : j'ai rien réussi à installer. Pourtant j'ai fait ce qui été indiqué… :/ Ça demanderait peut-être un petit bout d'interface pour gérer tout ça simplement… par exemple en ayant une UI qui te permettrait de télécharger, installer, activer et désactiver des mods.

Je ne suis pas des masse convaincu, niveau bibliothèques Haskell est plutôt chargé. Pas assez utilisé dans la pratique pour me faire un avis pertinent, mais ça m'a pas l'air bien différent de ce que vous décrivez.

Il me semble assez simple, et je vois que des gens l'utilisent pour faire un peu de code en réseau, et je suppose que c'est très bien pour le web (pour remplacer node de ce que je vois des autres commentaires). Mais je ne vois pas trop ce qu'il apporte aux langages un peu plus connus. J'ai fait un peu de Haskell et j'aimerai bien savoir ce qu'Erlang et Elixir peuvent m'apporter, et je n'ai rien vu de tout ça sur les sites que j'ai vu.

Et également, le "documentaire" est vraiment creux : il y a des gens qui disent "c'est génial" et expliquent que "c'est génial" parce qu'ils arrivent à faire appel à un code distant… j'ai dû raté quelque-chose, ou alors c'est juste complètement con.

La pérennité d'un langage et que dans l'écosystème il y ait ce qu'on souhaite, oui. De même, si t'as un projet sur lequel tout est en C++, il n'y a pas lieu de changer sous prétexte qu'il y a un nouveau langage qui brille.
Se baser uniquement sur le fait qu'on ait du code dans un langage dans un coin pour justifier que tout ce qu'on fera par la suite sera dans ce même langage, y compris d'autres projets qui n'ont rien à voir, alors qu'un autre langage pourrait parfaitement te satisfaire tout en étant plus simple et plus sûr, tout en ayant les fameux écosystème de grande taille et qu'il ait déjà un paquet d'années, bof. J'ai pointé du doigt un argument qui est donné en boucle… et qui n'est pas lié à un raisonnement valide, ce n'est qu'une justification pour ne jamais rien changer, quelqu'en soit les conséquences, peu importe s'il y aurait effectivement mieux à faire.

Et je me fiche complètement de l'argument "ouais mé ton manager y ve pa lol", la question ici s'adresse à des gens intelligents qui comprennent les tenants et aboutissants y compris techniques, pas des managers.

Mais bon, j'ai l'impression de m'embêter pour rien, face à des arguments creux autant s'arrêter de tourner en rond.

Je pense plutôt que Docker n'existerait tout simplement pas. Mais bon, on va pas commencer une guerre de trolls. :p

Plus sérieusement, je ne viens pas sur LinuxFR en demandant des arguments pour qu'on me réponde "ouais mais de toutes façons on ne fait pas ce qu'on veut". Ce n'est pas pertinent comme réponse. C'est superficiel, générique, peu construit et peu intéressant : oui, on sait très bien pourquoi on n'utilise pas des techno intéressantes au quotidien dans toutes les entreprises, mais ce n'est pas la question ici.

Encore et toujours la même rengaine, c'est un argument circulaire : il faut du C++ parce qu'il y a actuellement du C++, donc demain il faudra du C++ car hier on avait du C++. Il y a mieux comme langage ? Pas grave, on garde C++ parce que c'est ce qu'on a donc c'est ce qu'il nous faut.

Dire "ouais mais tu dis ça parce que tu parles de projets perso où t'es le seul dev dans ton garage", ça se tient parfaitement… sauf que le langage a désormais 7 ans, un succès auprès des développeurs qui sont de plus en plus nombreux à l'utiliser pour tous les projets possibles et imaginables (en allant jusqu'à des OS et du code très bas niveau, y compris dans des projets très visibles comme ffmpeg). Donc s'il y avait des critiques techniques, je veux bien les voir, là visiblement on en reste à des critiques très superficielles et génériques.

Au final, il faudrait quoi du coup pour faire changer les mentalités à propos du C++ ? Parce qu'à part fournir un langage bien plus simple, ayant globalement les mêmes performances, une meilleur gestion des bibliothèques tierces, une manière plus élégante de déployer le code, un système de dépendance moins archaïque, une analyse statique du code permettant de déceler plus rapidement des erreurs, une gestion plus pratique (et sûre) de la mémoire, une compilation qui dure pas des plombes, une documentation fournie lisible et maintenue… il faut quoi de plus ?

Oui, c'est bien du "temps réel", mais ce que je veux dire par là c'est qu'il y a un système de gestion de "chance". Tu peux être à côté de l'ennemi, qu'il ne se défende nullement et pourtant rater (et sans animation particulière non plus, juste… rien ne se passe). Et ça, c'est frustrant !

Je n'ai aucun problème à me battre contre un ennemi qui contre, qui utilise une parade contre mes attaques, mais un simple "rien ne se passe" n'est juste pas possible. Je vois que je suis à côté, je lance ma massue sur sa tronche, je veux qu'il se passe quelque-chose.

Lua c'est bien, et je pense que moonscript pourrait être encore mieux pour avoir un code encore plus simple à lire et à écrire : c'est du Lua auquel on a ajouté quelques éléments de syntaxe. C'est totalement compatible Lua, ça en réutilise les bibliothèques, et le code moonscript est compilé en code Lua.

Tout à fait d'accord, une version libre impliquerait de changer l'histoire et les personnages. Mais j'ai bon espoir que ça se fasse un jour ! :)

Pour l'example suite, je n'ai juste rien trouvé d'intéressant à voir. Il n'y a quasi rien… :(

Pour le nexus, là j'ai trouvé 2 mods qui ont l'air sympa pour le gameplay :

• https://www.nexusmods.com/morrowind/mods/42332?tab=description
• https://www.nexusmods.com/morrowind/mods/31942?tab=description

Donc je vois que des gens apprécient Morrowind tout en ayant envie d'un gameplay plus orienté Oblivion ou Skyrim, c'est cool. :-)
Les modifications à apporter au jeu original ne sont pas nécessairement énormes finalement, vu que dans la nouvelle version d'OpenMW on peut récupérer des objets plantés dans le décors…

Vivement la version 1.0 et la version 100% libre ! \o/

Attention, je parlais des "avantages de C++" par rapport à d'autres, pas de ceux de Rust. ;)

Et oui, il n'a pas la maturité de C++… est-ce réellement une bonne raison pour ne pas le choisir, je suis pas sûr. Tout langage sorti après C++ est forcément moins mature. Et pas que je sois un prosélyte de Rust, mais il a déjà fait parlé de lui en bien dans des projets de très grande ampleur, notamment parce qu'il est mieux pensé que C++ sur pas mal d'aspects.

L'écosystème est moins fourni, d'accord, mais les bibliothèques C (voire C++) peuvent être réutilisées en Rust (ok pour C++ c'est un peu pénible, mais faisable), donc bon, là encore, pas un très bon argument.

Et quant au manque de développeurs formés, là encore, c'est pas un super argument, c'est en forgeant qu'on devient forgeron. Je conçois que dans quelques cas il soit compliqué de trouver un peu de temps pour apprendre un nouveau langage, mais ça ne devrait pas être la norme.

Toutes mes félicitations concernant OpenMW. C'est juste dingue tout ce qui a été fait, tout le chemin parcouru, les améliorations énormes par rapport au jeu originel.

Aussi, j'ai deux petites questions (si quelqu'un sait).

1. J'ai essayé d'y jouer mais je n'ai pas le jeu original. Je me demande quand on pourra avoir une version d'OpenMW qui n'a plus du tout besoin des assets originaux. C'est pas que 15€ sont impossibles à fournir pour un jeu de cet ampleur, juste par principe j'aurai aimé avoir un jeu 100% libre, qu'on puisse même installer à partir des dépôts de sa propre distribution/OS.

2. Je n'apprécie pas le mécanisme de combat dans ce jeu. C'est la seule chose qui me gène dans Morrowind, les combats se font façon jeu de rôle à base de dés lancés, ce qui a été largement amoindri par la suite avec Oblivion où les combats se faisaient en temps réel. Je trouve cela beaucoup plus immersif. Du coup je me demandais si quelqu'un avait prévu de changer le gameplay à ce niveau, ce qui clairement demanderait un énorme travail d'adaptation bien évidemment… mais qui sait, c'est peut-être déjà fait dans un recoin obscur de l'Internet ?

En tout cas, c'est vraiment impressionnant. Bon courage pour la suite.

Des avantages que tu listes, je ne vois rien qui soit un réel frein à l'usage de Rust. Bas niveau, possible réutilisation des bibliothèques C/C++, le langage peut parfaitement être stable dans le temps bien qu'il soit encore jeune. Pour moi c'est tout bon.

Je ne sais pas si c'est pareil pour vous, mais apparemment je ne peux pas accéder au site en question. Est-ce qu'ils auraient fait un très joli rétro-pédalage ?