Bootstrap niveau de code

La stratégie de développement du bootstrap mérite une petite explication.

Ce « petit » morceau de code unique de quelques 6500 lignes aujourd’hui a pour rôle de recherche et charger la bibliothèque nebule et l’application demandée par l’utilisateur.

Son interface est sommaire, spartiate. L’utilisateur moyen n’a pas beaucoup de raison de s’y aventurer en temps normal. Si le bootstrap apparaît c’est sûrement pour un problème grave…

Son code résulte de la tension forte entre le besoin d’une code de démarrage unique des applications et le besoin récurrent de mise à jour en cas de faille.

Pour cela il intègre une bibliothèque réduite et limité de nebule afin de pouvoir manipuler les objets et liens en provenance uniquement des entités autorités. Ensuite, une fois l’application chargée, c’est le code de la bibliothèque complète qui est utilisée, mais celle-ci est tenu à jour en recherchant toujours la dernière version disponible. Et il en est de même pour les différentes applications.

Le code du bootstrap a été fait en programmation procédurale (dit libpp) afin qu’il n’y ai pas de confusion avec le code de la bibliothèque complète en programmation orientée objet (dit libpoo).

Afin de pouvoir être d’une certaine utilité en cas de problème, le bootstrap intègre trois toutes petites applications :

  • app 0 : sélection de l’application à lancer pour l’utilisateur.
  • app 1 : documentation nebule.
  • app 2 : application par défaut, ne fait rien que d’afficher une page simple.

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

Dissimulation, transcodage et dossier privé

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.

Implémentation de la gestion des liens dissimulés

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.

Création d’objet et dissimulation des liens

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.

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

Anonymisation/dissimulation des liens

Il y a déjà une série d’articles en 2012 sur la Liaison secrète (et suite), puis en 2014 sur l’Anonymisation de lien (et correction du registre de lien), et enfin en 2015 sur la Dissimulation de liens, multi-entités et anonymat et l’Exploitation de liens dissimulés.

On trouve dès 2015 un schéma d’implémentation d’un lien dissimulé (offusqué) et le mécanisme cryptographique utilisé :

20150627-nebule-schema-crypto-lien-c

Mais la mise en pratique ne suit pas alors que la bibliothèque nebule en php orienté objet est prête à reconnaître les liens dissimulés.

Parce qu’en pratique, il ne suffit pas juste de générer ces liens et de les lire, il faut aussi les stocker de manière à pouvoir les retrouver tout en gardant des performances acceptables lors du passage à l’échelle.

Comme l’anonymisation attendue nécessite la mise en place d’un minimum de déception vis-à-vis d’un adversaire, il n’est pas possible de stocker les liens dissimulés dans les liens des objets concernés. Cela casserait presque immédiatement la confidentialité du lien dissimulé parce que les objets ont souvent chacun des rôles propres et donc des places privilégiées dans les liens qui servent aux usages de ces objets.

Les deux seules informations que l’on ne peut dissimuler sans bloquer le transfert et l’exploitation des liens dissimulés, c’est l’entité signataire et l’entité destinataire (si différente). Donc le stockage ne peut se faire que de façon connexe à des deux entités. Si ce n’est pas le cas les liens ne pourront pas être retrouvés et utilisés lorsque nécessaire.

