Catégorie : fonctions

P̩rim̬tre fonctionnel bootstrap Рlibpp

Jusque là le bootstrap intégrait une bibliothèque PHP procédurale (libpp) de nebule héritée et remaniée avec le temps mais ayant gardée tout ce qui était fonctionnel.

Or pour le bootstrap certaines fonctionnalités n’ont pas d’utilisé. Et comme il va falloir réécrire et revoir en grande partie cette bibliothèque, c’est le bon moment pour la simplifier. Et on va commencer par supprimer les parties sans utilité.

Au niveau cryptographie, seul la génération et la vérification des liens est utile. Le chiffrement d’objets n’a pas de raison d’être présent. La dissimulation de liens n’a pour l’instant pas d’utilité non plus.

La gestion des attributs d’objets n’a pas d’utilité mais il faut garder la capacité à suivre les mises à jours d’un objet et être capable d’aller chercher des mises à jour. Mais afin de réduire la complexité, seul le HTML sera utilisable.

Les liens supportés seront mono-registre et mono-cœur.

Le travail fait avant par la bibliothèque de nebule en bash permettait de générer un nouveau puppetmaster. Cela va devenir une nouvelle fonction dans le périmètre du bootstrap, et donc de la libpp. Il faut donc conserver la capacité de générer de nouvelles entités et de générer des liens.

Une autre partie qui va être intégrée au bootstrap, c’est la possibilité de faire les mises à jours des applications. Il faut donc que le bootstrap soit capable de parler avec le reste du monde. Seul le HTTP sera pris en compte pour ça. Et cela concerne aussi les entités.

Tout le reste fera partie de la bibliothèque en PHP orienté objet (libpoo).

Définition des groupes

La gestion des groupes est entièrement revue et corrigée dans la bibliothèque nebule en PHP orienté objet et dans les applications (sylabe, klicty, messae).
Une fois les applications mises à jour, les groupes existants disparaîtront.

Cet article invalide la définition de groupe telle que définit dans l’article Définition des groupes du 14/01/2016.

Cette implémentation des groupes sera aussi utilisée pour les conversations contenant des messages.

OG / Groupe

Le groupe est un objet définit comme tel, c’est à dire qu’il doit avoir un type mime nebule/objet/groupe.

Fondamentalement, le groupe est un ensemble de plusieurs objets. C’est à dire, c’est le regroupement d’au moins deux objets. Le lien peut donc à ce titre être vu comme la matérialisation d’un groupe. Mais la définition du groupe doit être plus restrictive afin que celui-ci soit utilisable. Pour cela, dans nebule, le groupe n’est reconnu comme tel uniquement si il est marqué de son type mime. Il est cependant possible d’instancier explicitement un objet comme groupe et de l’utiliser comme tel en cas de besoin.

Le groupe va permettre de regrouper, et donc d’associer et de retrouver, des objets. L’objet du groupe va avoir des liens vers d’autres objets afin de les définir comme membres du groupe.

Un groupe peut avoir des liens de membres vers des objets définis aussi comme groupes. Ces objets peuvent être vus comme des sous-groupes. La bibliothèque nebule ne prend en compte qu’un seul niveau de groupe, c’est à dire que les sous-groupes sont gérés simplement comme des objets.

Continuer la lecture de Définition des groupes

Réflexion sur l’évolution de l’interface web pour nebule – entités

Suite de la réflexion sur l’évolution de l’interface web pour nebule et objets.

Le code de génération graphique de l’affichage des objets progresse. La mise en place d’une fonction getDisplayList() permet de gérer beaucoup plus facilement une liste d’objets.

Voici un comparatif d’une liste d’entité avec l’ancienne méthode et la nouvelle :

 20170902-shot-2017-09-02_18-35-52

Et :

20170902-shot-2017-09-02_19-09-22

Réflexion sur l’évolution de l’interface web pour nebule – objets

Suite de la réflexion sur l’évolution de l’interface web pour nebule.

Au moyen d’une nouvelle fonction d’affichage dans la bibliothèque nebule, la fonction getDisplayObject(), il est maintenant possible de déléguer plus facilement l’affichage d’une liste d’objets ou d’entités.

