Entités de recouvrement

Le mécanisme de recouvrement des objets protégés et des liens dissimulés est en train d’être doucement mis en place.

D’un point de vue théorique, cela répond à deux problèmes similaires.
En entreprise, et pas que, il est recommandé d’utiliser une ou plusieurs autorités de recouvrement lorsque l’on utilise de la cryptographie pour protéger ses données. Les décideurs le prennent souvent comme une contraite et oublient de mettre en place ce mécanisme de restauration des données chiffrées. Et ce mécanisme est différent de celui de restauration classique alors qu’il est perçu comme étant le même. Résultat, lorsqu’un employé critique vient à manquer, ses données, critiques aussi, deviennent subitement inaccessibles. La disponibilité c’est aussi de la sécurité.
Pour différentes raisons, des états plus ou moins démocratiques peuvent imposer la mise en place d’un mécanisme de déchiffrement des données de leurs concitoyens.

Mais, afin de ne pas rompre la confiance, ce mécanisme doit être loyale, c’est à dire public, transparent et vérifiable.

D’un point de vue pratique, la mise en place comprend deux parties.
Il faut commencer par recenser les entités éligibles comme autorités de recouvrement. Pour l’instant dans le code de la librairie en php, la liste de ces entités est renvoyée vide. Les applications peuvent donc commencer à prendre en compte ces entités pour l’affichage public. C’est le cas dans klicty mais pas encore dans sylabe.
Il faut ensuite, lors de la protection d’un objet ou de la dissimulation d’un lien, dupliquer la protection ou le lien pour chacune des entités de recouvrement. Cela revient simplement à faire un partage de la protection pour un objet protégé en duplicant le lien de type k de chiffrement de la clé de session.

Pour terminer, la librairie n’intégrera pas par défaut d’entité de recouvrement. Si des entités sont définies comme tel, ce sera uniquement par choix (ou obligation) de l’entité responsable du serveur.

Intégration des groupes dans la librairie php

Suite à la définition des groupes, l’intégration a commencé dans la librairie php orienté objet.

L’intégration est profonde puisque les groupes sont gérés comme des objets spécifiques comme c’était déjà le cas pour les entités. Une classe dédiée ainsi que tout un tas de fonctions leurs sont dédiés et personnalisés.

Les applications sylabe et klicty vont intégrer progressivement les groupes, notamment dans un module adapté.

Dans le même temps, un groupe fermé étant uniquement constitué de liens d’une seule entité (et cela doit être vérifié), le filtre social est en cours de mise en place. Ainsi, il est possible de restreindre la prise en compte des liens suivant ces filtres sociaux :

  • self : liens de l’entité ;
  • strict : liens de l’entité et des entités autorités locales ;
  • all : toutes les entités, mais avec un classement par pondération des entités.

L’activation du filtre social et donc de la possibilité de le choisir dans le code à nécessité un revue de tout le code de la librairie et des applications. Il reste à vérifier les modules de sylabe.

Intégration d’une partie affichage dans la librairie PHP

Des corrections de buggs sont réalisés dans la librairie nebule en PHP ainsi que dans le bootstrap en fonction des progrès de klicty.

Pour faciliter le développement et la cohérence de l’affichage, la librairie nebule en PHP intègre maintenant une partie ‘display‘ dédiée à l’affichage de petites parties de pages comme par exemple un objet. La gestion globale de l’affichage reste du ressort des applications comme sylabe ou klicty.

Projet klicty

Voici donc venir le projet klicty. C’est un dérivé de sylabe mais en plus spécialisé et donc plus léger aussi. En attendant qu’il ai sont propre blog, voici donc quelques captures. Globalement, il va permettre le partage de fichiers sur Internet, mais bien sûr le moteur c’est nebule

20151031 klicty_-_hôte_bachue_-_2015-11-01_00.41.11Écran d’accueil.

Continuer la lecture de Projet klicty

Gestion des applications au niveau du bootstrap

Le bootstrap était jusque là assez sommaire. Il se contentait de trouver la dernière version valide de l’application en cours puis la chargeait pour affichage à l’utilisateur. Une page spécifique permettait, et permet toujours, de voir les caractéristiques du bootstrap et de son travail à des fins de dépannage, mais sans interaction possible.