Prenons le cas d’une entité qui décide de dissimuler la grande majorité de son activité, elle va donc dissimuler tous les liens qu’elle génère (ou presque). Là où habituellement le stockage des liens aurait été réparti entre tous les objets concernés, du fait de la dissimulation ils vont tous se retrouver attachés à un même objet, l’entité signataire. Cela veut dire que pour extraire un lien de cette entité il va falloir parcourir tous les liens. Cela peut fortement impacter les performances de l’ensemble.
Et c’est aussi sans compter le problème de distribution des liens parce que l’on les distribue aujourd’hui que vers les objets source, cible et méta… et non sur les entités signataires. L’entité destinataire est dans ce cas naturellement desservie directement, est-ce un problème si l’entité signataire ne l’est pas ?
Une autre méthode pourrait consister à créer un objet de référence rattaché à l’entité et spécifiquement dédié à recevoir les liens dissimulés. Mais les liens dissimulés ne contenant pas cette objet de référence, on doit créer un processus plus complexe pour la distribution des liens tenant compte des entités signataires et destinataires.
On peut aussi mettre tous les liens chiffrés dans les liens d’un objet c puisque c’est le type de lien après dissimulation. Mais cela veut dire que tous les liens dissimulés de toutes les entités se retrouvent au même endroit. On ne fait que déplacer le problème de la longue liste des liens à parcourir.
Enfin on peut rester sur une des premières idées qui consiste à stocker des liens dissimulés non plus dans la partie du stockage dédié au liens mais directement dans un objet. Le défaut de cette méthode est qu’à chaque nouveau lien dissimulé généré, il faut refaire un nouvel objet avec une novelle empreinte… et donc un nouveau lien pour le retrouver.

On rejoint le problème de la persistance des données dans le temps, de leurs objets et liens associés. Une solution déjà proposée, mais non implémentée, consiste à organiser un nettoyage par l’oubli des objets et des liens dans le temps en fonction d’une pondération.

Pour commencer à expérimenter, les liens dissimulés seront stockés uniquement avec l’entité destinataire. Cela ne remet pas en cause la distribution actuelle des liens. On verra à l’expérience comment gérer un flux massif de liens et son impact sur les performances.

php, gd et mbstring

Pour une installation sous Linux, ne pas oublier les paquets php-gd et php-mbstring permettant d’avoir accès aux fonctions de modification graphique et à mbstring qui va notamment convertir les textes en utf-8.

C’est utilisé par la bibliothèque nebule procédurale incluse dans le bootstrap. Donc si pas de mbstring disponible, ça plante dès le début…

Les documentations sont déjà à jour :

Sous FreeBSD et OpenBSD, il faut compiler php avec gd et mdstring, ou l’installer via les portages avec ces dépendances. Bon… ça fait un moment que le code n’a pas été testé sur ces plateformes par manque de temps.

Debian 8 n’est pas concerné. C’est par défaut en dépendance de php.

L’idéal serait de pouvoir s’en passer pour simplifier l’installation… à voir…

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 des sources d’aléa – implémentation

Suite à l’article Modification des sources d’aléa, la fonction getPseudoRandom a été modifiée dans la bibliothèque PHP orienté objet de nebule pour ne plus consommer du tout de ressource d’aléa mais en gardant une entropie forte.

La génération se fait depuis une graine qui est la concaténation de la date, de l’heure en micro-secondes, du nom de la bibliothèque, de la version de la bibliothèque et enfin de l’identifiant de l’instance locale du serveur. La graine dépendant donc surtout de l’heure avec une grande précision et est spécifique à chaque serveur.

La graine sert à générer via une fonction de hash l’état du compteur interne. Comme la taille du hash est fixe, une boucle permet d’alimenter la sortie en dérivant successivement l’état du compteur interne. À chaque tour de la boucle, l’état du compteur interne est dérivé en calculant le hash de lui-même. À chaque tour de la boucle, on concatène à la sortie le hash de l’état du compteur interne concaténé à une valeur fixe. L’état du compteur interne n’est jamais directement sorti et il est effacé en fin de génération de fonction.

Le bootstrap utilise aussi une génération pseudo aléatoire pour la création notamment d’identifiants temporaires. La bibliothèque PHP procédurale intégrée au bootstrap a aussi été modifiée. Elle fonctionne sur le même principe décrit ci-dessus. Une nouvelle fonction __pr est créée et les fonctions ne nécessitant par un aléa fiable ont été modifiées.

La fonction de hash actuellement utilisée pour la dérivation du compteur interne et la fonction sha256. Comme on attend pas de propriété cryptographique forte dans cette fonction, n’importe quelle fonction de hash peut faire l’affaire.