Voici l’affichage inséré dans un textes :

20170829-inline

Les différents formats d’affichage en blocs avec une hauteur de 32px, 64px, 128px puis 256px :

20170829-bloc-1

20170829-bloc-2


 20170829-bloc-3


 20170829-bloc-4

Plusieurs blocs s’assemblent pour remplir toute la largeur disponible en rapport avec leur largeur propre. Les informations internes affichées des blocs sont complètement indépendantes les unes des autre. Cela donne :

20170829-assemblage-bloc

La fonction permet aussi un affichage en liste avec un objet par ligne :

20170829-lignes

Quelques possibilités :

  • Le carré de l’icône peut être remplacé par une image ou masqué.
  • Le carré de la couleur n’est pas modifiable est dépend uniquement de l’ID de l’objet, mais peut être masqué.
  • Le nom de l’objet peut être remplacé par un texte.
  • L’identifiant de l’objet peut être masqué.
  • Les entités ou objets de référence (au dessus du nom) peuvent être masqués et si la liste est trop longue il se réduisent aux carrés de couleur et d’icône, voir juste au carré de couleur.
  • Les icônes de protection, de dissimulation et de verrouillage sont activables (en fond vert) et peuvent être masqués.
  • Les émotions sont calculés automatiquement et peuvent être masquées.
  • Le compteur est personnalisable et peut être masqué.
  • Certains éléments ne peuvent pas être affichés ensemble, surtout quand la place est limitée.
  • Les blocs sont centrés par défaut, leurs assemblages aussi.

Il reste à faire la deuxième partie de ces affichages d’objets, c’est à dire de les rendre utilisables autrement que juste par des liens hypertextes. L’idée est de rendre les carrés de l’icône et de la couleur sensible au clic pour afficher un menu complet des actions sur l’objet. Les actions seront dépendantes des modules via la mise en place de nouveaux points d’accrochage (hooks).

Modification de l’ordre de prise en compte des propriétés d’un objet

Je reprends progressivement le développement de nebule pour corriger le bugg de klicty et améliorer dans sylabe le module correspondant.
Et je tombe sur un problème non dans l’implémentation mais dans la façon dont on prend en compte les propriétés d’un objet, ou plutôt l’ordre de prise en compte lorsque cela est fait plusieurs fois. C’est à dire, quel propriété retient-on en priorité lorsqu’il y a plusieurs liens d’un objet vers plusieurs propriétés.
Le problème n’a pas une solution difficile en soi mais le fait qu’il concerne une brique importante de nebule me freine à le modifier sans plus de réflexion. Les implications que cela engendre peuvent être très importantes dans pleins d’endroits du code de la bibliothèque de nebule et des applications. Continuer la lecture de Modification de l’ordre de prise en compte des propriétés d’un objet

Renforcement de la lecture des objets – affichage

Suite de l’article sur le Renforcement de la lecture des objets, et type hash invalide.

L’argument $permitTruncate ayant disparu, c’est aussi l’option displayUnverifiedObjects qui n’a plus de raison d’être. Les fonctions d’affichage qui auraient pu devoir afficher un objet trop gros pour le vérifier n’en verront plus dans tous les cas.

En échange, une nouvelle option permitCheckObjectHash est mise en place dans la bibliothèque nebule en PHP orienté objet.
Elle est utilisée dans la fonction _getUnprotectedContent(). Elle va activer la vérification de l’empreinte des objets lus, ou plutôt forcer la lecture de l’objet même si son empreinte est invalide ou non vérifiable. C’est le pendant de l’option permitCheckSignOnVerify ayant la même signification pour la vérification des liens. Elle a true comme valeur par défaut. Elle n’est pas modifiable par lien, pour changer sa valeur par défaut il faut modifier le fichier des options.
Cette option est critique, elle doit toujours rester par défaut à true !

Renforcement de la lecture des objets – type hash invalide

Dans l’article sur le Renforcement de la lecture des objets, il était question notamment de la possibilité de supprimer ou pas un objet dont on ne peut pas vérifier l’empreinte parce que le type de hash est soit inconnu soit non reconnu.

