Archive for the ‘Implémentation’ Category

Fusion des monnaies dans la bibliothèque

Dimanche, octobre 13th, 2019

Plutôt que de laisser tout dans une application et un module, la gestion des monnaies a migré vers la bibliothèque nebule.

C’est plus simple pour l’application mais cela a nécessité pas mal de modifications dans la bibliothèque. Cela veut dire aussi que la documentation dispose maintenant d’une partie dédiée.

Premiers essais pour bientôt !

Options et subordination

Dimanche, octobre 6th, 2019

Suite des articles Liens des options et Lien à quatre champs objets.

Il paraissait intéressant de pouvoir définir les options d’une entité sous contrôle comme une instance sur un serveur. Cela voulait dire contextualiser le lien or les trois champs des liens de définition des options étaient déjà utilisés. Mais comme il est possible de fusionner le champs option avec le champs définissant de quelle option on traite, cela libère une champs pour une entité cible.

Les liens de modification des options ont été changés dans la bibliothèque nebule afin de prendre en compte ce changement. L’entité est en champs source. Le hash de la valeur de l’option est en champs cible. Et le champs méta contient le hash du nom de l’option préfixé par nebule/option/.

Et une nouvelle option subordinationEntity permet de définir une entité de subordination, c’est à dire une entité qui peut forcer les options. C’est utiliser typiquement pour définir les options d’une instance sur un serveur distant (qui n’est pas sous contrôle physique). Cette option est en lecture seule, c’est à dire qu’elle ne peut être modifiée que via le fichier d’environnement.

L’option doit renvoyer un identifiant d’entité mais plus tard il sera possible de mettre en groupe d’entités…

Le bootstrap affiche maintenant aussi cette entité de subordination dans la page d’interruption.

La documentation décrit cette évolution :

CCOL / Options via Liens

Dans les deux méthodes pour gérer les options, il y a le lien d’option. Toutes les options, à l’exception de celles dites en lecture seule, peuvent être définies par les liens d’options correspondants.
Toutes les options définis par des liens sont attachées à des entités. C’est à dire que le lien d’une option doit contenir l’entité à laquelle s’applique le lien. L’utilisation ou non de l’option se fait par l’entité si le lien lui appartient ou si elle est subordonnée à l’entité signataire du lien (voir CCOS). Les liens de l’entité de subordination sont prioritaires sur les liens propres.
Toutes les options inscrites dans le fichier des options sont dites forcées et ne peuvent être surchargées par un lien d’option.
La valeur de l’option doit être présente ou écrite dans l’objet correspondant. Si la valeur de l’option ne peut être lu, elle ne sera pas prise en compte. Le nom de l’option n’a pas besoin d’être écrit dans l’objet correspondant, il est déjà défini dans le code.
Les options définis par les liens ne sont pas prises en compte par la bibliothèque nebule en PHP procédurale du bootstrap.
L’option se définit en créant un lien :

  •     Signature du lien
  •     Identifiant du signataire
  •     Horodatage
  •     action : l
  •     source : ID entité visée
  •     cible : hash(valeur de l’option)
  •     méta : hash(‘nebule/option/’ + nom de l’option)

Liste des options non modifiables via des liens :

  •     Option ‘puppetmaster’
  •     Option ‘permitWrite’
  •     Option ‘permitDeleteObjectOnUnknowHash’
  •     Option ‘permitCheckSignOnVerify’
  •     Option ‘permitCheckObjectHash’
  •     Option ‘permitListInvalidLinks’
  •     Option ‘permitInstanceEntityAsAuthority’
  •     Option ‘permitDefaultEntityAsAuthority’
  •     Option ‘permitRecoveryEntities’
  •     Option ‘permitRecoveryRemoveEntity’
  •     Option ‘permitInstanceEntityAsRecovery’
  •     Option ‘permitDefaultEntityAsRecovery’
  •     Option ‘permitJavaScript’
  •     Option ‘modeRescue’
  •     Option ‘displayUnsecureURL’
  •     Option ‘subordinationEntity’

CCOS / Subordination

