gasche a écrit 1151 commentaires

Par exemple tu mentionnes les debordements de tampons ("buffer overflow"). Selon les cas, un bug de ce type peut:
- soit permettre l'execution de code arbitraire, auquel cas les bonnes vieilles techniques dites ASLR et DEP (liens dans mon journal) limitent les possibilites d'y parvenir mais pas a 100%, et le sandboxing limite les possibilites pour du tel code d'agir sur le reste du systeme mais comme il y a deja plein de choses a manger a l'interieur du sandbox, c'est pas forcement un probleme pour l'attaquant.
- soit conduire a un bete plantage, ce qui est un cas de deni de service, et la non plus aucune des techniques envisagees n'est utile.

C'est vrai que les techniques d'isolation ne peuvent pas transformer une faille de sécurité en non-bug: un bug reste un bug et dégradera toujours localement la qualité du service. Cependant une compartementalisation assez fine peut souvent limiter les nuisances possibles; par exemple si un composant plante, on peut souvent faire un choix par défaut raisonnable et le relancer, sans mettre en danger l'ensemble du système; de même si la granularité est assez fine les "choses à manger" ne présentent pas de risque (par exemple on ne veut pas qu'une exécution arbitraire de code dans le code qui affiche des images puisse accéder aux mots de passe stockés en mémoire par le gestionnaire de clés du navigateur).

• soit permettre aux scripts d'acceder en lecture ou en ecriture a de la memoire arbitraire, auquel cas aucune des techniques mentionnees ci-dessus n'est utile!

Si justement, une isolation assez fine (pour cela il faut de l'information sur quels scripts correspondent à quels principaux) permet de faire tourner des parties du système avec des droits restreints, et donc en particulier d'utiliser des protections mémoires pour éviter ces difficultés; un compartiment donné pourra accéder à et corrompre la mémoire qui lui est propre, mais si l'architecture est bien pensée on a seulement un échec local du compartiment, ou injection de résultats faux (ce qui peut contaminer les compartiments communicants en provoquant des erreurs de leur côté, ce qui est bien sûr toujours possible, mais c'est un cas plus rare).

Les programmeurs de chez Mozilla ne sont pas des "programmeurs lambda"; un monde dans lequel tous les programmeurs seraient aussi cultivés que les gens qui font Rust aujourd'hui serait un paradis, relativement parlant.

Ce que tu vois c'est plutôt l'effet lent des gens qui ont fait un peu de recherche (par exemple une thèse) dans des domaines proches des langages de programmation, qui atteignent l'industrie, et qui y font des marques. Les gens de mozilla sont assez ouverts aux expériences de ce genre (cf. leur travail sur l'analyse statique de C++) et on y retrouve donc beaucoup d'idées qui viennent de ces milieux -- cf. par exemple Chris Double, qui fait du Dylan, Factor, ATS...

Qui sait, peut-être qu'un jour, on trouvera des preuves Coq dans les dépôts de source Mozilla ?

Je ne connais pas Rust mais j'imagine que s'ils disent que le GC est "optional" il doit bien y avoir moyen d'allouer et désallouer à la main. En tout cas c'est le cas en ATS, le langage système intéressant du moment (mais pas orienté concurrence).

"vous proposez quoi sur le terrain technique ?" C'est bien simple: on resout les bugs au cas par cas. Je sais que vu de loin, comme ca, on prefere croire a des solutions miracles qui elimineraient d'un coup toute un classe de vulnerabilites. Mais dans la realite, pour la grande majorite des bugs, il n'y a pas de telle solution miracle. Chaque bug doit etre compris et repare separement.

Je ne suis pas du tout d'accord. Je ne suis pas un expert en sécurité mais je vois de temps en temps passer des annonces de failles de sécurité, et dans l'extrême majorité des cas on peut les classer dans des "grandes familles" de bugs qui pourraient être tout à fait éliminées par une architecture plus robuste.