Lors de l’échec de la récupération du type de hash de l’objet, on essaye tout de suite, si l’option permitSynchronizeLinks est à true, de synchroniser rapidement les liens de l’objet. Puis on essaie de relire le type de hash de l’objet.

Une nouvelle option permitDeleteObjectOnUnknowHash vient d’être ajoutée. Elle a true comme valeur par défaut. Elle n’est pas modifiable par lien, pour changer sa valeur par défaut il faut modifier le fichier des options.
Cette option est critique, elle doit toujours rester par défaut à true !

La nouvelle option est utilisée par la bibliothèque nebule en PHP en programmation orienté objet (library POO) par les fonctions checkConsistency() et _getUnprotectedContent() de la classe Object. La fonction _getProtectedContent() ne prend pas en compte cette option, elle se base uniquement sur _getUnprotectedContent() pour la lecture de l’objet protégé et de la clé de déchiffrement associée.

L’implémentation de l’option est un tout petit peu différent ce que l’on peut attendre. Lorsque l’on recherche le lien du type d’empreinte d’un objet (avec la pondération sociale), si aucun lien n’est trouvé ou si le nom de l’algorithme de prise d’empreinte n’est pas reconnu, alors il y a deux possibilités.
L’option permitDeleteObjectOnUnknowHash est à :

  1. false. Dans ce cas les deux fonctions retournent tout de suite un résultat booléen négatif ou un contenu vide.
  2. true. Comme aucun algorithme n’est trouvé, on utilise l’algorithme définit par défaut et on continue le processus de vérification dans les deux fonctions. Si l’empreinte ne correspond pas avec cet algorithme, l’objet est supprimé. C’est une façon de donner une chance à un objet pour lequel les liens auraient été partiellement synchronisés.

Dans la bibliothèque nebule en PHP en programmation procédurale (library PP), la lecture des objets se fait via les fonctions _o_ls1 et _o_lsx. La deuxième repose en fait sur la première. Et en début de fonction _o_ls1, un appel à la fonction _o_vr permet de vérifier le contenu de l’objet.
La fonction _o_vr ne prend en compte que les objets avec un hash fait avec l’algorithme par défaut, aujourd’hui sha256. L’option permitDeleteObjectOnUnknowHash n’est pas utilisée.

Dans les deux bibliothèques, si c’est l’objet avec d’identifiant 0, alors il est systématiquement supprimé.

Enfin, dans tous les cas, il ne faut surtout pas tenter de vérifier l’empreinte avec tous les algorithmes disponibles, cela reviendrait à permettre une attaque sur le plus faible de ceux-ci…

Renforcement de la lecture des objets

Dans la bibliothèque nebule en PHP orienté objet et dans certaines applications, un certain nombre de fonctions lisent le contenu des objets soit directement soit via la fonction getContent() de l’instance Object des objets. Toutes les lectures de contenus d’objets et de liens se font via la classe io de la bibliothèque et non directement par des fonctions de PHP de lecture de flux, de lecture directe. Les fonctions de la classe io ne font pas d’opérations cryptographiques, donc aucune vérification n’est possible à ce niveau.

Dans la bibliothèque se trouve aussi la fonction checkConsistency() pour vérifier le contenu d’un objet. Deux différences existent entre les deux fonction :

  1. La fonction getContent() lit des données et vérifie si l’empreinte est bonne sauf si l’objet est trop grand. Si l’objet est trop grand, un argument $permitTruncate permet de ne pas rejeter le contenu de l’objet si il est trop grand. Pour les petits objets la vérification se fait dans tous les cas. La limite d’un objet petit ou grand est définie par l’option ioReadMaxData. Si l’empreinte ne correspond pas, le contenu n’est pas conservé et un contenu vide est renvoyé à la fonction appelante. La fonction checkConsistency() ne renvoie pas de données mais vérifie juste l’empreinte, le résultat booléen renvoyé et négatif ou positif.
  2. La fonction getContent() ne supprime pas un objet si l’empreinte n’est pas bonne. La fonction checkConsistency() vérifie l’empreinte et, si l’empreinte n’est pas bonne, supprime l’objet via une fonction de la classe io.