Une entité peut définir ses propres options mais peut aussi se voir défini ses options par une autre entité. C’est principalement utilisé afin de piloter des instances sur des serveurs distants.
La mise en place de ce mécanisme permet de maintenir autant que possible le contrôle sur un serveur que l’on ne maîtrise pas physiquement. Elle est mise en place via l’option subordinationEntity en lecture seule écrite dans le fichier des options. Cela veut dire aussi qu’une entité peut être compromise et pilotée à distance si le fichier des options est modifié par une entité tièrce.
La subordination peut être faite vers une seule entité, défini par son identifiant, ou pour un groupe d’entités. La gestion du groupe n’est pas encore fonctionnel, seule une entité peut être défini.
La subordination n’est pas prise en compte par la bibliothèque nebule en PHP procédurale du bootstrap.

Export des articles de blockchain et transaction vers le blog de qantion

Dimanche, septembre 29th, 2019

Les projets développés autour de nebule avaient peu de réflexions propres et les différentes réflexions revenaient invariablement à la gestion d’information, donc vers le blog de nebule. Il n’en est pas tout à fait de même pour les réflexions sur la blockchain et les transactions qui sont souvent propres au projet qantion aujourd’hui mis en place.

Afin de garder une cohérence dans les réflexions menées sur le nouveau blog dédié à qantion, les différentes articles du blog de nebule traitants de blockchain et de transactions ont été dupliqués ici et anti-datés.

Toutes nouvelles réflexions liées à la blockchain ou aux transactions seront faites sur le blog de qantion, et seront dupliquées ici si elles intègrent aussi une réflexion de portée plus fondamentale sur la gestion d’information.

Nouvelle application qantion

Lundi, septembre 9th, 2019

Les réflexions sur les crypto-monnaies commencent à prendre beaucoup de place et de temps de réflexion. Il est temps de démarrer une application à part entière dédiée à la crypto-monnaie basée sur nebule.

Après une phase de réflexion sur un nom possible, percutant, porteur de sens… et encore disponible dans les noms de domaines sur Internet, c’est finalement qantion qui s’est imposé.

Il désigne le plus petite élément de quantification.

Une autre alternative de noms partait sur deux noms proches (et eux aussi disponibles) pour porter les deux facettes des monnaies, c’est à dire une locale et une globale avec deux fonctionnements différents.

Donc, nous avons blog.qantion.org pour le suivi du projet et qantion.com pour le démonstrateur.

Transcodage et translation

Lundi, août 19th, 2019

Suite aux articles Anonymisation/dissimulation des liens – ségrégation partielle, transcodage, Transcodage des liens dissimulés et Anonymisation des fichiers transcodés, il était apparu un problème avec le contenu des fichiers transcodés.

Le transcodage des identifiants des objets pour lesquels on dissimule des liens permet de stocker ces liens dans des fichiers non directement associés à l’identifiant de l’objet concerné. C’est en fait une translation d’identifiant.

Ces objets ‘virtuels’ translatés doivent pouvoir être partagés par transfert ou synchronisation sans risquer de dévoiler l’association entre l’identifiant en clair et l’identifiant translaté.

Le système de translation aujourd’hui mis en place est basé sur une clé unique de translation par entité. Cette translation doit être une fonction à sens unique, donc à base de prise d’empreinte (hash), y compris lorsqu’une ou plusieurs translations sont connues. Enfin, la translation doit être dépendante de l’entité qui les utilise, c’est à dire qu’une même clé peut être commune à plusieurs entités sans donner les mêmes translations.

Dissimulation, transcodage et dossier privé

Samedi, juillet 20th, 2019

La réflexion de l’article Anonymisation/dissimulation des liens – transcodage est très intéressante parce qu’elle rejoint la réflexion originel de nebule implémenté en bash pour les expérimentations. Cette implémentation en bash est clairement mono-entité, c’est à dire à l’usage exclusif d’une entité là où une implémentation en php comme l’application sylabe permet un usage multi-entités simultané.

L’implémentation en bash utilise un dossier nommé /pub pour recevoir les dossiers o et l contenants les objets et les liens dits publiques, ou plutôt publiables. Ce dossier /pub peut être partagé via un serveur web. Mais il y a aussi un dossier nommé /priv qui lui reçoit des dossiers o et l contenants les objets et les liens dits privés, donc non publiables. Le dossier des objets privés permet de recevoir le contenu des objets protégés et déchiffrés le temps de leur utilisation. Le dossier des liens privés n’a jamais été utilisé mais il correspond tout à fait à ce que l’on essaye de faire aujourd’hui avec le transcodage pour les liens de dissimulation.

