concl

_posts/2024-02-06-fosdem.md

@@ -123,8 +123,9 @@ La rétro-compatibilité peut alors s'envisager avec des outils comme [gVisor](h
 
 On pourrait alors imaginer un service de serverless/lambda function sur ce modèle. En gros le principe d'un système de ce genre, c'est de charger le code de l'utilisateur qu'en cas de besoin. C'est un peu la version cloud de [inetd](https://fr.wikipedia.org/wiki/Inetd) si vous préférez. Donc on aurait un daemon web qui écouterait. Lors de la réception d'une requête HTTP, il scannerait le champs Host de la requête et son URL. En fonction de cette dernière, il demanderait à l'orchestrateur de démarrer le service adéquat, et de connecter ses descripteurs de fichier pour gérer la requête/réponse. Là encore, si l'utilisateur veut que son service puisse accéder à des ressources autres, il devra les déclarer au moment de publier son code, et ne pourra pas outrepasser ce qui lui est permis.
 
-Cette idée est partiellement discutée dans un papier intitulé [A capability inspired low level security model based on modern Linux kernels](http://arkanis.de/projects/2013-01%20Capabilities/A%20capability%20inspired%20low%20level%20security%20model%20based%20on%20modern%20Linux%20kernels.pdf). Ma proposition se différencie dans le sens où, pour contourner certaines limitations des descripteurs de fichier, j'envisage des daemons en espace utilisateur qui se chargeraient de réduire le scope.
+L'idée que je présente est partiellement discutée dans un papier intitulé [A capability inspired low level security model based on modern Linux kernels](http://arkanis.de/projects/2013-01%20Capabilities/A%20capability%20inspired%20low%20level%20security%20model%20based%20on%20modern%20Linux%20kernels.pdf). Ma proposition se différencie dans le sens où, pour contourner certaines limitations des descripteurs de fichier, j'envisage des daemons en espace utilisateur qui se chargeraient de réduire le scope. Il est bon de noter, en plus de Capsicum, le cas de [Cloud ABI](https://lwn.net/Articles/674770/). Pour moi, Capsicum, à vouloir moduler ce que fait le descripteur de fichier se trompe : ça doit rester un stream simple, l'important c'est qui il y a au bout. Le projet que j'envisage est justement de définir ces composants (orchestrateur, message bus, etc.) dans un monde où on a que des descripteurs de fichier. CloudABI se concentre uniquement sur la rétro-compatibilité : comment s'assurer que les processus existants, supposant un POSIX/interface de programmation Linux vont bien se comporter et ne vont pas crasher/silencieusement downgrade vers des comportements indésirables (par exemple pour la cryptographie et la génération d'aléatoire). C'est intéressant mais orthogonal.
+
 
 ## Conclusion
 
-J'ai vu deux trois autres choses au FOSDEM. En vrac : j'ai bien aimé [la présentation de Garage](https://fosdem.org/2024/schedule/event/fosdem-2024-3009-advances-in-garage-the-low-tech-storage-platform-for-geo-distributed-clusters/) par Alex, j'ai beaucoup apprécié aussi le lightning talk de Emily Omier [Project websites that don't suck](https://fosdem.org/2024/schedule/event/fosdem-2024-3154-project-websites-that-don-t-suck/) : très pertinent, très bien exécuté. 
+J'ai vu deux trois autres choses au FOSDEM. En vrac : j'ai bien aimé [la présentation de Garage](https://fosdem.org/2024/schedule/event/fosdem-2024-3009-advances-in-garage-the-low-tech-storage-platform-for-geo-distributed-clusters/) par Alex, j'ai beaucoup apprécié aussi le lightning talk de Emily Omier [Project websites that don't suck](https://fosdem.org/2024/schedule/event/fosdem-2024-3154-project-websites-that-don-t-suck/) : très pertinent, très bien exécuté. Plein de monde, de food trucks, de stands, de présentations, je n'ai pas essayé de tout faire : j'ai essayé de me focaliser seulement sur ces deux points. Si vous avez un billet de blog sur votre FOSDEM, je peux le référencer en bas de celui-ci.