Il est difficile de prendre une décision de suppression d’un objet parce que peut-être que l’algorithme de prise d’empreinte n’est pas reconnu par la machine sur laquelle tourne l’instance serveur. En cas d’absence de possibilité de vérification comme un type d’empreinte inconnu ou un objet trop grand, il faut renvoyer un contenu vide ou résultat négatif mais il ne faut pas supprimer l’objet. Quoique dans un mode paranoïaque, il faut peut-être prévoir de supprimer tout objet non vérifiable, à voir.

Pour commencer l’argument $permitTruncate n’a pas de raison d’être, il est contre productif parce qu’il affaibli l’ensemble du système. Il va être supprimé et les applications qui affichaient un objet avec un message comme quoi l’objet est trop gros vont afficher un message d’erreur sans le contenu.

Ensuite, la fonction getContent() fait appel à une fonction privée _getProtectedContent() pour lire le contenu d’un objet protégé. Elle va maintenant sous-traiter aussi la lecture des objets non protégés à une fonction privée _getUnprotectedContent(). Cette nouvelle fonction sera très similaire à la fonction checkConsistency() mais renverra un contenu complet ou vide au lieu d’un résultat booléen. Et bien sûr l’objet sera supprimé en cas d’empreinte invalide. Et la fonction _getProtectedContent() utilisera la fonction _getUnprotectedContent() pour la lecture de tous les objets accessibles non protégés.

La suppression de l’argument $permitTruncate va poser un gros problème pour l’affichage des gros objets. Ceux-ci via le navigateur peuvent être affiché dans certains cas parce que le navigateur les télécharge sur le serveur web pour les afficher au fur et à mesure. C’est le cas des vidéos non protégées. Une des options pour résoudre ce problème est peut-être d’utiliser le lien de type s jusque là inexploité par la bibliothèque…

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

Mise à jour – librairie bash de référence

L’entité bachue diffuse depuis ce soir une nouvelle version de la librairie bash de référence. Elle est disponible ici :

0c2bd920ba6efa6fdb72718bd5d606cd56c95956d8e3e8c6e1f8562d56820853 (contenu)

Cette mise à jour apporte la fonction de déchiffrement complète nebObjUnEnc pour extraire un objet en clair d’un autre objet chiffré. Cela tient compte de la clé de session et de l’entité destinataire, c’est à dire celle qui détient la clé privée (et son mot de passe).

Cela donne par exemple (dans une console bash) pour la commande

nebObjUnEnc 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 /home/steph/temp/

les logs :