La structure typique des dossiers de l’implémentation en bash :

/home/user
   +-> /neb
       +-> /pub
       |   +-> /l
       |   +-> /o
       +-> /priv
           +-> /l
           +-> /o

Or le problème de la dissimulation est facile à résoudre sans transcodage dans l’implémentation bash. Mais ce n’est pas transposable dans l’implémentation en php à cause de la notion cité plus haut de capacité multi-entités simultané. Les fichiers transcodés contenants les liens dissimulés répartis par ID d’objets sont le pendant direct des liens du dossier /priv/l.

Anonymisation/dissimulation des liens – transcodage

Samedi, juillet 20th, 2019

Suite à l’article Anonymisation/dissimulation des liens – ségrégation et temporalité et ségrégation partielle, la réflexion et l’implémentation sur le stockage et l’échange des liens dissimulés progresse.

La méthode de ségrégation des liens dissimulés développée est suffisante pour retrouver les liens dissimulés et les partager. Mais si le partage est efficace parce que l’on ne récupère que les liens dissimulés des entités connues, la lecture des liens n’est clairement pas efficace.

Lors de la consultation des liens d’une objet particulier, il faut lire tous les liens de l’objet, facile, et lire l’intégralité des liens dissimulés parce que l’on ne sait pas à l’avance quelle entité à dissimulé des liens pour cet objet. Il manque de pouvoir localement (indépendamment du partage) stocker les liens en fonction des objets source, cible et méta. Mais il faut aussi ne pas dévoiler cette association d’objets cités dans la partie dissimulée du lien, ce qui permet rapidement de lever la partie dissimulée.
Il est possible de transcoder les identifiants des objets cités par le lien dissimulé. On parle bien de travailler toujours sur des fichiers de stockage dédiés aux liens dissimulés, et donc indépendamment des liens non dissimulés. Ce transcodage doit permettre de ne pas révéler l’association entre les objets cités par le lien dissimulé. Ce transcodage peut être commun à tous les objets avec une clé de codage commune, ou chaque objet peut disposer de sa propre clé de codage. Et bien sûr, chaque entité dispose de sa/ses clés de transcodage, donc chiffrées avec la clé privée.
Un transcodage avec une clé unique est plus facile puisque l’on peut chiffrer cette clé et la stocker à un endroit unique, mais il est moins sûr que le transcodage à clés individuelles.
Pour commencer on va partir sur la base de la clé unique de transcodage.

Les liens dissimulés dans des fichiers transcodés sont lisibles publiquement et peuvent potentiellement être synchronisés mais ils n’ont pas vocation à remplacer les liens dissimulés dans les fichiers dédiés à la ségrégation et utilisés lors du partage des liens.

Le nettoyage des fichiers des liens dissimulés et transcodés devient un nouveau problème.
Plusieurs entités pouvant localement générer des liens dissimulés, et donc utiliser des clés de transcodage différentes, il n’y a pas de méthode de nettoyage générique des liens dissimulés dans les fichiers transcodés. Seule une entité peut faire le nettoyage de ses propres fichiers transcodés. Il faut donc que ces fichiers transcodés soient clairement associés à une entité.

Il est possible par contre de supprimer tous les fichiers transcodés d’une entité (ou plus). Il faut dans ce cas que l’entité, une fois déverrouillée, reconstitue ses fichiers transcodés.
Cela lève un nouveau problème, comment savoir que tous les fichiers transcodés sont présents et qu’ils sont à jour. Avec cette méthode, il ne faut pas que les fichiers dédiés à la ségrégation des liens dissimulés pour une entité soient manipulés par une autre entité parce que les fichiers transcodés ne seront pas synchrones. Et les transferts ne sont pas possibles.

Les entités ne doivent pas synchroniser les liens dissimulés des autres entités !

Il reste encore des réflexions à mener autour de cette méthode de transcodage.

Implémentation de la gestion des liens dissimulés

Vendredi, juin 28th, 2019

La bibliothèque nebule en php orienté objet est en cours de modification pour être capable de gérer les liens dissimulés.