20151018 nebule_bootstrap_-_2015-10-18_23.19.21
La page de dépannage du bootstrap. Continuer la lecture de Gestion des applications au niveau du bootstrap

Objet réservé pour les pseudo systèmes de fichiers

Pour les besoins de sylabe et la gestion des équivalents de systèmes de fichiers, un objet réservé à été créé : nebule/arborescence

Il sert de repère pour les points d’entrés des arborescences des systèmes de fichiers. C’est ajouté au wiki Documentation – nebule v1.2 – Objets à usage réservé.

CF : sylabe – blog – Avancement

Messagerie et transfert fondamental d’information

Comme cité dans l’article sylabe – Emulation de messagerie, l’implémentation de certaines fonctionnalités de la messagerie pose problème.

Tout lien f est potentiellement un message. Cette façon de voir est plus fondamentale, plus propre et plus proche de la gestion de l’information. Malheureusement, elle pose quelques problèmes pour certaines fonctionnalités classiques de la messagerie telle que nous l’utilisons tous aujourd’hui. Les problèmes de fonctionnalités ne sont pas graves mais peuvent être perturbants.

Pour commencer, comment marquer un message comme lu puisque cela revient à faire un lien d’un lien, ce que ne permet pas nebule.
Nous sommes ici dans un fonctionnement attendu de la messagerie dans laquelle chaque message est important et doit donc être lu. Ce comportement est différent du message de réseau social qui n’a pas forcément d’importance et n’est pas destiné à être lu impérativement. On distingue le message destiné à la masse des gens, même si elle peut être très limitée, du message destiné spécifiquement à un individu. La notion d’importance dans l’attente de lecture du message dépend surtout du nombre de destinataires.
Il ne faut pas non plus penser que le spammer s’attend à ce que tout le monde lise ses messages. C’est du rêve mais ce genre de message est très peu lu et est donc envoyé en masse pour compenser ce manque d’importance ou d’intérêt.

Ensuite, lorsque l’on marque comme supprimé un message, c’est que l’on supprime explicitement le lien f qui fait que c’est un message. Si on souhaite annuler cette suppression, la théorie dans nebule veut que l’on recrée un lien mais avec une date plus récente. Or si la date est plus récente, cela altère l’information de la date du message. Ensuite, c’est l’entité qui à reçu le message qui génère le nouveau lien à une date plus récente, et non l’entité d’origine. On perd donc la provenance du message. Ce n’est pas acceptable dans ces conditions de permettre la restauration d’un message.

Il est probable que l’on revienne plus tard à une implémentation plus universelle et fondamentale dans la façon de reconnaître ce qu’est un transfert d’information, un message.

Dissimulation de liens, multi-entités et anonymat

La dissimulation de lien tel que prévu dans nebule n’est que la première partie permettant l’anonymisation des échanges entre entités.

Voir les articles précédents :
Liaison secrète et suite ;
Nouvelle version v1.2, Anonymisation de lien et correction du registre ;
Lien de type c, précisions ;
Entités multiples, gestion, relations et anonymat et Entité multiples ;
Nébuleuse sociétale et confiance – Chiffrement par défaut

Cette dissimulation d’un lien se fait avec un lien de type c. On a bien sûr dans le registre du lien visible l’entité qui génère ce lien, l’entité signataire. Et on a l’entité destinataire qui peut déchiffrer ce lien dissimulé et en extraire le vrai lien. Et comme dans la version publique de ce lien on a à la fois l’entité source et l’entité destinataire qui sont visibles, il n’y a pas d’anonymat. Ce type de lien permet juste de dissimuler l’usage d’un objet.

2015.06.27 lien c

Un lien dissimulé ne peut pas contenir un autre lien dissimulé. On interdit donc les multi-niveaux de liens dissimulés qui seraient un véritable calvaire à traiter.

Un lien peut être dissimulé pour soi-même. C’est à dire que l’entité signataire est aussi l’entité destinataire.

Si un lien doit être dissimulé pour plusieurs destinataires, il faut générer un lien pour chaque destinataire. La seule façon de réduire le nombre de liens pour un grand nombre de destinataires est d’utiliser la notion de groupe disposant de son propre bi-clé. Ce type de groupe est pour l’instant purement théorique.