2013-05-24T23:23:48+0200 2  -nebObjUnEnc REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 /home/steph/temp/
2013-05-24T23:23:48+0200 2  -nebObjUnEnc PATH /home/steph/temp/
2013-05-24T23:23:48+0200 3  -nebReadObjLinks REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 4  _l_lsx REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 5  _l_ls1 REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 2  -nebObjUnEnc FOUND 2919ec018c34e16115b6edccd6cd8f5ba4fc43b2f81a74b05a6a6b2b7b10c1203495bc16302448e0f765f996b20dcfdaa603d498ca3677d1c4edc89d00ff78ee0b08afea86599b9dd7d3b906eabd03e95fcedb6a061a845880734dbd96ce
2013-05-24T23:23:48+0200 2  -nebObjUnEnc SESSION KEY fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 3  -nebReadObjLinks REQ fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 4  _l_lsx REQ fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 5  _l_ls1 REQ fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 2  -nebObjUnEnc FOUND 8081c51cffa6f2e56f0f2b087cfaf0cf58eb04470e232d3051153d12e536b803a17dbb2d2d32d1816abfe405beac973193ce3ec4116a5588a03fe7a120170cf19160ccb6a2d131711c30d18eb120326972b147baddbd008837f271c401f5
2013-05-24T23:23:48+0200 2  -nebObjUnEnc SESSION KEY ENC cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c
2013-05-24T23:23:48+0200 3  -nebAsymUnEnc REQ cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c
2013-05-24T23:23:48+0200 4  -nebReadObjTypeMime REQ cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c
2013-05-24T23:23:48+0200 5  -nebFindObjType REQ cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c nebule/objet/type
2013-05-24T23:23:48+0200 6  _l_lsx REQ cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c
2013-05-24T23:23:48+0200 7  _l_ls1 REQ cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c
2013-05-24T23:23:48+0200 5  -nebFindObjType TYPE f0fff2e398c34a5cde5006bd1d964226ddee18a7550e552a4e49536607792d7a
2013-05-24T23:23:48+0200 4  -nebReadObjTypeMime FIND application/x-encrypted/rsa
2013-05-24T23:23:48+0200 3  -nebAsymUnEnc OBJ TYPE application/x-encrypted/rsa
2013-05-24T23:23:48+0200 3  -nebAsymUnEnc DECODE cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c 6a4b7f1100b87044b21f0300eb5c8b627e440e6c239b7dc64767dc16fab38719
2013-05-24T23:23:48+0200 3  -nebAsymUnEnc DECODED cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c -> fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 3  -nebObjUnEnc DECODED KEY
2013-05-24T23:23:48+0200 4  -nebSymUnEnc REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 5  -nebReadObjTypeMime REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 6  -nebFindObjType REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 nebule/objet/type
2013-05-24T23:23:48+0200 7  _l_lsx REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 8  _l_ls1 REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 6  -nebFindObjType TYPE f67ae5bf11f82e1037ee44aa79fab49dd4d7c4f66e6efb3f9a157193b1e20f9a
2013-05-24T23:23:48+0200 5  -nebReadObjTypeMime FIND application/x-encrypted/aes-256-cbc
2013-05-24T23:23:48+0200 4  -nebSymUnEnc OBJ TYPE application/x-encrypted/aes-256-cbc
2013-05-24T23:23:48+0200 4  -nebSymUnEnc ALGO aes-256-cbc
2013-05-24T23:23:48+0200 5  -nebFindObjType REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 nebule/objet/encode/InitialVector
2013-05-24T23:23:48+0200 6  _l_lsx REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 7  _l_ls1 REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 5  -nebFindObjType TYPE 4dcabd9342f9d1da7703e050a8887c4d87b06dcea7426d9c0d099bacf763656e
2013-05-24T23:23:48+0200 4  -nebSymUnEnc IV 4dcabd9342f9d1da7703e050a8887c4d87b06dcea7426d9c0d099bacf763656e
2013-05-24T23:23:48+0200 4  -nebSymUnEnc DECODE aes-256-cbc 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0 IV=739c43201f51033e5826db9572bde317
2013-05-24T23:23:48+0200 4  -nebSymUnEnc DECODED IN 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:48+0200 4  -nebSymUnEnc MOVED TO PRIV
2013-05-24T23:23:48+0200 4  -nebObjUnEnc DECODED OBJ
2013-05-24T23:23:48+0200 5  -nebReadEntityFName REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:48+0200 6  -nebFindObjType REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e nebule/objet/nom
2013-05-24T23:23:48+0200 7  _l_lsx REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:48+0200 8  _l_ls1 REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:49+0200 6  -nebFindObjType TYPE f3ca40a0f58333a71523ebe390a71240432eaa5572f4a466d4ed8030b91f0e20
2013-05-24T23:23:49+0200 5  -nebReadEntityFName FIND 201305201327.e837349285b6a040f41bc5371d58c0a7.www.tar
2013-05-24T23:23:49+0200 5  -nebReadEntitySName REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:49+0200 6  -nebFindObjType REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e nebule/objet/suffix
2013-05-24T23:23:49+0200 7  _l_lsx REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:49+0200 8  _l_ls1 REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:49+0200 6  -nebFindObjType TYPE b06912c7bb9360d220e0a7a25449b9012b35f891f4d748cc0f3f0615c1ec48d7
2013-05-24T23:23:49+0200 5  -nebReadEntitySName FIND bz2
2013-05-24T23:23:49+0200 4  -nebObjUnEnc FILENAME 201305201327.e837349285b6a040f41bc5371d58c0a7.www.tar.bz2
2013-05-24T23:23:49+0200 4  -nebObjUnEnc MOVED TO /home/steph/temp/

Et le fichier /home/steph/temp/201305201327.e837349285b6a040f41bc5371d58c0a7.www.tar.bz2 est bien créé.

Mise à jour – librairie bash de référence