La classe qui gère les I/O reçoit une nouvelle fonction parce que la demande de liens dissimulés ne se gère pas de la même façon que les autres liens.
La partie écriture a été modifiée aussi afin de détecter si le lien à écrire est dissimulé ou pas. Dans le cas d’un lien dissimulé le fichier de stockage est différent.
Et lors de la lecture de liens dissimulés, il est possible de préciser un signataire, ce qui cible directement un seul fichier de liens à lire.

La classe qui gère les liens va être modifiée pour être capable d’interroger la classe des I/O pour les liens dissimulés ou non.

Liens hypertexte et insertions

Lundi, avril 29th, 2019

Liens hypertexte

Le lien hypertexte a fait le succès de l’Internet en permettant depuis un document HTML de pointer vers d’autres documents HTML, ou d’autres ressources, et sur d’autres serveurs à travers tout l’Internet. C’est tellement pratique que d’autres programmes reprennent le même principe, par exemple les outils de bureautique qui permettent de pointer vers des fichiers externes sur le réseau ou localement sur la machine.

Le lien hypertexte ou ses équivalents utilisent une balise dans le texte du document. Cette balise est interprétée par le programme exploitant le document pour l’utilisateur. Et à la place de la balise on montre à l’utilisateur un contenu descriptif sur la destination comme un texte ou une image.

Dans les objets manipulés par nebule, il est possible d’ajouter une balise propre à nebule. Cette balise ne peut pas être la même que pour un document HTML parce que les objets peuvent ne pas être exploités via une page web. La balise doit se déclarer comme balise nebule et faire référence à un objet avec un élément de remplacement. Dans le cas de l’application sylabe, la balise sera remplacée par un lien HTML pointant vers l’objet mais sur le même serveur web.

Ici pas de nécessité de localisation dans la balise parce que la cible, un objet, est une URI et non une URL. Et le protocole n’est pas précisé parce que c’est le programme qui génère l’affichage qui va se charger de choisir le moyen de renvoie, HTTP, FTP, SMTP, XMPP, etc…

Insertions

Mais de la même façon, une balise peut être utilisée pour non plus renvoyer l’utilisateur vers une ressource externe mais plutôt pour inclure une ressource dans l’affichage présenté à l’utilisateur d’un objet. On obtient ainsi plusieurs contenus affichés en même temps par l’intermédiaire d’un seul objet maître.

C’est ce qui est fait par exemple dans l’inclusion de parties dans une page d’un Wiki.

Cela veut dire que les objets contenus doivent être présents sur le serveur pour permettre un affichage complet. Dans le cas contraire il devra être montré clairement à l’utilisateur qu’une partie du contenu manque.

Chaque objet peut avoir une mise à jour. Il est judicieux pour un même objet maître de ne pas suivre les liens de mise à jour des objets contenus. Mais il est possible de générer et de suivre les mises à jour de l’objet maître intégrant celles des objets contenus.

Liens des options

Mardi, février 26th, 2019

Le lien permettant de définir une option, si elle est autorisée à être modifiée, est constitué d’un type l, du nom de l’option, de sa valeur et d’un objet méta de référence nebule/option.

Cette forme de lien est bonne pour un usage locale et personnel des options. Mais il se prête mal à la gestion des options d’entités sous contrôle. Par exemple si on a un serveur de diffusion de contenu, on peut être amené à changer son comportement. Cette forme de lien impose dans ce cas de générer un lien avec l’entité instance du serveur… et donc de connaître obligatoirement son mot de passe.

Peut-être serait-il judicieux de changer maintenant la forme du lien pour inclure une entité. L’objet méta n’a pas grande utilité ici comme référence fixe. La référence pourrait devenir le nom de l’option… et les noms des options deviendraient des objets réservés.

Suite au prochain épisode…

Gestion du cache des objets et liens

Lundi, février 25th, 2019

La bibliothèque nebule gère maintenant mieux le cache des objets et des liens.

Jusque là tous les objets et liens lus étaient mis en cache. Cela pouvait conduire assez rapidement à une dépassement de la mémoire disponible pour un processus PHP.

Maintenant l’option sessionBufferSize permet de limiter la taille du cache. Par défaut l’option est à 1000. Cette limitation est tout compris, que ce soit les liens ou les différents types d’objets.