Ce maintien comme public des entités sources et destinataires est une nécessité au niveau du lien, c’est une des bases de la confiance dans les liens. Pour que le lien puisse être validé et accepté par une entité ou retransmit par un relais, l’identification des entités est incontournable. Et donc avec l’identification nous avons aussi l’imputabilité et la non répudiation.

Si on veut assurer de l’anonymat pour les entités, puisque l’on ne peut pas travailler au niveau du lien, il faut travailler au niveau de l’entitié. On va dans ce cas travailler sur la notion de déception, c’est à dire faire apparaître des entités pour ce qu’elles ne sont pas ou tromper sur la nature des entités.
L’idée retenu consiste, pour chaque entité qui souhaite anonymiser ses échanges avec une autre entité, à générer une entité esclave avec laquelle elle n’a aucun lien. Ou plutôt, le lien d’entité maîtresse à entité esclave est un lien dissimulé pour l’entité maîtresse uniquement. Ici, personne à par l’entité maîtresse ne peut affirmer juste sur les liens que l’entité esclave lui est reliée.
Lorsque l’on veut échanger de façon anonyme, on transmet à l’entité destinataire l’identifiant de l’entité esclave, et vice versa. Cette transmission doit bien sûr être faîte par un autre moyen de communication ou au pire par un seul lien dissimulé.

L’anonymisation complète est donc la combinaison des liens de dissimulation de liens et d’une capacité multi-entités des programmes.

La dissimulation est en cours d’implémentation dans sylabe en programmation php orienté objet. Mais le plus gros du travail sera à faire dans la librairie nebule puisque c’est elle qui manipulera les liens et présentera ceux-ci à l’application, c’est à dire sylabe, dans une forme exploitable. L’application n’a pas à se soucier de savoir si le lien est dissimulé, elle peut le lire ou elle ne peut pas. Tout au plus peut-elle afficher qu’un lien est dissimulé pour information de l’utilisateur.
La capacité multi-entités de sylabe est maintenant beaucoup plus facile à gérer en programmation php orienté objet. Mais il reste à implémenter la génération des entités esclaves avec dissimulation de leur entité maîtresse.

Une autre dimension n’est pas prise en compte ici, c’est le trafic entre les serveurs pour les échanges d’informations. Il faudra faire attention à la remontée possible aux entités maîtresses par leurs échanges.

Enfin, pour terminer, aujourd’hui c’est la course au chiffrement par défaut de tous les échanges pour tout un tas de programmes et services sur Internet. Ce chiffrement par défaut est bon pour l’utilisateur en général. Et il masque dans la masse les échanges pour qui la confidentialité est critique. Ainsi il ne suffit plus d’écouter le trafic chiffré pour retrouver ses ennemis.
Mais cette logique est perverse. Le chiffrement par défaut est une aberration, un remède de cheval posé en urgence faut de mieux. Nous avons besoin d’échanger aussi des choses publiquement, comme sur un forum ou dans la presse. Nous ne devrions pas avoir des outils de communication tout chiffré et d’autres tout public, chaque outil devrait permettre les deux et clairement indiqué ce qui est protégé de ce qui ne l’est pas…

Description de la création d’une nouvelle entité.

La ré-implémentation de la génération d’une nouvelle entité est en cours dans sylabe.

Une nouvelle partie apparaît dans la documentation de référence sur la création d’une entité : Wiki – Documentation nebule v1.2 – Création d’une entité

On y trouve la procédure de référence à implémenter et notamment tout ce qui concerne la manipulation des clés cryptographiques asymétriques et mots de passes.

Arborescence virtuelle

Dans nos systèmes d’information actuels, le rangement des fichiers dans une arborescence est non seulement classique mais fondamentale et souvent incontournable. L’autre forme de rangement est d’utiliser une base de données.

Il est possible avec nebule de simuler une arborescence mais virtuelle et uniquement constituée d’objets et de liens.
CF Wiki РR̩flexion Рanalyse des applications РSyst̬me de fichiers

