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é…