Ce sera disponible dans la prochaine version diffusée de la bibliothèque de nebule.

Modification des sources d’aléa

La bibliothèque nebule en PHP orienté objet présente deux fonctions de génération d’aléa dans la classe dédiée à la cryptographie.

Les fonctions :

  • public function getPseudoRandom($size=32)
  • public function getStrongRandom($size=32)

La première fonction getPseudoRandom permet de générer un aléa correct mais pas fiable, c’est à dire de qualité mais pas pour un usage cryptographique sûr. Il va servir principalement pour générer des identifiants d’objets de références.

La seconde fonction getStrongRandom permet de générer un aléa beaucoup plus fiable, c’est à dire réellement non prédictible, pour un usage cryptographique sûr. Cependant cet aléa est précieux parce que sa génération prendre du temps et peut consommer des ressources, ce qui limite la quantité de bon aléa que l’on peut demander à un instant donné. Il doit donc être réservé strictement à des usages requérant un aléa fiable.

Or, la fonction getPseudoRandom fait appel à la même fonction interne openssl_random_pseudo_bytes que getStrongRandom, ce qui veut dire qu’elle consomme de l’aléa précieux alors que ce n’est pas nécessaire.

Cette fonction getPseudoRandom va être modifiée pour générer un aléa correct mais non fiable à partir de la date/heure et une préparation via une ou plusieurs fonctions de hachage. Elle ne devra en aucun cas être utilisée comme source pour générer des mots de passes de session ou de protection des objets, etc… nécessitant un aléa de qualité cryptographique.

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

Entités de recouvrement – configuration

Suite des articles Entités de recouvrement et implémentation.

L’objet de référence de définition des entités de recouvrement est l’objet contenant :

nebule/objet/entite/recouvrement

De nouvelles options permettent de gérer la prise en compte des entités de recouvrement par la bibliothèque nebule en PHP :

  1. permitRecoveryEntities (boolean, critical) : commutateur global d’activation des entités de recouvrement via les liens des autorités strictement locales. Par défaut à false.
  2. permitRecoveryRemoveEntity (boolean, careful) : commutateur qui permet à une entité de supprimer le partage de la protection d’un objet avec une entité de recouvrement. Par défaut à false.
  3. permitInstanceEntityAsRecovery (boolean, critical) : commutateur de définition de l’entité instance locale comme entité de recouvrement. Outrepasse les liens. Par défaut à false.
  4. permitDefaultEntityAsRecovery (boolean, critical) :commutateur de définition de l’entité par défaut comme entité de recouvrement. Outrepasse les liens. Par défaut à false.

Toutes les options sont en lecture seule, c’est à dire que les liens d’options ne sont pas pris en compte. Au besoin, ces options doivent être modifiées dans le fichier d’environnement.

A false, par défaut, la première option désactive complètement la détection des entités de recouvrement et le mécanisme de partage de protection des objets pour les entités de recouvrement.

La deuxième option, si à true, permet à une entité de supprimer le partage de protection à une entité de recouvrement particulière. Cette action doit être faite après la protection, réalisée systématiquement, et sur tous les objets protégés un par un. Cette option va faire disparaître le bouton de suppression de partage de protection dans les affichages, mais elle est aussi vérifiée lors de la suppression effective du partage de protection d’un objet si l’utilisateur tente la suppression de force.

Le lien de déclaration d’une entité de recouvrement a la forme :

  • action : f
  • source : entité instance locale, par exemple = 3af39596818c1229d7a3d08b9f768622903951305df728609a68a2957f7f3882
  • cible : entité de recouvrement, par exemple = 19762515dd804577f9fd8c005a7803ddee413f264319748e30aa2aedf318ca57
  • méta : objet de référence de recouvrement

La désactivation est un lien de type x.

Les liens doivent être signés de l’entité instance locale ou de l’entité par défaut en fonction des options de permission.