Un arborescence commence par une racine, par exemple ‘/‘. Dans cette racine on va trouver des fichiers, des sous-dossiers et des fichiers dans les sous-dossiers.
Chaque fichier a nativement un nom ou au pire un identifiant unique. Les fichiers vont avoir en plus un ou des liens pour les positionner dans l’arborescence à un ou plusieurs endroits.
Chaque dossier est constitué de l’objet contenant son nom. Cet objet de nommage est lié au dossier parent par un lien, lui-même relié à son dossier parent… jusqu’à la racine.

Le nom des objets ne pose pas de problème, il risque juste de changer d’une entité à l’autre. Le nom d’un dossier peut par contre avoir deux formes, mais on ne doit en gérer qu’une seule.
Soit le nom d’un dossier ne contient que sont nom et pas l’ensemble de l’arborescence. Dans ce cason peut avoir n’importe quel nom, y compris des noms avec le caractère séparateur de dossiers ‘/’. Mais si on souhaite mettre deux dossiers avec le même nom dans deux branches différentes de l’arborescence, il y a conflit sur le nom et donc mélange des fichiers enfants.
Soit le nom d’un dossier contient l’ensemble de l’arborescence. On résoud les problèmes de conflit. Et on n’accepte pas des noms de dossiers avec le caractère séparateur de dossiers. C’est la meilleur solution.

Comme il est possible que plusieurs entités créent plusieurs arborescences différentes ou en reconnaîssent plusieurs, il faut un objet unique de référence de cette arborescence. L’objet contenant ‘/’ doit dans ce cas être lié à l’objet de référence, et il en est de même pour tous les objets de l’aborescence.
Ainsi, comme pour l’émulation de commentaires dans le blog, les objets on des liens entre eux avec comme contexte un objet de référence. Les mêmes liens peuvent tout à fait être reproduire intégralement ou partiellement avec un autre objet de référence et ne pas entrer en conflit.

On obtient, du fait même de la base nebulisée, des comportements spécifiques sur l’arborescence.
Par exemple dans une arborescence de fichiers d’une société, le chef pose un nouveau fichier dans un sous-dossier. Tout le monde dans la société va voir ce nouveau fichier. Un des employé ‘copie’ le fichier ailleurs dans l’arborescence, tout le monde voit le nouveau fichier. Si il le modifie, il crée un objet de mise à jour et les deux fichiers sont mis à jours. Cela est intéressant puisque tous les emplacements sont tenus à jours mais cela peut déjà poser problème puisque l’on ne voulait peut-être pas tout mettre à jour. Il faut donc bien distinguer la mise à jour et le dérivé.
Prenons un autre cas. Un des employé modifie le nom du fichier créé par le chef. tout le monde voit la modification. Le chef décide d’annuler le nouveau nom, de redonner le nom d’origine au fichier. Tout le monde va voir le fichier revenir à son nom d’origine… sauf peut-être celui qui avait renommé le fichier puisque la gestion sociale des liens va peut-être décider que personne ne peut annuler son opération, même si le chef est son supérieur hiérarchique dans la société.

Cette arborescence virtuelle sera ajoutée pour expérimentation à sylabe. Comme ce n’est pas quelque chose de vraiment natif dans la philosophie de nebule, l’implémentation se fera sous forme d’un module.

On peut ensuite, sur cette base, aller plus loin avec par exemple inotify. Pour un dossier spécifié et ses sous dossiers, tout changement sur un dossier ou un fichier serait immédiatement nébulisé et synchronisé vers un serveur local ou distant.

Avancement

La remise en place des fonctions de la librairie nebule en php orienté objet ainsi que la ré-écriture du bootstrap pour en profiter reprend pleinement.

La résolution du graphe des mises à jours des objets, c’est à dire le suivi des liens de mises à jours, est fonctionnelle. On peut donc maintenant rechercher la dernière version de la librairie ainsi que la dernière version du programme à charger par défaut.
La librairie ayant le minimum fonctionnel pour le bootstrap, elle y a été intégralement copiée. Plus tard, elle sera allégée des fonctions non utilisées. La librairie étant plus modulable, les modules non nécessaires au bootstrap ne seront simplement pas intégrés.

La cible : faire charger la librairie par le bootstrap et le programme par défaut.

