Routage

Une notion nouvelle émerge de l’utilisation des liens et objets de nebule, c’est le routage.

Cette notion est assimilée au routage que l’on connaît en réseau. Le routage réseau est lui-même dérivé du routage de marchandises. C’est à dire le transports de marchandises variées en masse par la route mais répartit sur plusieurs transporteurs, tel des paquets dans le réseau.

Cette notion profonde de transport de quelque chose d’un point à un autre se distingue du transport par commutation (de circuit). Dans le cas de la commutation, c’est comme si l’on réservait pour un temps donné (qui peut être assez long) une voie de circulation complète de façon continue du point de départ au point d’arrivée. Cette préemption de la route est complète que la route soit utilisée ou pas. Cela peut répondre à des besoins spécifiques, voie réservée aux bus, mais en règle générale c’est plutôt générateur d’une grosse perte de rendement.

Avec les liens nebule, il peut se passer un peu comme du routage lorsque les liens sont générés par l’entité source et synchronisées parfois par des chemins différents vers une autre entité. Il en est de même avec un objet qui, si il est fractionné (liens type s), peut être relayé par des entités différentes, voir être déjà des objets issus de plusieurs autres objets eux-même fractionnés.

Le but est ici de s’assurer (ou pas) du bon acheminement des liens et des objets vers une entité tierce. Si les liens, qui sont signés, doivent impérativement être relayés, les objets peuvent tout à fait être ré-assemblés en fonction de fragments déjà présents chez (ou proche de) l’entité destinataire.

Bien sûr, en temps normal, les entités sont tout à fait capables de se connecter directement les unes aux autres sans passer par des relais. Le routage est une notion qui n’interviendra en pratique que entre deux entités qui sont sur des réseaux filtrés, semi-isolés, ou complètement isolés. Dans ce dernier cas, un vecteur est nécessaire entre les deux réseaux (clé USB par exemple)…

Le weblog et la relation d’objets – 2

Suite de la réflexion sur le weblog et la relation d’objets.

La première expérience avec sylabe sur une arborescence d’objets liés montre qu’il faut privilégier les liens de type dérivation f dans cet usage. Le lien de type l permet avec un objet méta de déterminer la relation entre deux objets dans l’arborescence. Mais c’est déjà ce que fait le lien de type dérivation f sans objet méta. Et si l’emplacement de l’objet méta est utilisé, il n’est du coup pas possible de définir ce que l’on peut appeler un contexte. C’est à dire de définir que les deux objets sont dans une arborescence bien délimitée et non tout le temps liés.

Ensuite, des liens de type dérivation f peuvent être utilisés sans objet méta afin de définir un objet dérivé d’un autre de façon générale. La différence, c’est que sans objet méta, le lien n’est pas utilisé dans l’affichage d’une arborescence d’objets. Mais cela n’empêche pas qu’ils soient utilisés pour améliorer l’affichage de certains objets spécifiques dans la représentation de l’arborescence. Ainsi, une arborescence d’images de grandes tailles gagnera à voir chaque image remplacée une à une par une versions réduite. C’est plus adaptée à l’affichage d’un navigateur web par exemple. La version réduite de chaque image étant liée à l’image originale par un lien de dérivation f.

Cette façon de faire résout les cas de gestion d’un article dans plusieurs nœuds et de gestion d’un article à plusieurs endroits dans le même nœud.

Reste à définir le cas de la gestion d’un nœud sous un autre nœud.

OMS et openPDS

Un article intéressant de InternetActu fait découvrir openPDS (Personal Data Store). On y retrouve les bases autour desquelles gravitent un certain nombre de recherches sur l’amélioration de la gestion des données privées. C’est surtout sur leur contrôle de ces données par l’utilisateur légitime, et notamment leur divulgation volontaire à des tiers. C’est un projet fait en collaboration avec ID3 et dont la base technique est Open Mustard Seed (OMS). OMS est à openPDS ce que nebule est à sylabe.

La solution semble reposer sur un espace de stockage et de traitement centralisé. L’espace de stockage est voulu comme étant sous contrôle exclusif et complet de l’utilisateur détenteur. Le traitement centralisé avec les données permet d’extraire une partie des données sans en exporter plus que demandé. L’export de données pour un traitement délocalisé semble poser un problème pour les auteurs de openPDS. Rien ne semble prévu notamment pour conserver localement certaines données en cache ou pour un mode déconnecté. Les données ainsi pré-traitées peuvent être transmises aux tiers extérieurs.