Chaque entrée du cache est maintenant datée de sa création ou de sa dernière re-création, c’est à dire à chaque fois qu’elle est utilisée. Au besoin, une place est faite dans le cache pour la nouvelle entrée en supprimant la plus ancienne, càd celle qui n’a pas été utilisée depuis le plus longtemps.

Et en fait cela accélère le calcul des pages parce que l’on a moins de choses à recharger de la session PHP.

Options de désactivation de protection et de dissimulation

Mardi, février 19th, 2019

La protection des objets est fonctionnelle. La dissimulation des liens des objets pas encore. Les deux sont implémentés dans la bibliothèque nebule.

Mais il y a désormais des options pour les désactiver, elles sont activées par défaut :

  • permitProtectedObject : Cette option active la possibilité de gérer la protection des objets et la possibilité de prendre en compte les liens de type k.
  • permitObfuscatedLink : Cette option active la possibilité de gérer la dissimulation (offuscation) des liens des objets et la possibilité de prendre en compte les liens de type c.

Lorsque une option est désactivée, le type de lien correspondant n’est plus géré, il est explicitement refusé. C’est à dire que les liens existants sont ignorés et les nouveaux liens sont rejetés comme invalides.

Ces options sont encore en cours d’ajout dans le code mais sont déjà fonctionnels pour les liens.

Filtre social de liens sur réputation du signataire

Vendredi, février 15th, 2019

Dans les filtres sociaux des liens, deux nouveaux types sont ajoutés : reputation et unreputation

Cela permettra à terme le tri par rapport à la réputation d’une entité. Cependant, la pondération des entités n’étant pas implémentée, ces deux filtres sont pour l’instant équivalents au filtre social none.

Traitement social des liens sur liste

Jeudi, février 14th, 2019

Typiquement, dans une conversation, on peut n’afficher les messages que de certaines entités. C’est le cas si on a marqué la conversation comme fermée.

Jusque là on listait les liens de tous les messages de la conversation puis le module filtrait les liens par rapport aux entités de la conversation.

Maintenant, la bibliothèque nebule intègre dans la partie calcul social deux nouvelles façons de filtrer les liens : onlist et offlist
Il faut préalablement envoyer au module de filtre social la liste des ID des entités que l’on veut garder ou filtrer puis appeler le filtre.

Cela centralise le processus et simplifie les applications et modules.

Soi-même ou moi-même

Mercredi, février 13th, 2019

Dans la partie gestion sociale de la bibliothèque de nebule, il y avait peu de sous-parties dédiées à des calculs sociaux des liens. Il y avait notamment une partie self dédiée à la reconnaissance de ses propres liens, et son inverse notself pour exclure ses propres liens d’une recherche.

Cependant, la bibliothèque reconnait en quelque sorte deux type de soi. Il y a le soi de l’entité connectée et le soi de l’entité que l’on regarde. En quelque sorte un moi et un soi. Quand on désigne moi-même il est fait explicitement référence à ma personne, ou dans notre cas à son entité. Alors que le soi-même désigne le moi-même d’une personne, qui peut être quelqu’un d’autre, dans notre cas une autre entité.
Dans la bibliothèque, cette distinction apparaît dans la place de deux variables qui portent le même nom $currentEntity. Utilisée dans la classe très généraliste nebule, elle désigne l’entité connectée (déverrouillée). Utilisée dans la classe Applications elle désigne l’entité que l’on regarde, de la même façon que l’on désigne un objet que l’on regarde.

Cela a mené à devoir dissocier le traitement social pour refléter cette distinction. Ainsi self et notself références maintenant l’entité que l’on regarde (au travers d’une Application). Et myself et notmyself désigne l’entité connectée elle-même, c’est à dire l’entité active.

Ce comportement peut parraître subtil mais il prend tout son sens dans l’application messae et le module messagerie de sylabe. en effet, l’affichage de la liste des conversations se fait par rapport à une entité, donc des conversations de soi-même d’une entité. Mais si on ne précise pas d’entité alors c’est de l’entité connectée que l’on parle, donc soi-même.

D’autres types de traitement sociaux des liens seront ajoutés plus tard. Il faudra notamment trouver un moyen de pondérer les liens de ses amis…

Réorganisation des entités spéciales – gestion

Jeudi, janvier 17th, 2019

Suite des articles Réorganisation des entités spéciales – inventaire de départ. et groupes d’entités.