Le programme sylabe est fonctionnel sur la librairie actuelle moyennant la conservation des fonctions procédurales. Ces anciennes fonctions seront progressivement transformées pour utiliser les nouvelles fonctions en programmation orienté objet… et/ou supprimées dès que sylabe aura été mis lui aussi à jour. En attendant, il intègre en bas de page les nouveaux compteurs du nouveau bootstrap.

nebule_bootstrap_-_Experimental_-_2014-11-16_10.21.26

Avancement

Afin de tester les nouvelles fonctions avec sylabe, et pour pouvoir aussi reprendre le développement de ce dernier, les anciennes fonctions de la librairie en php procédural sont réinjectées dans la librairie en php orienté objet. Ainsi sylabe fonctionne et les anciennes fonctions procédurales vont pouvoir être progressivement reprogrammées pour faire appel aux nouvelles fonctions orienté objet…

Le code n’est pas encore diffusé puisqu’il est assez ‘sale’. Mais ça viendra…

Mémorisation de liens et accélération des traitements

Par défaut, à chaque chargement d’un objet pour traitement ou pour son affichage, chaque liens sont lus et vérifiés, puis relus et revérifiés. Parce que cette vérification implique des algorithmes cryptographiques de prise d’empreinte et des algorithmes cryptographiques asymétrique (à clés privées), le traitement cumulé de chaque vérifications devient vite une quantité non négligeable. Bref, le temps de calcul se ressent dans le traitement.

Il est possible d’accélérer ce fonctionnement avec la mémorisation des vérifications déjà faites.

Pour commencer, on peut considérer en première approximation que la plus grande partie du temps de traitement est imputable à la cryptographie asymétrique. On considère donc par défaut que les autres traitements sont, temporellement, quantités négligeables. cette approximation est vérifiée en pratique dans sylabe lorsque l’on désactive la vérification des signatures.

Pour des raisons de sécurité, les liens qui ont été vérifiés, et que l’on souhaite mémoriser, doivent être mémorisés en intégralité. Il ne faut pas garder uniquement la signature du lien. Il est préférable de conserver l’intégralité du lien. Tout au plus peut-on supprimer le champs signature. Ces liens pré-vérifiés doivent être conservés en lieu sûr, non modifiable par une autre entité ou un autre processus.
Dans ce cas, la vérification d’un lien va commencer par le parcours des liens déjà vérifiés, puis en dernier recours à vérifier le lien. Au delà d’un certain nombre de liens mémorisés, il est possible que le bénéfice de la mémorisation soit négatif vis-à-vis de la vérification direct des signatures des liens. Il faudra montrer expérimentalement l’ordre de grandeur de la table des liens mémorisés. Qui dit table de mémorisation limité dit aussi gestion de la quantité de liens mémorisés et donc du remplacement de certains liens par d’autres. Ce remplacement peut se faire en boucle, sans calcul, ou au contraire en tenant compte du temps de dernier usage des liens mémorisés. Bref, il y a du travail d’optimisation en perspective.

Comme on l’a vu avec une table de mémorisation limitée, le temps de mémorisation des liens peut être variable. De même, une autre période de rétention peut exister. La table de mémorisation peut n’être valable que pour le temps de chargement d’une page (web). Ou au contraire la table de mémorisation peut être valable le temps de la session, c’est à dire tout le temps ou l’entité est déverrouillée. Dans le cas de navigations sur sylabe, et en étant non-déverrouillée, la mémorisation peut être liée à la session php, et donc expirer avec celle-ci.

Imaginons maintenant un peu le futur. Imaginons que chaque entité, chaque humain dispose de sa clé privée en permanence dans un périphérique, ou plutôt une prothèse. Empactée dans du matériel, la clé privée serait beaucoup mieux protégée. De fait, corrompre la table de mémorisation des liens vérifiés deviendra un moyen plus facile pour modifier le comportement d’une entité. Il doit donc être maintenu la possibilité de fonctionner en mode paranoïaque en vérifiant à chaque utilisation les liens.

Avancement de la réimplémentation

La ré-implémentation de la librairie nebule php en orienté objet continue.

C’est plus long que prévu mais c’est intéressant. Cela oblige à refaire le tour des options et de leur pertinence avec le temps. C’est aussi l’occasion de revoir l’organisation de l’ensemble des fonctionnalités et de leurs places.

