Diffusion des mises à jours

L’entité bachue diffuse depuis hier soir les dernières versions de la librairie nebule en php et du bootstrap :

La librairie nebule en bash est en cours de mise à jours vers la version 1.2 .

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

Modification de la librairie php vers la version 1.2 des liens

La librairie en php intègre maintenant les spécificités de la version 1.2 lors de l’écriture des liens par la fonction _l_wr.

L’écriture des liens se fait aussi sur l’entité signataire avec la prise en compte de la spécificité du lien de type c lors de l’écriture. Lorsque c’est un lien de type c, seule l’objet de l’entité signataire du lien reçoit le lien. Ce fonctionnement risque encore de changer en fonction des réflexions autour de ce type de lien.

Mise en cache de validité de liens

Il faut faire attention à la mise en cache du résultat de certaines opérations. Il est très peu probable qu’un lien ou un objet soit modifié au cours du chargement d’une page. Mais la sûreté de fonctionnement de ce mécanisme de cache ne repose que sur ce principe.

Actuellement, dans la librairie en php, la fonction de vérification des liens _l_vr n’intègre pas de cache. C’est à dire que à chaque lecture de liens, ils sont revérifiés.
Si un cache devait être implémenté sur cette fonction, pour un lien définit il devrait prendre en cache l’intégralité du lien et non juste le premier champs de registre. Éventuellement, il pourrait n’intégrer que tous les champs de registre à l’exception de la signature puisqu’elle aura déjà été vérifiée.

La mise en cache de la vérification des objets utilisés _o_vr vient d’être implémentée. Le cache n’est gardé que le temps du chargement d’une page. Il ne vérifie que les objets directement intégrés à la page mais pas les objets externes comme les images. Les objets externes sont vérifiés lors de leur consultation, ce qui correspond en quelque sorte à une nouvelle page.

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.

Nouvelle version nebule v1.2 – lien de type c

Comme nouveauté de la version 1.2, il y a la possibilité d’offusquer les liens afin de renforcer l’anonymisation des entités.

Pour cela, un nouveau type de lien vient d’être ajouté à la documentation : Action c – Chiffrement de lien
Autrement dit, c’est un lien de type c.

Il n’est pas encore pris en compte dans le code. Sa forme exacte n’est pas encore figée.

Nouvelle version nebule v1.2

Ça faisait quelques temps que ça mijotait. Voici donc venir la nouvelle version de nebule. Nous passons à la version 1.2 .

Une nouvelle page technique sur le wiki vient d’être créée : Documentation – nebule v1.2

Les ajout prévus pour cette nouvelle version :

  1. Modifier le comportement dans le tri des liens par rapport aux objets concernés. Désormais un objet aura aussi en liens attachés ceux qui contiennent le champs signataire=objet. En pratique, cela ne concerne que les entités. Le gain attendu est de faciliter la diffusion des actions des entités.
  2. Permettre l’offuscation de liens par la mise en place d’un nouveau type d’action. Le gain attendu est de renforcer l’anonymisation.

Tous les codes vont progressivement être modifiés pour intégrer cette version.

Supprimer un grand nombre d’objets anciens

La fonction d’oubli, bien qu’indispensable, n’est pas encore en place. Elle nécessite la mise en place préalable de la pondération sur les objets. Cette pondération est elle-même un dérivé des avis et émotions.

En attendant, il peut être nécessaire de supprimer un grand nombre d’objets anciens et qui perdent vite de la valeur avec le temps. Typiquement cela concerne les sauvegardes d’un serveur. Les sauvegardes ont une forte utilité mais seule la dernière en date a vraiment de l’importance. Tout au plus peut-on garder des sauvegardes plus anciennes pour pouvoir remonter dans le temps, au cas où. Mais si on fait une sauvegarde journalière, la plupart des sauvegardes n’ont plus d’intérêt après quelques jours, voir le lendemain.

Voici comment supprimer des objets par lot dans nebule, et surtout en bash.

1 Lister

Première étape, lister tous les objets que l’on souhaite ‘oublier’. Ici, les objets sont ceux qui font plus de 10Mo et qui sont anciens de plus de 90 jours.
Lancer :
find pub/o/ -mtime +90 -size +10M | cut -d '/' -f 3 > aSupprimer.txt

Le fichier aSupprimer.txt contient la liste des objets qui répondent aux critères. Il serait tentant de supprimer directement les fichiers, mais ceux-ci pourraient réapparaître suite à une synchronisation. Il est préférable de les marquer supprimés.

2 Supprimer

Deuxième étape, faire supprimer et marquer comme supprimés les objets précédemment listés.
Lancer :
. lib_nebule.sh
. env.sh
export nebule_publ_entite=$(cat pub/e)
export nebule_priv_entite=$(cat priv/e)
read -s -p "Mot de passe : " nebule_pass_entite
nebCheckKeyPass
cat aSupprimer.txt | while read O ; do echo $O ; _l_wr $(_l_gen 0 d $O 0 0) ; rm pub/o/$O ; done