Entit̩s de recouvrement Рimpl̩mentation

Dans le précédent article sur les Entités de recouvrement qui date de plus de 6 mois, il était question de l’implémentation du mécanisme dans le code. Jusque là la liste des entités de recouvrement était renvoyée vide.
Ce mécanisme peut être une contrainte légale dans certains pays mais ce peut être aussi un moyen d’assurer plus sereinement la disponibilité des données sans remettre en question significativement la confidentialité de celles-ci. Sa portée est strictement local et ne doit pas devenir un comportement global sous peine de rompre la confiance dans l’ensemble du code de nebule.

La prochaine version de la bibliothèque nebule en PHP intègre le code nécessaire à la détection des entités marquées localement comme entités de recouvrement et le code qui se charge de dupliquer la protection des objets pour ces entités.

La définition des entités de recouvrement est purement locale et est attachée à l’entité instance locale. La détection d’entité de recouvrement se fait sur un lien de type f entre chaque entité définie comme entité de recouvrement et l’entité instance locale. Le champ méta du lien est l’objet de référence contenant nebule/objet/entite/recouvrement. Seuls les liens des autorités strictement locales sont pris en compte, c’est à dire à l’exception du puppetmaster, du maître de la sécurité et du maître du code.

La duplication de la protection se fait au niveau de la fonction (unique) de protection d’un objet setProtected(). Afin d’éviter la suppression du partage de protection avec une entité de recouvrement, la fonction cancelShareProtectionTo() ne supprime pas ce partage si l’entité est dans la liste des entités de recouvrement.
Afin de ne pas perturber l’utilisateur, les applications affichent tous les partages de protection mais n’affichent pas le bouton correspondant pour ces entités de recouvrement.

Les applications option, sylabe et klicty permettaient déjà l’affichage des entités de recouvrement même si elle était vide. Ces affichages ont été améliorés afin d’afficher en plus l’entité autorité locale qui a activé l’entité comme entité de recouvrement. Le but est d’avoir un mécanisme qui peut être contraignant et indiscret mais dont le fonctionnement doit être ouvert et loyal pour maintenir la confiance de l’utilisateur.
L’application option est maintenant le centre de gestion des entités de recouvrement. Il est possible, lorsque l’on déverrouille l’entité instance de serveur, d’ajouter ou de retirer des entités à la liste. Les autres entités ne peuvent faire que de l’affichage. Si un lien est généré par une autre entité, il est ignoré.

Renforcement de la lecture des objets – taille limite

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

Le renforcement de la lecture des objets et notamment la suppression sur empreinte invalide ou invérifiable entraîne un autre effet. Tout objet plus grand que la taille limite de lecture des contenus des objets, définit par l’option ioReadMaxData, est automatiquement supprimé lorsqu’on essaie de l’utiliser. Ce qui veut dire qu’il y a une valeur minimum à l’option ioReadMaxData pour ne pas empêcher le bon fonctionnement des applications.

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 ligne d’un paquet complet

Le serveur de l’entité maître du code bachue vient d’être mis à jour avec le nouveau bootstrap en php et tous les liens signés de celle-ci. On retrouve donc dedans les différentes applications.

Afin de faciliter l’installation, une archive prête à déployer de l’ensemble est disponible ici :

871d0e2a2dd623da97e0cc5ca313a56e1a55a410d2b5f9b69042379f4222f189

Cette archive contient déjà tous les objets et liens nécessaires au bon fonctionnement de l’ensemble. Cela évite la synchronisation (incomplète) du bootstrap lors de la première connexion.

Le bootstrap ayant fortement changé dans son fonctionnement interne, il n’est pas possible de simplement synchroniser les applications sur un serveur déjà en place.
Il faut pré-charger les objets de l’archive, pré-envoyer les liens de l’entité maître du code, et mettre en place le nouveau bootstrap

Les guides d’installation ont été mis à jours :