Je commence par le bootstrap puisque c’est l’implémentation la plus simple de nebule. Du coup, il ne change pas trop de forme mais il est réorganisé dans son fonctionnement. Un certain nombre de tests sont ajoutés pour vérifier le bon fonctionnement de l’ordinateur et de l’instance de nebule. Les entrées sorties sont vérifiées en lecture et écriture. Le bon fonctionnement de la cryptographie, qui se faisait jusque là dans sylabe, est aussi réalisée par le bootstrap. Le dysfonctionnement de certains tests critiques provoqueront le chargement de la page de bootstrap au lieu de l’application normale.

shot-2014-08-10_15-09-59

Le code correspondant, en cours de développement, est disponible ici :
http://stephane.nebule.fr/?mod=aff&obj=6ba665284be710117d2d2a2f81e8c9fe45d39e6fa270e54b7a515b63aa9eff3e

Lorsque le code sera intégré dans la librairie, les anciennes fonctions de la librairie procédurale seront ré-implémentées. Le code en orienté objet nécessite la connaissance de la programmation orientée objet, ce qui n’est pas à la portée de tout le monde puisque cela nécessite un temps de formation. Il faudra faire un guide d’utilisation de la librairie et de ses fonctions procédurales et orientées objet pour que n’importe qui puisse l’utiliser. Et puis, cela permettra aussi une transition facile pour le code de sylabe qui est en procédurale… et est assez volumineux pour moi à reprendre…

Parcours restreint de graph de mise à jour

Dans sylabe, la mise en place de la traduction sous forme de modules a apporté son lot de problèmes de sécurité. Les modules peuvent contenir tout un tas de code qui ne sont pas en rapport avec la traduction. Il faut interdire par tous les moyens l’ajout de code malveillant inconnu. Il est très difficile de filtrer finement ces codes pour ne garder au mieux que ce qui concerne les traduction ou au pire rejeter l’objet qui le contient. La solution retenu est de ne reconnaître que les modules signés soit par bachue, soit par l’entité locale.

Les fonctions _l_grx et _l_gr1 de la librairie en php prennent maintenant en compte un paramètre pour restreindre la recherche des liens de mise à jours (résolution du graphe des mises à jours) aux deux entités citées ci-dessus.

Mais, si fonctionnellement c’est suffisant, on va maintenant plus loin. Au lieu de ne reconnaître que deux entités, il est maintenant possible d’en ajouter plus de façon statique. On crée en quelque sorte une liste d’autorités locales. Cette liste n’est valable que sur un serveur et pour une seule instance de sylabe ou tout autre programme similaire.

Ainsi, la variable $nebule_local_authority contient une liste des entités faisant office d’autorité locale. Elle est pré-remplie par défaut avec l’entité bachue. Elle peut être complétée.

Une autre variable $nebule_curentnotauthority permet d’interdire à l’entité courante d’être elle aussi autorité locale. A false par défaut, l’entité locale peut ajouter des modules. C’est notamment pratique pour le développement puisque l’on peut faire soi-même des évolutions de ces modules. A true, l’entité locale ne peut qu’utiliser les modules par défaut présents localement.

Il est bien sûr possible de positionner ces deux variables dans les fichiers de configuration env_nebule.php et env_sylabe.php. Cependant, leur comportement est un tout petit peu différent dans le bootstrap et dans la librairie (via une application comme sylabe).

Quelques explications s’imposent pour comprendre les différences. Schéma de fonctionnement global d’une instance :

1 – Appel du bootstrap (index.php) par le serveur web.
V
2 РEx̩cution du script php.
3 – Lecture du fichier de configuration env_nebule.php.
4 – Recherche de la librairie nebule valide à charger.
5 – Chargement de la librairie nebule (fonctions et variables).
6 – Recherche de l’application par défaut et valide.
(actuellement, c’est sylabe)
7 – Le bootstrap charge l’application et passe la main.
V
8 – Exécution du script php de l’application.
9 – Lecture du fichier de configuration env_sylabe.php.
10 – Déroulement du script de l’application…