Et voila, les objets sont supprimés et marqués comme supprimés. Le fichier aSupprimer.txt peut être lui aussi supprimé…

Script d’export de la machine hôte de bachue

Voici la suite de l’article Script d’import de la machine hôte de bachue.

C’est un nouvel exemple de manipulation d’un support amovible avec nettoyage par un script. C’est aussi un exemple simple de manipulation de liens.

Le script en bash est disponible sur une page dédiée du wiki : Documentation – Entité bachue – Hôte bachue – Script export
Empreinte SHA256 : 5ffdf679599fedaf9029ad1eafc2bffa459ec8b919363245b9956a725b78ad99

Une version spéciale permet une copie intégrale : Documentation – Entité bachue – Hôte bachue – Script copie
Empreinte SHA256 : 30c5adb8d6582cdc92768575fc1fb42686eefb463ceb0e3445229bd96cc8a43c

Ajout d’émotions sur des objets – suite 4

L’ajout des émotions sur les objets n’en finit pas d’arriver… Le code est un peu délicat à manipuler. Certaines choses doivent s’afficher dans certaines conditions et à certains endroits en fonction de l’objet que l’on regarde. C’est la suite de l’article Ajout d’émotions sur des objets – suite 3.

Les émotions supportées sont encore sujet à discussion, mais leur fonctionnement est maintenant stable.
Les émotions doivent être considérées comme des groupes, donc les objets que l’on marque avec ces émotions appartiennent en quelque sorte aux groupes d’émotions en question.
On parle ici des émotions, mais la mécanique est exactement la même pour les avis. Seul l’affichage peut varier un peu.

Quelques règles de fonctionnement :

  1. Une émotion est représentée sur un objet par un lien de type ‘f‘ de l’émotion vers l’objet, méta à ‘0‘.
  2. Une émotion sur un objet dérivé lié à l’objet en cours est un lien de type ‘f‘ de l’émotion vers l’objet dérivé avec comme méta l’objet en cours.
  3. Une émotion sur un objet dérivé, donc avec un contexte, n’apparaît pas dans le mode affichage de l’objet, même si on est sur l’objet dérivé en question.

Cela donne par exemple ce genre de vue en mode navigation :

shot-2014-04-22_20-44-57

On remarque que toutes les lignes qui disent que l’objet est de type image/jpeg ont l’émotion ‘J'approuve‘. C’est fait en une seule fois. C’est le même lien derrière qui dit que l’on approuve que l’objet soit de ce type, indépendamment de qui le dit.

Si on se place sur l’objet du milieu dans la petite conversation en cascade, on peut observer ça :

shot-2014-04-22_20-50-34

On voit que les autres commentaires sont fait dans le contexte d’un objet spécifique, un autre objet surtout. On voit aussi qu’une émotion est placée sur l’un des commentaire, cette émotion est cependant dans le contexte de l’objet en cours, ce commentaire, et non dans le contexte de l’objet dans lequel à lieu la discussion. Si on regarde l’affichage précédent, cette émotion n’apparaît pas.

Mise en place d’un cache

Dans la librairie nebule de référence en php, une forme de mise en cache des résultats a été mise en place. Un certain nombre de fonctions peuvent être appelées plusieurs fois avec les mêmes paramètres. Il est plus rapide de mémoriser certains résultats par défaut même si ils ne sont plus utilisés que de relire et revérifier des liens pour retrouver les résultats.

Les gains dans les modes nav et lnk sont très sensibles, au minimum 2 à 3 fois moins de temps pour afficher une page.

La mise en cache est contrôlée par la variable $nebule_usecache.

CF : http://blog.sylabe.org/?p=488

Script d’import de la machine hôte de bachue

Voici un exemple de manipulation d’un support amovible avec nettoyage par un script. C’est aussi un exemple simple de manipulation de liens.

Le script en bash est disponible sur une page dédiée du wiki : Documentation – Entité bachue – Hôte bachue – Script import
Empreinte SHA256 : 88e31d4d23271f3e3528842b0d6b71fe36ed9b265e8f0b41202ea87a4e937e73

Une variante de ce script va permettre aussi l’import d’objets et de liens sur le serveur relai bachue. La seule différence, c’est qu’il n’acceptera pas les liens non signés.

La mise en production de bachue progresse…

Affichage des liens invalides

La librairie nebule en php permet maintenant la remontée, pour affichage uniquement, des liens invalides. C’est contrôlé par la variable $nebule_listinvalidlinks. Cette fonctionnalité ne sera pas activée par défaut parce que l’utilisateur pourrait confondre un lien compromis avec un problème de synchronisation sans gravité. Quoi qu’il arrive, la synchronisation élimine par défaut les liens invalides.

Voila à quoi cela peut ressembler :

