Réunion du 20-08-2024

Changements du code de la semaine

Certificats SSL auto-signés

Ubit Umarov a intégré les Pull-request d'Adil El Farissi

Ces pull-request ajoutent du code pour faire des certificats auto-signés en utilisant les outils dotnet. La création de certificats auto-signés SSL à chaque démarrage d'une standalone est une solution pratique et efficace pour gérer les adresses IP non-fixes ou les changements d'environnement et utiliser SSL avec une Standolone.

• Commit c2c3ca] : Implémentation de la création et du renouvellement de certificats SSL auto-signés.
• Commit ac9ed3: Ajout du support des certificats auto-signés à Robust, à osGetLinkInventoryKeys plus quelques corrections.
• Commit 207c3d: Rétablissement de certains paramètres par défaut et correction du support SSL

NDLR  : Pull-request (PR) : Lorsqu'un développeur souhaite intégrer ses changements dans la branche principale d'un dépôt, il crée une pull request. Cela permet aux autres membres de l'équipe de revoir, commenter et discuter des modifications avant qu'elles ne soient fusionnées dans le code principal.

Il faut noter que bien que des efforts aient été faits pour intégrer le support SSL, il n'est pas encore entièrement fonctionnel. Dans ces cas, il peut y avoir des redirections entre les connexions sécurisées et non sécurisées. Il reste encore beaucoup de travail à faire pour que tout cela fonctionne correctement.

Extension du code

• Commit 79dbca : Quelques modifications. Dans certains cas, il est difficile de savoir si une ressource utilise HTTP ou HTTPS. Il se peut que les deux soient nécessaires, avec éventuellement une redirection de HTTP vers HTTPS. TODO
• Commit 8eef70 : ... Dans certains cas, il est impossible de déterminer si une ressource utilise HTTP ou HTTPS. Il se peut que les deux soient nécessaires, avec éventuellement une redirection de HTTP vers HTTPS.TODO
• Commit 4a72e9 : Correction de la vérification de l'option EnableSelfsignedCertSupport.

Avertissement

Attention : Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux réunions du mardi ou sur le canal IRC. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉

Modules

Module de chat vocal

• Ubit Umarov a examiné WebRTC et il a testé la fonctionnalité de communication peer-to-peer (P2P) dans Second Life. Cependant, il a constaté que Second Life ne propose pas cette fonctionnalité, mais uniquement la voix sur les parcelles pour la grille principale.
• Second Life a changé le code de la voice 2 jours avant la réunions.
• Janus Beg a listé kes régions de Second Life où tester WebRTC sur l'un de ses blogs ou dans les annonces bêta. Il y en a 4 et elle doivent se nommer webrtcx1 à 4.

Noyaux

Problème de sérialisation binaire obsolète : sécurité et gestion des données

Le problème posé

• Mike Chase soulève un problème concernant la sérialisation binaire, qui est obsolète depuis .NET 5 et qui pose des problèmes de sécurité. Il pense qu'il est nécessaire de revoir la manière dont les données sont sérialisées dans OpenSimulator, en tenant compte de la grande quantité de données héritées qui utilisent actuellement cette méthode (assets, etc.). Il invite les autres à réfléchir à une solution globale.

NDLR  : La sérialisation est le codage d'une information sous la forme d'une suite d'informations plus petites pour, par exemple, sa sauvegarde ou son transport sur le réseau. L'activité réciproque, visant à décoder cette suite pour créer une copie conforme de l'information d'origine, s'appelle la désérialisation. Sérialisation binaire : est le processus de conversion d'objets ou de structures de données en un format binaire, qui peut être facilement stocké ou transmis. La sérialisation binaire peut poser des problèmes de compatibilité et de sécurité. Sérialisation textuelle : sérialisation lisible, plus facilement validés, plus simple ce qui réduit les risques, interopérabilité. Exemple JSON ou XML.

Discussion

Point de vue de Mike Chase

• Mike Chase commence tout juste à examiner le problème. Il a peur d'avoir des problèmes pour mettre à jour au-delà de dotnet 8 si une solution n'est pas trouvée. Il pense qu'il pourrait y avoir des dépendance qui suppriment du code même dans dotnet 8. Il va commencer à chercher des aternatives et reste ouvert aux solutions décrites par Ubit Umarov.
• Pour lui le problème réside surtout dans l'injection lors de la désérialisation.
• La suggestion de Microsoft est de passer à la sérialisation JSON.
• Il dit qu'une première étape serait de faire l'inventaire de ce qui est affecté, il va commencer par là.
• Quand il aura mieux cerné le problème il compte revenir avec quelques suggestions.

Point de vue d'Ubit Umarov