La centralisation du stockage permet logiquement une grande cohérence de gestion des données. Tout étant en un emplacement unique, le traitement peut en permanence accéder à tout. Il est sûrement prévu un mécanisme de sauvegarde des données dans un autre emplacement, mais c’est un autre débat. Cette centralisation va poser à mon avis deux problèmes. Le premier est la disponibilité en cas de panne de l’infrastructure de stockage. La deuxième réserve concerne le traitement. Pour traiter les données, il faut accéder aux données. Mais en permettant à une machine d’accéder aux données, on permet aussi aux administrateurs d’y avoir accès. On retombe finalement sur une sorte de solution de cloud assez classique. Finalement, qu’est ce qui garanti que les données ne sont pas exploitées par derrière par l’opérateur technique du cloud ? En l’état, rien.

L’identité des personnes est assurée par OAuth2 ou OpenID. La confiance dans les identifiants entre personnes est gérée par une notion de rôles, c’est à dire des groupes auxquels on attribue des droits.

Le site de référence de openPDS ne dit pas quelle genre de données peuvent être stockées et traitées, ou plutôt la variété des données. On manipule potentiellement plus que la géolocalisation, des données bancaires par exemple.

OMS semble vouloir de son côté s’assurer de la bonne application des préférences de confidentialité définies par l’utilisateur légitime sur ses données. Il faut voir comment l’implémentation est réalisée, mais la théorie montre que c’est illusoire.

Enfin, l’ensemble se base sur de la cryptographie pour identifier les personnes et leurs échanges avec les PDS. Mais les données ne semblent pas en profiter. Tout se base sur des droits d’accès, donc des droits assez faibles.

Bon, la critique est facile. OMS et openPDS sont encore très jeunes. Il faut voir comment cela évoluera dans le temps…

L’article de InternetActu fait aussi référence à MesInfos, une initiative de la Fing. Ici l’étendue des données est visiblement assez restreinte : consommation, finances, communication, navigation, mobilité, santé, emploi et énergie. En fait, ça regroupe des domaines de données mais pas des types de données. Le but est ici encore de permettre à l’usager de se réapproprier ses données et leurs usages. Est on est ici aussi au stade de la réflexion préliminaire.

Liens :
http://openpds.media.mit.edu/
http://www.internetactu.net/2013/07/03/dautres-outils-et-regles-pour-mieux-controler-les-donnees/
http://idcubed.org/
http://idhypercubed.org/
http://fing.org/?-MesInfos-les-donnees-personnelles-
http://fing.org/

Le weblog et la relation d’objets

La mise en application des objets et liens nebule dans sylabe montre qu’un aspect important de la relation entre les objets a été sous-estimé.

Prenons l’exemple d’un blog ou d’un fil de discussion sur FB (en autres). Un utilisateur publie un article, un texte en fait. A cet article, tous les utilisateurs (ou presque) peuvent répondre, c’est à dire attacher à l’article un nouvel article. Ce nouvel article est aussi un texte, mais il est subordonné à l’article initial.
On peut ainsi ajouter une infinité d’articles subordonnés à l’article initial ou subordonnés les uns aux autres.

Première remarque à priori. L’article initial, celui de plus haut niveau, a tout intérêt à être déclaré comme étant un nÅ“ud. Mais ça n’est pas obligatoire en fait.

Ensuite, le lien entre l’article initial et les articles qui lui répondent est un lien créant une hiérarchie. Les liens nebule de type l ou f peuvent répondre à ce besoin.

La réflexion est cependant incomplète. Il faut tenir compte de :
– la gestion d’un article dans plusieurs nÅ“uds ;
– la gestion d’un article à plusieurs endroits dans le même nÅ“ud ;
– la gestion d’un nÅ“ud sous un autre nÅ“ud.

A suivre…

Mise en ligne du projet annexe sylabe

Je cherchais un nom de domaine pour gérer un projet annexe à nebule, une interface cliente basée sur nebule.

Le nom de domaine à trouver devait commencer par la lettre S, contenir 6 caractères alphabétiques (comme nebule), être relativement facile à mémoriser, et être disponible avec l’extension .com .