L'exemple typique, ce sont les failles de buffer overflow permises par l'interface de manipulation de chaînes en C. C'est un cas typique, il y a eu des milliers de failles de ce genre et il en reste encore qu'on n'a pas détectées. "Résoudre au cas par cas" c'est la moindre des choses, mais utiliser d'autres outils pour manipuler les chaînes c'est encore mieux, et d'ailleurs le logiciel écrit dans des langages de plus haut niveau qui font de la vérification des accès aux chaînes/tableaux n'ont quasiment jamais ces failles. On a donc bien un changement d'architecture qui éradique complètement un problème de sécurité.

C'est encore la même chose pour les failles d'injection SQL, qui sont liées à une interface rétrograde choisie à la frontière entre le langage serveur et la base de donnée.

Les exemples 1 ou 3 dans ton billet sont typiquement des choses qui pourraient être corrigées si l'architecture était plus solide. Ce sont des exemples du fait que sur une page web, les principaux (au sens de la littérature de sécurité, les agents ayant des intérêts différents) ne sont pas bien identifiés. Avec une architecture ou les principaux sont identifiés, et les éléments de la page sont compartimentés selon le principal auquel ils appartiennent, le DoS ne serait pas un problème (il suffit de limiter les ressources par principal, et de laisser l'utilisateur décider en cas d'abus) et les attaques cross-domaines seraient beaucoup plus difficiles. Il y a des gens qui travaillent sur ça, par exemple le projet Google Caja que j'ai déjà cité.

Je ne dis pas que c'est un problème facile à résoudre, ce n'est pas du tout le cas, surtout avec l'architecture (assez faible) actuelle (des navigateurs, mais surtout des langages de contenu et de script) et les contraintes de standardisation et de compatibilité très fortes. Mais ce sont bien des erreurs au niveau architectural que l'on pourrait régler en très grande partie avec une meilleure organisation. Il y a des gens qui travaillent sur ça et qui font des choses intéressantes, qui ont des impacts sur l'industrie.

Il est tout à fait exactement que, dans les navigateurs webs, les attaques internes aux données du navigateur (cookies, scripting cross-domaine etc.) sont au moins aussi préoccupantes que les attaques contre le systèmes (exécution de code), car plus proches du domaine applicatif. Pour la même raison, elles sont plus difficiles à éviter par des mécanismes génériques; ça fait écho de la discussion sur les navigateurs dans la news sur seccomp (sandboxing dans Linux).

Cependant je trouve qu'il y a un peu de déni dans ta réaction. Certes, l'insistance des gens de Chrome sur le sandboxing a aussi des effets marketing; d'ailleurs ton message lui aussi est un message de communication, pas vraiment un message technique. Mais s'ils peuvent se permettre d'insister dessus de façon parfois exagérée, c'est parce que ce choix technique de fond est bon, et que Mozilla est à la traîne là-dessus. C'est un fait, et je trouve bien que les gens de Chrome vous mettent la pression (par des moyens qu'on peut critiquer) pour bouger sur ça : dans le fond c'est une vraie différence technique.

D'ailleurs les failles dont tu parles sont toutes des problèmes de compartimentation/isolation (même le DoS : pour gérer les attributions de ressources il faut avoir compartimenté au préalable). Dans l'architecture actuelle des navigateurs, elles ne correspondent pas forcément à des limites de processus et donc les techniques de sandboxing ne sont pas forcément utiles; par exemple si les cookies ou les objets de scripting vivent dans un espace de nommage global partagé, des attaques sont possibles. Mais dans le fond ça reste un manque de compartimentation, et des architectures différentes (par exemple le choix de multiprocessing de Chrome pour le rendu, ou pour aller plus loin une organisation plus "everything is a file" à la Plan9) pourraient rendre ça accessible aux techniques systèmes standard d'isolation.