L’application option permet aujourd’hui d’afficher les autorités globales et locales. Cette interface avec l’instance nebule du serveur doit être le seul point de gestion de ces entités et de leurs rôles. Cette application va donc devoir évoluer pour prendre en compte les évolutions des entités spéciales, et pas seulement les afficher.

Bonne année 2019

Dimanche, janvier 13th, 2019

Une nouvelle année signifie la mise à jour de toutes les dates à côté des licences… que ce soit dans les différents code mais aussi des sites web statiques et des blogs.

Aucune publication de code n’a été faite depuis le 8 mai 2017. Les différentes applications sont toujours en cours de ré-écriture avec la nouvelle partie graphique intégrée à la bibliothèque nebule. Et elles rejoignent progressivement la mise en pratique de la Réflexion sur l’évolution de l’interface web pour nebule. Cependant une publication en cours de migration avec des modifications partielles serait catastrophique pour l’utilisabilité des applications.

Par rapport à début 2018, la réorganisation de la partie graphique est bien avancée. De nouvelles réflexions se font sur une possible implémentation de crypto-monaie basée sur nebule, et donc sur la réliance que l’on peut en espérer. Les réflexions continent aussi sur la réorganisation des rôles provilégiés par groupes.

La documentation technique de nebule migre maintenant vers une pseudo-application dédiée gérée par le bootstrap. Mais la documentation est en fait contenu, et mise à jour, par la bibliothèque.

Création d’objet et dissimulation des liens

Dimanche, septembre 23rd, 2018

Lors de la création d’un objet, quel qu’il soit, génère au minimum un lien de définition du hash de l’empreinte. Sauf que la création par défaut de liens peut perturber voir anéantir la dissimulation de la création de l’objet.

Certains liens peuvent être dissimulés au moment de la création ou à posteriori, mais le lien de l’empreinte doit rester visible sous peine de perturber la vérification des objets. Il est possible cependant d’anti-dater le champ date de ce lien pour lui retirer toute référence à une plage temporelle de création. Mais il restera et sera un marque d’association du créateur de l’objet si par ailleurs l’objet a un lien d’usage non dissimulé, y compris d’une autre entité.

Le lien d’annulation de suppression d’un objet est moins critique, si dissimulé il fonctionnera toujours.

Les autres liens définissants des propriétés de l’objet peuvent être aussi dissimulés sans problème.

Le code de la bibliothèque nebule en php intègre ces modifications pour les objets, les groupes et les conversations. Seules les entités ne sont pas concernées, leurs contenus ne pouvant être protégés, dissimuler les liens n’a pas de sens.

Penser à supprimer le lien de l’empreinte reviendrait à faire apparaître l’algorithme dans le lien… et donc à changer significativement la forme des liens et le fonctionnement de nebule.

Non vérification crypto et lecture seule – Centre de données et répartition

Samedi, septembre 15th, 2018

Suite de l’article sur la Non vérification crypto et lecture seule.

Le problème des très gros objets peut être résolu avec un fonctionnement segmenté de l’application. D’un côté on a l’application principale qui structure et délivre des informations aux utilisateurs, par exemple la page de diffusion des vidéos. Et de l’autre un serveur uniquement dédié au stockage des objets volumineux.

L’application principale peut fonctionner classiquement sur une ou plusieurs instances et faire référence à du contenu, y compris volumineux, hébergé sur un autre serveur. Le contenu est constitué d’objets parfaitement référencés par leurs empreintes et dont l’usage est définit par des liens. On ne fait là qu’exporter le problème des gros objets.

Un serveur uniquement dédié au stockage des objets volumineux va devoir résoudre le problème de la vérification des objets volumineux sans avoir à se poser de question sur leurs pertinences. La pertinence des données, ce sont les applications qui la gère avec les liens. Ce serveur devient ainsi un centre de distribution de données (CDN) dont la stratégie de vérification peut être adaptée. Et là, l’usage des instances sur ces serveurs étant très restreint en fonctionnalité, il est possible d’alléger la vérification des objets. La vérification peut ne plus être systématique avant un téléchargement par un client mais peut être préprogrammée périodiquement lors de faibles sollicitations. Cela veut dire qu’il faut faire confiance à un serveur qui, peut-être, n’est pas entièrement sous contrôle. Il reste possible bien sûr de vérifier la validité des objets après téléchargement.

