Réunion du 06-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 pour 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 un 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éunion.
• Janus Beg a listé les 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 elles 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épendances 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 [1].
• 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[2].
• 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  : JSON : JavaScript Object Notation (JSON) est un format de données textuel dérivé de la notation des objets du langage JavaScript. Linden Lab Structured Data (LLSD) : LLSD fournit un système de données flexible similaire aux systèmes de données des langages dynamiques tels que Perl et Python. Il prend en charge l'échange de données structurées entre des systèmes séparés. MessagePack est un format d'échange de données informatique. C'est un format binaire qui permet de représenter les structures de données simples comme les tableaux et les tableaux associatifs. MessagePack a pour objectif d' être le plus compact et le plus simple possible.

Bugs

Problème de texture/inventaire

Question

• Est-il possible que le chargement des textures dans le monde lors de la connexion puisse déclencher le même problème de texture/inventaire que celui observé ?

Réponse

• Nous n'avons pas vu de problème de texture/inventaire...Les textures dans le monde sont pour la plupart séparées de l'inventaire. Les textures sont des assets.
• Les crashs de l'inventaire sont du côté viewer et ne concernent peut-être que Firestorm.

Erreur de serveur HTTP dans OpenSimulator

Question et description du bug

• Cuga Rajal voit occasionnellement une exception dans la console du serveur HTTP d'OpenSim.

   [BASE HTTP SERVER]: OSHttpServer.OSHttpListener had an exception System.Net.Sockets.SocketException (22): Invalid argument
   at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, Boolean disconnectOnFailure, String callerName)
   at System.Net.Sockets.Socket.UpdateStatusAfterSocketOptionErrorAndThrowException(SocketError error, String callerName)
   at OSHttpServer.OSHttpListener.AcceptLoop() in /Users/cuga/opensim/OpenSim/Framework/Servers/HttpServer/OSHttpServer/HttpListener.cs:line 145

• Le serveur HTTP s'éteint, mais le serveur continue de fonctionner en pensant que tout va bien. La région reste inaccessible jusqu'à l'arrêt manuel et le redémarrage. Il y a un thread suspendu qui nécessite un arrêt depuis la console.
• La région est redémarrée tous les quelques jours. Cela n'arrive qu'une fois toutes les deux semaines environ, mais cela fait un an que cela se produit.
• Dotnet est mis à jour régulièrement quand les mises à jour sortent. Version de dotnet8 et trunk sans rien modifier
• N'importe qui peut atteindre ce port avec n'importe quoi.

Réponse

• Il est la possible que le serveur reçoive des requêtes HTTP inattendues, ce qui pourrait causer des erreurs. Des données corrompues ou malveillantes pourraient être à l'origine des problèmes.
• Un proxy pourrait surveiller les requêtes entrantes et l'utilisation un "pinger"[3] servirait à redémarrer automatiquement le serveur. Il faudrait vérifier les journaux système et d'autres ressources pour diagnostiquer le problème.
• Cela pourrait être un problème spécifique à macOS, il faudrait vérifier les journaux du système macOS. Gavin Hird donne un lien qui indique comment augmenter les limites de ressources du système ( le nombre de fichiers ouverts par processus) sur macOS.

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é une solution de contournement en réglant sur false un paramètre de débogage d'AISv3 [4]. 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 [5] 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