Bref, pour moi ton message se lit comme un "ouin les gens de Chrome ils sont vilains, ils se font mousser sur leur sandboxing mais en vrai c'est pas la seule solution à tous les problèmes". Peut-être mais en attendant vous proposez quoi sur le terrain technique ? Les gens de Google poussent l'état de l'art en matière de sécurité sur les navigateurs (Google Caja, Capsicum, le travail de Mark Miller sur la standardisation de Javascript), ce ne sont pas les seuls, mais ils font du bon boulot. J'attends avec impatience que les gens de Mozilla fassent eux aussi des avancées dans le domaine, mais il faudra un peu plus qu'un simple "oui mais c'est que de la communication".

Ça ne suffit pas : il faut en plus appliquer le principe d'autorité minimale. Ton client de conversation a beau juste être un client de conversation, il va quand même faire du parsing pour afficher les messages reçus du serveur. Le code de parsing en C est propice aux buffer overflow. Statistiquement, dans ton système, il a presque toujours du code qui tourne sous ton autorité et qui contient une faille de buffer overflow, "une seule chose bien" ou pas.

Une fois que tu as une faille, la question est de savoir ce que l'attaquant peut faire avec. Avec le système de sécurité UNIX classique basé sur les droits utilisateurs, un attaquant peut faire tout ce que l'utilisateur peut faire. Donc une faille dans le code de parsing de ton serveur de messagerie peut être exploitée pour lire tes fichiers, les effacer, envoyer des messages sur le réseau comme tu le fais, etc. C'est un défaut de sécurité immense qui touche tous les systèmes d'exploitation mainstream actuel, et que l'on essaie de tempérer de l'extérieur, avec des politiques systèmes pour créer des contextes d'exécution restreint.

Bref, ces deux aspects sont indépendants: ton idée de minimiser les fonctionnalités permet de réduire la surface de vulnérabilité (en ayant simplement moins de code), mais pas le danger lié à une vulnérabilité donnée (et comme ton système reste assez gros, tu es donc en danger); permettre aux applications d'abandonner les privilèges permet, à quantité de code potentiellement buggué constant, de diminuer le danger, donc la surface d'attaque effective.

Après le design UNIX dont tu parles revient à mettre en place une forme de compartementalisation. C'est bien, car il est plus facile ensuite d'abandonner des privilèges : quand le logiciel est bien conçu, il est découpé en parties indépendantes qui correspondent à la fois aux fonctionnalités et à l'autorité nécessaire pour le fonctionnement. Donc on peut juste dire "dans tel sous-programme je me contente de tels droits", et on obtient déjà un découpage assez fin (ce qui n'est pas forcément pas vrai pour du logiciel spaghetti ou le traitement de tel ou tel aspect est éparpillé tout au long du programme).

Non, l'abandon de privilège peut être fait au sein de libpng, de façon purement locale. Par exemple libpng pourrait choisir de forker un thread pour parser les headers (opération notoirement sensible aux buffer overflow comme tout ce qui touche aux chaînes en C) qui, à la naissance, abandonne tous ses privilèges sauf celui de renvoyer des données correspondant au header sur un pipe pour son papa. Une faille de sécurité dans ce code de parsing de headers sera donc probablement sans danger¹.

Je n'aime pas trop le mot "sandbox" car il fait penser à un changement de contexte à un coup, qu'on peut utiliser quelque part une seule fois et c'est fini. L'abandon de privilège de capsicum ou seccomp_filter est composable, peut se répéter pour s'affiner encore. Si les tâches qui utilisent libpng ont déjà abandonné une partie de leurs privilèges pour la partie de leur travail qui appelle libpng, c'est tant mieux, mais dans tous les cas libpng peut se re-compartimentaliser en interne, pour gérer les droits restants avec une granularité plus fine.

¹: dans le sens où une exécution de code arbitraire ne sera pas possible; par contre un attaquant peut injecter le header qu'il veut, et parier sur un bug ensuite de traitement du header. C'est à regarder avec soin, mais le gain de sécurité lié à l'abandon de privilège reste très important (on passe de "hop avec une image craftée je peux te pousser à formater ton /home/foo" à quelque chose de beaucoup moins dangereux dans le cas courant).