Et j’ai trouvé sylabe, version un peu contractée du mot syllabe.
Cela donne comme nom de domaine www.sylabe.org pour héberger le projet. Et le domaine sylabe.com est pré-réservé pour un éventuel besoin futur.

Dans la foulée, un logo dérivé de celui de nebule à été mis en place :

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

Activation de l’annuaire d’entités asabiyya

Introduction

L’entité annuaire asabiyya se charge de parcourir régulièrement les entités qu’elle connaît à la recherche de nouvelles localisations d’entités et de nouvelles entités.

Elle est validée par puppetmaster.

Description

Toutes les entités ne connaissent pas toutes les autres entités, et encore moins leur localisation à tout instant. Le rôle de l’annuaire est de référencer des ressources ainsi que leurs emplacements. Ici les ressources sont des entités et leurs emplacements sont leurs localisations sur le réseau numérique.

L’annuaire est dans nebule la première étape du lien social entre toutes les entités.

L’entité annuaire asabiyya se met à jour à intervalle régulier. Aujourd’hui, l’intervalle est de une heure. Pour cela, elle commence par récupérer chez toutes les entités qu’elle connaît les liens de l’objet nebule/objet/entite/localisation . Ensuite, à partir de ces liens qu’elle parcourt, elle recherche uniquement les liens spécifiant une localisation d’entité et en extrait l’identifiant de l’entité ainsi que l’identifiant de la localisation. L’objet de chaque entité ainsi identifiée (c’est à dire la clé publique) est téléchargé si sont type-mime est application/x-pem-file. Pour les localisations, c’est à la fois les liens et l’objet contenant la localisation qui sont téléchargés si le type-mime de l’objet est text/plain. Le type-mime étant un lien, le fait de synchroniser en premier les liens d’un objet permet de connaître sont type-mime sans le télécharger. Continuer la lecture de Activation de l’annuaire d’entités asabiyya

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.

Genèse du monde – Mise à jour

001
Le premier jour, dieu créa l’objet, l’essence de tout chose.
Ainsi la matière de l’information naquit du néant.

010
Le deuxième jour, dieu créa le lien, pour les relier tous.
Ainsi apparurent les objets à la lumière, ils pouvaient se voir mutuellement.
Ainsi l’univers informationnel naquit des objets et des liens.

011
Le troisième jour, dieu créa l’entité.
La matière inerte et uniforme devint active et protéiforme.
Ainsi la vie naquit de la matière et des entités.

100
Le quatrième jour, dieu créa la signature.
L’univers informe s’illumina du feu des entités attirants inexorablement les objets.
Ainsi les nébuleuses naquirent des entités.

101
Le cinquième jour, dieu créa le nœud.
A l’intérieur des nébuleuses, les objets se rassemblèrent en orbites autour des nÅ“uds et des entités.
Ainsi les galaxies naquirent des nébuleuses.

110
Le sixième jour, dieu créa le cryptogramme.
Pour la première fois, la matière des objets commença à disparaître de la lumière.
Ainsi les trous noirs naquirent des entités.

111
Le septième jour, dieu créa l’interface.
Elle permit à l’homme de voir l’univers.
Ainsi l’univers fut achevé.

8
Le huitième jour, au nom de dieu, l’homme créa la religion.
Il s’appropria tous les objets et soumit toutes les entités sous une seule.
Ainsi disparut l’univers dans un trou noir super-massif.

IPv6 et nebule

Il est parfois bien difficile de se préparer à l’avenir et d’abandonner les choses au passé.

Il est une chose qui devrait déjà appartenir au passé, ou du moins être en voie d’extinction, voir entretenu par quelques antiquaires : IPv4 !!!

IPv6, c’est le futur.
Ce devrait même être le présent en fait… mais c’est encore considéré comme le futur. Même en France beaucoup de gens n’ont pas nativement accès à l’Internet en IPv6, leur FAI (ou ISP) ne l’implémente pas. Cela ne veut pas dire forcément de systématiquement l’utiliser, mais juste de pouvoir le faire.

Et pour nebule ?
Bonne nouvelle, l’implémentation en bash fonctionnement indifféremment en IPv4 et IPv6. En fait, c’est parce que cela ne dépend que de l’hôte. Si celui-ci a un accès IPv6, les programmes savent l’utiliser. D’ailleurs, on peut aller plus loin. Si l’hôte n’a que IPv6, ça marche aussi !