Lors de l’exécution du bootstrap, celui-ci n’utilise pas la session utilisateur gérée par php. Il va cherche si le fichier e existe et si c’est une entité. Il prend cette entité comme étant l’entité propriétaire de l’instance. Si avec la variable $nebule_curentnotauthority on empêche de reconnaître cette entité comme autorité, seule bachue sera autorité et donc seuls ses mises à jours seront prises en compte. Ainsi, il n’est pas possible pour l’entité locale de modifier la librairie ou le programme (sylabe) sauf si ils sont signés par bachue. Une mise à jour régulière est possible.

Lors de l’exécution de l’application, ici sylabe, l’entité locale n’est pas forcément l’entité courante. Et l’entité courante n’est donc pas forcément propriétaire de l’instance mais juste utilisatrice. Si avec la variable $nebule_curentnotauthority on empêche de reconnaître cette entité comme autorité, seule bachue sera autorité et donc seuls ses modules seront pris en compte. Ainsi, il n’est pas possible pour l’entité courante de modifier les modules. Une mise à jour régulière est possible.

En clair, l’entité locale choisit la librairie nebule et le programme à charger, l’entité courante dans le programme choisit les modules. Si cela ne leur est pas interdit.

Pour ajouter d’autres autorités, il suffit de les ajouter à la variable $nebule_local_authority dans les fichiers de configuration :
$nebule_local_authority[]='88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea';

shot-2014-05-19_12-24-40

Métrologie et journalisation

La métrologie est ajoutée dans la librairie en php de nebule et est complétée dans sylabe.

La journalisation (log) est ajoutée au bootstrap et à la librairie php. On peut consulter les logs du système, cela ressemble à ça :

May 16 15:58:35 gaia nebule/bootstrap/99df1611: metrologie(start)1400248715.3933
May 16 15:58:35 gaia nebule/bootstrap/99df1611: metrologie(mark1)1400248715.3957
May 16 15:58:35 gaia nebule/bootstrap/99df1611: metrologie(mark2)1400248715.3961
May 16 15:58:35 gaia nebule/bootstrap/99df1611: metrologie(mark3)1400248715.7138
May 16 15:58:35 gaia nebule/bootstrap/99df1611: metrologie(mark4)1400248715.7139
May 16 15:58:35 gaia nebule/bootstrap/99df1611: metrologie(mark5)1400248715.7303
May 16 15:58:35 gaia nebule/bootstrap/99df1611: metrologie(mark6)1400248715.7304
May 16 15:58:35 gaia nebule/bootstrap/99df1611: metrologie(end--)1400248715.7304
May 16 15:58:35 gaia sylabe/99df1611: metrologie(start)1400248715.7669
May 16 15:58:35 gaia sylabe/99df1611: metrologie(mark1)1400248715.8505
May 16 15:58:35 gaia sylabe/99df1611: metrologie(mark2)1400248715.8683
May 16 15:58:35 gaia sylabe/99df1611: metrologie(mark3)1400248715.8755
May 16 15:58:35 gaia sylabe/99df1611: metrologie(mark4)1400248715.8756
May 16 15:58:35 gaia sylabe/99df1611: metrologie(mark5)1400248715.8992
May 16 15:58:35 gaia sylabe/99df1611: metrologie(mark6)1400248715.9034
May 16 15:58:36 gaia sylabe/99df1611: metrologie(mark7)1400248716.0637
May 16 15:58:39 gaia sylabe/99df1611: metrologie(mark8)1400248719.8376
May 16 15:58:39 gaia sylabe/99df1611: metrologie(end--)1400248719.8378

Dans la librairie, les marques de passage dans les fonctions et les temps sont envoyés dans les logs système (syslog) moyennant le contrôle par les variables $nebule_timedebugghf et $nebule_timedebuggef. La distinction se fait sur les fonctions de haut niveau et les fonctions élémentaires. Aucun log n’est prévu sur les fonctions de bas niveau. Si on active les deux, ça débite pas mal…

Mise en place de la nouvelle version dans la librairie php

Le code de la librairie en php génère maintenant les entêtes de liens en version 1.2.

Cela n’a pas d’autre influence aujourd’hui. C’est déclaratif.

Le code sera adapté rapidement pour ajouter les liens au suivi des entités. Puis plus tard l’offuscation des liens sera implémentée.

Cela n’a pas d’impact sur le comportement de sylabe notamment.