Dans son premier mail BPF, Will Drewry explique longuement pourquoi il pense que ftrace/perf n'est pas l'endroit adapté. Je t'invite à aller lire son explication qui est très complète. Sa conclusion :

At every turn, it appears that the tracing infrastructure was unsuited
for being used for attack surface reduction or as a larger security
subsystem on its own. [...] It doesn't mean that it has security problems, just that
there will be a continued struggle between having a really good perf
system and and really good kernel attack surface reduction system if
they were merged.

seccomp_filter permet à une application de dire au noyau : "à partir de maintenant, je n'ai plus besoin de l'appel système ; si je l'appelle par mégarde (par erreur ou parce qu'un utilisateur malicieux me pousse à le faire), interdis-le s'il te plaît, pour m'empêcher de faire des bêtises". En fait c'est plus fin que ça, il peut dire "je vais utiliser cet appel mais seulement sous telle et telle condition, le reste tu me l'interdis".

C'est le développeur de l'application qui insère ces appels à seccomp, donc qui décide d'abandonner certains de ses privilèges. S'il se trompe et en fait l'application avait bien besoin de cet appel, l'appli va planter; mais ça c'est un bug qu'il va (on espère) repérer pendant le développement. Dans le cas normal, les droits sont limités mais personne ne s'en rend compte, puisque l'application n'essaie pas de les utiliser de toute façon. Et si on repère un bug ou une faille de sécurité dans le logiciel après cet abandon, on a une meilleure idée de ce qui peut se passer, et surtout de ce qui ne peut pas se passer : une tranche entière de "mauvais comportement" est exclue. Par exemple si l'application abandonne son droit à lire le système de fichier (sauf /tmp), on sait que le bug n'autorisera pas un attaquant à lire mes fichiers de configuration.

L'utilisateur lambda n'a même pas besoin de savoir que cette protection existe. Il en entendra seulement parler quand il lira "une faille a été détectée dans libpng, sous Windows elle permet l'exécution de code arbitraire, mais sous Linux ou FreeBSD elle est inoffensive car à cet instant le processus de rendu n'a plus aucun droit".

Excellente remarque, j'ai été surpris (je n'avais pas fait attention). J'ai envoyé un mail pour me plaindre demandant plus d'information au support HIB, et voilà la réponse:

Instead of simply going with the standard two charities, we discussed the charities with the HIB #4 game developers and after a lot of thought, these charities emerged. With the addition of a great charities, American Red Cross, the tough decision was made to not include the EFF in HIB #4. This doesn't express any change in our support for the EFF and what they stand for; we will likely include them in future bundles. If you would like, please consider donating to the EFF independently of the bundle at www.eff.org.

Also, when you're choosing how much to give to the charities, you can open up a slider and choose each charity specifically.

Bref, il sera sans doute toujours possible de donner à EFF pour les prochains Humble Indie Bundle .

... si tu veux.

J'ai au moins corrigé la documentation de la syntaxe markdown (section "Paragraphes").

En lisant ça, j'ai eu envie de faire un don à EFF; en fait ça ne marche pas, le transfert bancaire échoue pour une raison bête mais bref, l'intention est là. En attendant que ça marche, je leur mettrai une grosse part sur mes prochains achats de Humble Indie Bundle.

Note que
1) les applications web prennent de plus en plus d'importance
2) Chrome supporte déjà Capsicum
ça fait déjà une adoption très importante..

Oui mais il y a un soucis de couches d'abstractions. Les failles de sécurité dans les applications web ne sont pas forcément dans l'interaction avec les appels systèmes de l'OS hôte. Il y en a (des exécutions de code arbitraire sur des images JPEG ou quoi), mais ce n'est pas vraiment du ressort des "applications web" qui tournent dans le navigateur. Celles-ci s'inquiètent plus des attaques cross-domaines, des cookies abusifs, des failles d'injection de scripts, etc., et tout ceci ne se voit pas au niveau de Capsicum par exemple.