L’entité bachue diffuse depuis ce soir une nouvelle version de la librairie bash de référence. Elle est disponible ici :

e7694b8923bfd02d601ddf8235463ceecc0d6913b7d046157107864d0944feb8 (contenu)

C’est une correction de bugg mineur pour la fonction de chiffrement nebAsymEnc . Le bugg entraînait la génération de liens ayant une signature valide mais ayant manifestement une syntaxe invalide.
Les liens invalides, validés jusqu’à présent par l’entité émettrice ainsi que par toutes les autres entités les ayant téléchargés, n’ont pas été nettoyés. Le nettoyage aura lieu lorsque la fonction nebCheckAll sera complète.

Chiffrement et protection des objets

L’entité bachue diffuse depuis ce soir un correctif de la librairie nebule de référence pour bash. C’est l’objet 8906d6148799bc807f2d87566125d02163c6f567c2497b564fbdb19b26156b75 (contenu).

Ce correctif fait suite à la découverte d’un comportement anormal lors du chiffrement asymétrique.

La fonction nebReadObjTypeMime (appelée par la fonction nebObjEncX) permet de déterminer notamment si l’objet entité destinataire à qui on souhaite chiffrer l’objet est bien une clé RSA. La clé RSA est assumé aujourd’hui comme clé publique.
La première action généralement réalisée avec un fichier à chiffrer (ou non), c’est de le nébuliser. C’est à dire de le convertir en objet nebule avec un certain nombre de caractéristiques traduites en liens. Cet objet nébulisé est par défaut placé en espace publique (accessible en ligne dans les objets).
Suite à une modification, la fonction nebReadObjTypeMime ne renvoyait plus aucune valeur de type mime. Ainsi, dans la fonction nebObjEncX, l’entité n’étant pas/plus reconnu comme entité, le chiffrement ne se faisait pas.
Si le processus de chiffrement était interrompu, la fonction nebSymEnc n’était pas appelée. Or, l’une des première action de cette fonction est de déplacer l’objet à chiffrer de l’espace public vers l’espace privé (non accessible en ligne). Sans cette fonction, l’objet à chiffrer se retrouvait ainsi en espace public alors qu’il aurait dû être chiffré puis supprimé.

Le correctif a consisté à :

  1. corriger la fonction nebReadObjTypeMime pour qu’elle retourne une valeur correcte ;
  2. modifier la fonction nebObjEncX pour déplacer tout de suite l’objet à chiffrer, et donc mieux le protéger.

En attendant de trouver la source de cette erreur, il m’a fallu nettoyer à la main les objets qui auraient dû être chiffrés. Ces objets étant pour certains déjà répliqués sur d’autres machines par les entités robots…

CF : 2d0468b3153a1a43861ada08cc0a209df138f581df61b8ebc4cf022ee3d83aef

Openssl sous Centos

Un des robots tourne sous CentOS release 5.9 (Final).

La version de openssl est la OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008. Elle ne permet pas d’utiliser certaines options de la commande rand pour générer des données aléatoires en hexadécimale. Sauf que je l’utilise intensément… pour générer des IV de chiffrement et pour générer des noms de fichiers temporaires.
Donc, le chiffrement ne marchera pas bien en l’état. Et des buggs sont à prévoir dans certaines fonctions…

Pour info, Debian Linux 6.0.7 dispose d’une version un peu datée aussi, la OpenSSL 0.9.8o 01 Jun 2010. Deux ans de différence, ça se sent… mais c’est suffisant pour mes besoins.
Heureusement, on est en 2013 est openssl est packagé en version 1.0.1e.

Priorité des liens à date identique

Comment doivent être interprétés des liens différents et dont la date est identique. Ce peut être le cas d’un lien de type u ayant strictement la même date qu’un lien identique mais de type x.

Est-ce qu’il y a un ordre préférentiel de lecture, et donc inversement de prise en compte ?
Le lien de type x est-il plus important que le lien de type u ou f par exemple?

Aujourd’hui, les implémentations de références doivent traiter les liens dans l’ordre tel que définit dans la documentation de référence. Donc le lien x devient implicitement, par ce que étant le dernier appliqué, celui qui a le plus de poids.