• Ubit Umarov pense que la sérialisation binaire n'est pas un gros problème de sécurité. Il dit que jusqu'à présent tout fonctionne avec dotnet 8 et que le problème de sécurité est lié à la sérialisation automatique ou pire à la désérialisation faite par Microsoft.
• Si un jour il y avait un problème de compatibilité, il pense qu'il faudrait simplement « cloner » le code actuel pour que tout fonctionne avec les assets actuels.
• Il pense également qu'il faudrait avoir une sérialisation binaire pour toutes les communications.
• Il est contre l'utilisation d'une alternative telle que Linden Lab Structured Data (LLSD) proposée par Joe Magarac. Il n'est pas plus intéressé par JSON ou XML.
• Il propose MessagePack comme standard de format d'échange de données informatiques.
• Il est d'accord avec Joe Magarac et confirme que la sérialisation binaire est plus un problème pour les communications interrégion et pour les services de la grille.

Point de vue de Joe Magarac

• Joe Magarac utilise XML LLSD, Notation LLSD, et binary LLSD écrit en Rust. Il donne le lien d'une implémentation de LLSD en Rust[1].
• Il dit que le problème avec la sérialisation textuelle est que les données de type OpenSim/Second Life contiennent beaucoup de flottants, et que la conversion de ces données en chaînes de caractères et inversement est coûteuse et encombrante.
• Il dit que la sérialisation n'est pas un problème de viewer.

Informations complémentaires

NDLR  :

Bugs

Problème de texture/inventaire

• 🏗️

Erreur de serveur HTTP dans OpenSimulator

• 🏗️

Viewers

Crashs de FS 7.x

Problèmes

• Sur le JIRA de Firestorm il semble que les utilisateurs rapportent des crashs sur les versions Firestorm 7.x .
• Le problème c'est qu'ils ne disent pas s'ils testent la versoion alpha ou une version plus ancienne. Ubit Umarov n'a pas de crash sur les versions beta/alpha récentes.

Solutions

• Ubit Umarov a étudié les raisons des crashs de FS 7.x quand le cache est vide, il a recherché une requête de Firestorm envoyée pour récupérer l'inventaire au moment de la connexion.
• Mike Chase, signale qu'il a trouvé un solution de contournement en réglant sur false un paramètre de débogage d'AISv3 [2]. Ubit Umarov pense que cela ne devrait pas avoir d'impact. Mike Chase confirme mais il maintient que cela a un impact probablement dû à l'absence de capability.

NDLR  : Mike Chase : développeur du fork OpenSim_NGC

• Ubit Umarov a identifié le changement de code nécessaire pour permettre le chargement complet de l'inventaire à la connexion. La solution consiste sipmplement à commenter un "else" dans le code. Le chargement complet de l'inventaire est particulièrement important pour les utilisateurs qui se déplacent entre différentes grilles (hypergrid). Si les utilisateurs prenaient l'habitude de récupérer tout leur inventaire avant de se téléporter cela ne poserait pas de problème.

NDLR  : Si les utilisateurs prenaient l'habitude de récupérer tout leur inventaire avant de se téléporter : Je ne vois pas bien ce que cela veut dire, attendre que l'inventaire soit complètement enregistré dans la base de données ? Une option que je ne connais pas ? )

Version alpha et beta testées

• Micke Chase est en train de parler avec Beq Janus(Développeur et chef de projet Firestorm) pour obtenir une version alpha claire à tester. Il a le même viewer alpha que Ubit Umarov, c'est à dire la version du 11 Août, un viewer avec WebRTC. D'après Ubit Umarov Beq a apporté un changement aux délais d'inventaire, ce qui a peut-être corrigé les plantages. Le viewer doit être testé. Cela a corrigé le problème pour Ubit Umarov et pour toutes les personnes à qui il a posé la question. Cela concerne aussi la dernière version Beta. Donc tout indique que c'est un problème de delais lié à la manière dont les coroutines sont gérées ou contrôlées dans le code. Cela pourrait cacher un problème plus profond qui pourrait nous toucher plus tard.

NDLR  : Les coroutines [3] permettent de gérer des opérations longues, comme le chargement d'un inventaire, de manière fluide et efficace, sans bloquer l'interface utilisateur.

• Ubit Umarov demande aux utilisateurs de tester la version alpha de Firestorm ce qui permettrait de visualiser tous les problèmes liés au chargement d'inventaire à la connexion. Il dit aussi qu'il qu'il est nécessaire de réduire les problèmes liés à la suitecase utilisée en hypergrid.

Sharpview

• Joe Magarac n'a pas encore touché à l'inventaire.
• Ubit Umarov pense que Sharpview ne sera pas confronté au problème de chargement d'inventaire au démarrage puisque le viewer utilise sa propre gestion des threads en Rust. Il dit à Joe Magarac de noter qu'OpenSim a besoin d'une mise à jour complète du cache à la connexion pour éviter les problèmes de téléportation en Hypergrid plus tard.

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-08-20