Donc, depuis hier soir, toutes les entités importantes de nebule sont accessibles aussi en IPv6 :

Entité annuaire – Mise en ligne

Comme annoncé dans le post sur l’entité annuaire, une entité vient d’être créée :

4e72933c991c2bb27415cfeff02e179b9a3002934e472142c4f612e3893e46e1

Elle se nomme asabiyya et est localisée en http://asabiyya.nebule.org/ et http://asabiyya6.nebule.org/ (IPv6).

Le script qui va lui permettre l’auto-découverte des autres entités n’est pas encore en place, mais il devrait être assez rapide à faire. Il s’agit en fait de parcourir toutes les entités déjà connues en cherchant l’objet contenant nebule/objet/entite/localisation (0f183d69e06108ac3791eb4fe5bf38beec824db0a2d9966caffcfef5bc563355).

On constate visuellement dans les liens la différence entre une clé RSA de 2048 bits et une autre clé RSA de 4096 bits, celle de puppetmaster. La signature est deux fois plus longue et donc les liens ont une taille qui double presque.

Entité annuaire

L’annuaire a deux fonctions principales. La première est de référencer toutes les instances connues d’un certain type de ressource. La deuxième est de transmettre une localisation (physique ou numérique) pour chacune des instances concernées. Le type de ressource, le type de localisation ou le caractère privé de l’annuaire ont une incidence sur l’exploitation d’un annuaire mais ne remettent pas en cause significativement son fonctionnement.

Dans nebule, un annuaire permet de référencer des entités ainsi que leur localisation numérique.

Une entité va être créée pour répondre à ce besoin. Cette entité aura le nom de Asabiyya (cf wikipedia).

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

Référence des librairies en bash – suite

La mise en place de la Référence des librairies en bash est fonctionnelle. La deuxième version de cette librairie est en ligne ici :

http://bachue.nebule.org/l/a3f3211a21174f7a4d719a8d0db08777dd8fb53742816440461a337ab5ea0b5d

Notamment, on voit bien apparaître en dernier les liens f et u. Extrait simplifié :

nebule/liens/version/1.1
4a778c.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_5d5b09f6dcb2d53a_8e2adbda190535721
e6d529.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_5d55e03f2d47d270_0
44451c.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_92127d432cc786d8_5312dedbae053266a
b98a1c.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_204159611b85c906_31e415a2fb3a47fd1
869b43.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_7931aa2a1bed8554_8b2520354f930f569
e37c40.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_c97550ce8213ef5c_9c3b5b12eb4e6aa7f
dafba8.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_0b8efa5a3bf10441_3dbea4b46d525a78d
d32916.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_535fa30d7e25dd8a_4ad634a7140931341
b8a946.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_9f14025af0065b30_3aa88d2c571cd17c3
8babc4.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_8527a891e2241369_9520b18653418ae08
aa975b.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_23d78c3b5451a304_b5a33ef345fb537a3
a0ac39.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_aa4e255307ea7ff2_940c75a60c14a24e5
bed805.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_89c4ec9f6b3f1086_fd7d447334feb3d03
d678fc.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_a8d605ad6b35649a_a5e056d51490d9b34
a7c90b.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_594d1ede91cf77b7_e207a4ac0f703d21d
2ae0ea.sha256_19762515dd804577f_2013-05-03T23:35:13_u_13664cda947381d6_a3f3211a21174f7a_0
032638.sha256_19762515dd804577f_2013-05-03T23:35:13_f_2d0468b3153a1a43_a3f3211a21174f7a_0

Quantification commune de la disponibilités des relais – suite

Suite au post sur la Quantification commune de la disponibilités des relais, je vais essayer de mettre en place une solution dans l’implémentation bash de référence.

Cette solution consistera, lors du téléchargement d’un objet, de vérifier quelle localisation contient l’objet (options spécifiques de wget) et de mesurer le temps de réponse instantané à cette requête.

Pour accélérer le téléchargement des liens sans remettre en question la vérification systématique de ceux-ci, je pense déjà à une solution. Mais elle implique des changements en profondeur du code dans ses parties téléchargement, génération et enregistrement des liens. Il faut aussi prévoir le cas où une entité ne serait pas capable de gérer cette amélioration…

En attendant de pouvoir travailler sur ces améliorations, je dois terminer l’implémentation complète du chiffrement.

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.