On peut faire des couches de sécurité inspirées des capabilities au niveau du Web. C'est ce que je fait le projet Google Caja par exemple, qui est un travail remarquable (son auteur principal, Mark Miller, fait des capabilities depuis longtemps et participe maintenant au comité Javascript). Mais c'est à un autre niveau, et il faut les deux pour être sécurisés.

Les développeurs que QEMU, LXC et vsftpd se sont déjà fait entendre sur seccomp_filter, donc je pense que le message est passé; de plus les communautés des couches supérieures sont relativement peu habituées à bosser avec le noyau ou sur les points de sécurité, donc ils ne sont sans doute pas trop au courant de ce qui se discute et des avantages que ça pourrait leur apporter.

Au niveau de la "compatibilité" Capsicum, ça n'est pas envisagé pour l'instant. Les gens qui poussent seccomp_filter ont fait le choix explicite de ne pas parler de Capsicum, parce qu'un port Capsicum serait trop invasif et que les devs kernel (à raison) sont très conservateurs. Ils préfèrent pousser des amélioration incrémentales des mécanismes existants pour obtenir quelque chose d'intégré, et faire valider chaque étape. Quand on voit le mal qu'ils ont à avancer sur une fonctionnalité plus modeste, on se dit que c'était le bon choix.

La question de la compatibilité pourrait être intéressante, mais le mieux pour l'instant c'est d'espérer que les fonctionnalités soient là, quelle que soit l'interface. De toute façon, adapter son code de sécurité aux différentes interfaces des différents OS, les devs Chromium par exemple sont déjà obligés de le faire aujourd'hui. Le travail sur seccomp_filter ne peut qu'améliorer leur situation -- il vaut mieux avoir avoir à maintenir deux codes différents de 100/200 lignes, plutôt qu'un code de 100 lignes et un code à 11 000.

Ce que je voulais dire c'est que c'est plus les chercheurs Capsicum qui ont poussé leur truc dans FreeBSD que les devs BSD qui ont pullé le travail de Capsicum; aujourd'hui la communauté FreeBSD découvre ce nouvel outil et se demande ce qu'elle va en faire. Enfin comme un des chercheurs Capsicum (Robert Watson) est aussi un dev. FreeBSD de longue date, les cartes sont un peu brouillées. De toute façon l'important c'est que ce soit dedans.

Je viens de tomber sur ce rapport de bug qui indique qu'il y a de l'intérêt pour cette fonctionnalité du côté de la Ubuntu Server Team. C'est assez logique puisqu'ils essaient de renforcer leur offre "Cloud", et la sécurité de la compartementalisation (ici de LXC) est importante. On retrouve des développeurs qui ont participé à la discussion sur la mailing-list du noyau, Serge Hallyn et surtout Kees Cook.