Reste un petit engrenage à ajouter là dedans. Il faut que la ou les applications, dans des instances différentes, soient capable non seulement de manipuler la référence d’un objet volumineux sans l’avoir effectivement à portée, mais soient aussi capable de faire pointer l’utilisateur sur le bon point de stockage de l’objet volumineux. C’est à dire qu’elles soient capable de désigner le bon centre de données au bon moment.
Pour cela, soit chaque application dispose d’une configuration définissant quel (unique) centre de données utiliser pour les objets dont la taille (défini par un lien de propriété) est supérieure à une limite de vérification. Soit l’application crée un lien (de propriété) définissant pour chaque objet volumineux sur quel centre de données il est disponible. La première solution est la plus simple, la seconde est la plus souple, et les deux peuvent cohabiter.

L’air de rien, le lien définissant sur quel centre de données est disponible un objet volumineux, la deuxième solution, existe déjà. Pour une entité il est possible de définir un lien avec pour objet méta ‘nebule/objet/entite/localisation‘ afin de donner des points de présences d’une entité. Cet objet méta réservé, non utilisé aujourd’hui, pourrait être abandonné et directement remplacé par l’objet méta ‘nebule/objet/localisation‘ plus générique. Ça tombe bien, ce dernier existe déjà… ne reste maintenant qu’à l’implémenter dans le code…

Non vérification crypto et lecture seule

Dimanche, août 12th, 2018

Dans la réflexion de créer une application dédiée à la manipulation de photos et de vidéos se pose invariablement la question des vidéos HD, FHD et UHD. La taille de ce genre de vidéo, pour conserver une qualité de restitution optimale, est assez conséquente.

Le problème ici dans nebule c’est la vérification systématique de la validité du contenu d’un objet manipulé, c’est à dire le re-calcul de son empreinte cryptographique. Si la librairie nebule mémorise le temps d’une session un objet vérifié, dans un cache, ce qui peut déjà présenter un problème de sécurité, il faut cependant toujours faire cette prise d’empreinte au moins une fois.
Par exemple l’empreinte SHA256 d’un fichier de 1,6Go va nécessiter environ 30s sur un disque dur à plateaux normal. La consommation de temps vient principalement de la lecture du support et non du calcul cryptographique. Et la prise d’empreinte cryptographique est un calcul relativement simple…

Il peut en être de même avec les liens qui nécessitent une vérification de signature de type RSA ou équivalent. Ce calcul en cryptographie asymétrique est beaucoup plus long rapporté à la quantité de données. Si un lien ne faire que quelques kilo-octets tout au plus, le nombre de liens à vérifier pour un seul objet peut être potentiellement gigantesque. Au cours du développement des applications de nebule il n’est pas rare de devoir nettoyer à la main les liens de la bibliothèque parce qu’il y en a plus de 80.000 … soit systématiquement 80.000 lien à lire et à vérifier. Là aussi un cache des liens déjà validés dans la session est en place pour accélérer le travail mais ce n’est pas toujours suffisant.

Une possible résolution de ce problème peut être de changer de disque et de passer sur SSD, ou de nettoyer sévèrement les liens utilisés. Mais ces deux cas sont extrêmes et pas toujours réalisables.

Une autre solution peut être envisageable dans le cas de machines de relais ou de partage d’informations en particulier. Comme on l’a vu dans l’article Frontal et relai d’information verrouillé en écriture, il est possible d’avoir des serveurs en lecture seule en activant l’option de lecture seule ou en figeant le système de fichiers. Cela pose des contraintes particulières sur la synchronisation des objets et des liens et sur le fait qu’ils doivent être vérifiés à un moment ou à un autre. Dans ce cas on peut coupler une option de non vérification des objets et des liens avec une option de lecture seule.
Avec cet exemple une entité peut toujours d’authentifier afin d’accéder à du contenu protégé mais ne pourra réaliser aucune action.

On peut imaginer aussi que l’application de mise à jour (upload) peut être autorisée à mettre à jours des liens et des objets en les vérifiant et ainsi avoir un serveur partiellement en lecture seule.

Donc il serait possible d’avoir un serveur de relai d’information en lecture seule uniquement mais avec un fonctionnement accéléré.
Ceci n’est pas implémenté actuellement.