shot-2014-04-12_15-34-58

CF : http://blog.sylabe.org/?p=481

Ajout d’émotions sur des objets – suite 3

Toujours pas de modification dans les émotions de base assumées. On reste sur la roue de Plutchik.

Par contre, la mise en place de la gestion des émotions et avis dans sylabe montre que l’utilisation des liens ‘l‘ n’est pas optimale et qu’il vaudrait mieux utiliser des liens ‘f‘ à la place. Si on change de type de liens, cela rendra caduc les objets ‘nebule/objet/emotion‘ et ‘nebule/objet/avis‘. A la place pourra être utilisé un objet méta comme une sorte de contexte du lien.
CF avancement du 11/04/2014.

Ajout d’émotions sur des objets – suite 2

Voici la suite des articles Ajout d’émotions sur des objets et suite, ainsi que de Liens d’émotions.

La liste d’émotions étant trop grande et malgré tout incomplète, il a été nécessaire de revoir l’ensemble pour le scinder. Plutôt que de réinventer la roue, un petit tour du côté de Wikipédia a permit de prendre un bon départ. La version anglaise de la page émotion est plus complète et plus intéressante.

Il y a plusieurs repères possibles pour traiter et cataloguer les émotions. On va s’arrêter sur les travaux de Robert Plutchik . Le résultat, c’est la roue de Plutchik :

Plutchik-wheel_fr.svg

Continuer la lecture de Ajout d’émotions sur des objets – suite 2

Liens d’émotions

La mise en place des émotions sur les objets appelle plusieurs questions.

Catégories

Vu le nombre d’émotions gérées, il va devenir nécessaire de les segmenter en catégories. On peut maintenir la catégorie ‘émotions‘ qui regroupe tout ressentit humain, plutôt subjectif. On peut ajouter une nouvelle catégorie ‘avis‘ pour tout ce qui est plus objectif.

Pondération

Une réflexion qui commence à dater un peu sera la mise en place d’une pondération aux objets. Cette réflexion concerne avant tout la possibilité d’oublier progressivement dans le temps les objets avec le moins d’importance. L’oublie peut être réalisé automatiquement à partir d’un certain seuil. Le seuil peut progressivement augmenter dans le temps jusqu’à un seuil maximum au dessus duquel les objets concernés seront conservés, sauf suppression volontaire.

Cette pondération peut être bien sûr utilisable en permanence pour trier l’affichage des objets.

La mise en place des émotions est le bon moment pour introduire la mise en place de la pondération. Il ne reste plus qu’à en définir les modalités.

Chiffrement

Une autre réflexion qui date un peu mais prend progressivement de l’importance, c’est la possibilité de chiffrer les liens. Le but est d’offusquer que l’on ne souhaite pas rendre publics tout en permettant leur bonne transmission aux destinataires légitimes.
Il y a plusieurs manières d’offusquer les liens :

  1. La première est de créer un objet de liens, objets que l’on chiffre ensuite vers son destinataire. Cette méthode, si elle est assez bonne en terme de performance de déchiffrement, nécessite cependant que tous les liens offusqués soient consultés en même temps que tout les liens normaux d’un quelconque objet, pour savoir si un lien secret ne le concerne pas spécifiquement. On obtient de fait un ou plusieurs objets de liens chiffrés attachés à son entité. L’inconvénient, c’est qu’il est impossible de transmettre un lien particulier à une autre entité sans devoir recréer un nouvel objet de liens chiffré.
  2. La seconde méthode est de faire du chiffrement de lien à la volée. C’est à dire qu’un lien a offusquer est chiffré et reste présent individuellement au milieu des autres liens. Cependant, ce lien va contenir un partie chiffrée, partie qui ne correspond donc pas à un objet réel, ce qui est en contradiction avec la forme actuelle des liens. L’avantage, les liens chiffrés voyagent naturellement avec les autres liens. L’inconvénient, le lien chiffré ne peut être rattaché qu’à un seul objet et à une entité. Le lien avant chiffrement fait référence à trois objets, on perd donc avec le lien chiffré la référence aux deux autres objets. Cela veut dire que le lien chiffré est valable si on consulte l’objet source, mais n’est plus reconnu si on consulte l’objet destination. Cet inconvénient risque de perturber la résolution inverse d’un arbre de mise à jour par exemple.
  3. La troisième méthode est d’exporter la partie chiffrée dans un objet en tant que tel. Cette méthode a l’avantage de profiter du mécanisme de chiffrement déjà implémenté pour les objets. Liens et objets sont transmis naturellement vers un destinataire du lien. Et on retrouve l’inconvénient de la deuxième méthode. En plus, on complexifie l’analyse des liens d’un objet puisqu’il faut aller consulter d’autres objets pendant le processus de lecture des liens, et donc d’autres liens…

La mise en place du chiffrement des liens va créer de fait une nouvelle version de nebule, la v1.2.