Sous ses dehors trollesques, c'est une question qui mérite en effet d'être posée. Ce n'est pas l'avis général mais je suis personnellement convaincu que Capsicum (ou équivalent) est une fonctionnalité majeure qui pourra être amenée à de gros gains en sécurité pour les utilisateurs. C'est un atout de FreeBSD aujourd'hui (pas forcément par choix de la communauté FreeBSD d'ailleurs, il se trouve juste que les chercheurs qui travaillent sur Capsicum connaissent bien FreeBSD, et les gens de Google travaillent dessus aussi), qui contrebalance peut-être d'autres atouts du noyau Linux.

Le problème c'est que cette fonctionnalité d'abandon de privilège ne sera pas utilisée en pratique dans les applications tant qu'elle ne sera pas disponible à un minimum d'utilisateurs. C'est bien que des gens essaient de convertir lentement les couches inférieures de l'userspace FreeBSD vers Capsicum, mais pour moi les vrais bénéfices se feront sentir quand de grosses applications utilisateur, KDE ou Gnome par exemple, commenceront à l'utiliser. Et il sera difficile de justifier cet effort d'adoption dans ces communautés tant que le code sera limité à FreeBSD, et qu'il n'y aura pas de fonctionnalités équivalentes (au moins partiellement) sous Linux.

Bref, pour ce genre de fonctionnalités de sécurité, on ne peut pas raisonner dans son coin, pour en profiter vraiment il faut que le maximum de gens l'adoptent.

Certes, et le but de la dépêche n'est pas de râler sur les développeurs noyaux. Par exemple je pense que Zijlstra a bien fait de mettre son veto sur le tracing, d'ailleurs même Drewry en est aujourd'hui convaincu.

On a quand même de la sympathie pour ce dernier quand il se retrouve coincé entre deux mainteneurs qui émettent des avis si contradictoires. Tout le monde était frustré, je pense, par les blocages sur cette fonctionnalité qui pourrait devenir très importante -- je suis amusé de voir que je suivais l'histoire en parallèle avec Jonathan Corbet, on pourrait presque croire que la dépêche est une traduction des articles LWN.net correspondants.

Tout à fait, et c'est ce que j'avais essayé de dire dans la dépêche Capsicum:

Plus généralement, les approches par Mandatory Access Control (SELinux) et par capacités sont complémentaires : le MAC vise à permettre à un administrateur système de contrôler les droits selon les besoins de son environnement, alors que les capacités servent au développeur pour contrôler les droits selon les besoins de son application.

Comme SELinux et compagnie sont aujourd'hui les seules options disponibles, on essaie de les faire jouer sur les deux tableaux (et SELinux est assez expressif pour le faire, au moins en partie), mais dans l'absolu on veut que les deux méthodes cohabitent. Quelque chose comme Capsicum reste beaucoup plus flexible puisqu'il peut être géré directement au niveau de l'application (qui sait à partir de quand elle n'a plus besoin de certains droits, par exemple, sans transition observable par une politique MAC), et les transferts dynamique de droits du style capabilities (pas (encore?) permises par seccomp_filter par contre) sont à une granularité encore plus fine, qui serait difficile à codifier par MAC (déjà pas facile à administrer).

Le but d'une option est justement de permettre aux gens de faire un choix non-majoritaire dans les cas où les différentes possibilités sont également désirables. Étant moins visibles que le choix par défaut, il me semble tout à fait normal qu'elles soient utilisées par une minorité, mais ça ne veut pas dire qu'elles ne sont pas légitimes.

Dans l'exemple concret présent, il n'y avait vraiment aucune raison d'activer le hard-wrapping (d'ailleurs tu étais toi-même contre), en violation de la spécification Markdown, autre que les râleries de certains utilisateurs bruyants. D'autres utilisateurs (saintamand, Xavier Claude, ʇpooɹquooɥɔs sɐȷoɔᴉu, moi...) préféraient ce qu'il y avait avant et sont gênés par ce comportement.

Il ne s'agit pas de modifier la logique interne du site de façon compliquée, juste d'activer ou non un flag dans le moteur markdown, qui est externe. Le patch nécessaire serait donc petit et facile à débugguer.

Si ça peut te faire changer d'avis, je suis prêt à m'occuper du développement et de la maintenance de cette option.

Par ailleurs, quel que soit le choix qui est fait, on pourrait ajouter un bouton "saut de ligne" à la barre WYSIWYG-like.

Parce que les bons sont faits pour aller dans le public et c'est forcément une erreur de faire le choix d'aller dans une école privée ? C'est pas un préjugé ça ?

Quitte à avoir des préjugés, je préfère ceux qui sont gratuits et qui vont dans le sens du renforcement de l'enseignement public, afin de ne pas devoir un jour classer l'informatique parmi les matières indignes comme le commerce où on est forcé d'aller dans le privé, avec les effets évidents sur la sélection sociale que cela implique.

Ce sont aussi des préjugés raisonnablement confirmés par les faits : je connais plusieurs personnes qui sont parties dans des écoles privées de ce genre, et la grande majorité d'entre elles en sont maintenant déçues et désabusées -- même si le LRDE a certainement des projets intéressants; la recherche ça peut être très cool, même dans le privé.

ça ne m'intéressait pas de perdre deux ans à faire des maths/de la physique à longueur de journée

Un choix discutable, mais c'est ton problème. Les maths c'est quand même utile aussi dans plein de domaines en info; si on est motivé, on peut très bien aller en prépa en continuant à faire de l'informatique en autodidacte, quitte à accepter d'aller ensuite à la fac plutôt que dans une école d'ingénieur qui sélectionne sur des matières que tu as moins bossées.

Là ma rentrée est dans deux semaines, je vais passer ma nuit (c'est à dire jusque demain 8h) avec des amis dans les locaux de l'école à bosser sur du matériel marrant qui a été financé par EPITA (une board SMP ARM pour faire du kernel dev, une board avec un Spartan 6 pour faire joujou avec du Verilog).

Dans le public il y a tout à fait moyen de travailler sur des matos exotiques si tu fais de la compil. par exemple (cf. les stages sur les VLIW dans les labos autour de l'Ensimag, les gens qui travaillent sur les optims GCC sur processeur Cell, etc), avec du bon matériel (les labos ont un budget matériel raisonnable en général). Il suffit d'être motivé et compétent et d'envoyer un mail aux chercheurs pour obtenir un stage (pas forcément rémunéré, mais si tu économises 7000 euros l'année ça reste rentable).

Par curiosité (même si ça une réponse positive ne justifierait pas le choix, pour les raisons ci-dessus), est-ce que le matos dont tu parles coûte plus cher au total que tes frais d'inscription globaux (sur toutes les années que tu y passes) pour cette école ?

Ce que j'ai beaucoup apprécié dans cette école, c'est qu'on apprends vite à se débrouiller. [...] on découvre un nouvel ami : Google. Et on comprend vite qu'il va nous accompagner durant toute la scolarité et même après. C'est très autodidacte. Cela n'est certainement pas adapté à tout le monde, mais c'est exactement ce qu'il me fallait.

Tu paies 7000 euros l'année pour chercher les réponses à tes questions sur Google ? C'est marrant, j'ai jamais eu besoin de payer pour être autodidacte... Mais peut-être que quand on est en plus endetté jusqu'au cou, c'est plus motivant ?

(Évidemment, je ne te critique pas personnellement, mais le système d'enseignement privé où les gens paient pour des écoles "connues" alors qu'ils pourraient très bien apprendre la même chose dans le public.)

Un jour surtout, les gens arrêteront d'aller dans des écoles privées pour se faire pomper du fric alors qu'ils auraient pu avoir beaucoup mieux dans le cadre de l'enseignement public. Tu as choisi d'aller à Epit{a,ech} volontairement, tu te fais chier sur place, et tu te demandes après pourquoi les gens critiquent l'école ?

Quand on va (volontairement ou non) à un endroit où les gens achètent leur diplôme pour galérer ensuite s'ils veulent, par exemple, continuer dans la recherche (tiens t'as un master pro...), après les gens ont des préjugés, c'est normal.

La minorité de bons, c'est une erreur d'orientation.

Mais les outils comme Etherpad ne font pas de rendu de la mise en forme. Et ça risque d'être lourd si ça doit être fait à chaque caractère modifié.

Rien n'impose de le faire à chaque fois, on peut avoir un bouton de prévisualisation qui lance le rendu à un instant donné. Enfin on pourrait sans doute aussi le faire à chaque caractère modifié, avec une bonne implémentation ça va vite. Mais markdown est pensé pour être lisible sans faire de rendu, donc il n'y a pas besoin.

Je pense qu'on pourrait intégrer quelque chose comme ShareJS à LinuxFR, si Bruno Michel était prêt à déployer ça.

J'ai créé une entrée de suivi à part.