Catégorie : librairie

Permettre les modifications par défaut

La modification du bootstrap est en cours pour la préparation par défaut d’un nouvel environnement sur un serveur vierge.

Cependant, les options permitWrite, permitWriteObject et permitWriteLinks étaient par défaut à false. Et comme sur un nouveau serveur il n’y a pas de fichier contenant les options, c’était false la réponse par défaut pour ces options. Cela induit que la librairie refuse par défaut d’écrire les objets et liens associés pour la création du nouvel environnement et donc l’impossibilité de préparer ce nouveau serveur…

Ces options sont maintenant à true par défaut.

Liens marqués entre le puppetmaster et les autres entités

Il y a quelques jours, le puppetmaster a été réveillé pour générer de nouveaux liens. De nouveaux objets de nebule sont maintenant reconnus comme des objets à usage réservé :

  • nebule/objet/entite/maitre/securite
  • nebule/objet/entite/maitre/code
  • nebule/objet/entite/maitre/annuaire
  • nebule/objet/entite/maitre/temps

Et il permettent de désigner via un lien de type f les différentes entités qui ont les rôles correspondants.

Le code de la librairie nebule en php et le bootstrap s’en servent désormais pour retrouver les entités avec ces rôles.

CF : sylabe – Avancement

Dissimulation de liens, multi-entités et anonymat

La dissimulation de lien tel que prévu dans nebule n’est que la première partie permettant l’anonymisation des échanges entre entités.

Voir les articles précédents :
РLiaison secr̬te et suite ;
– Nouvelle version v1.2, Anonymisation de lien et correction du registre ;
РLien de type c, pr̩cisions ;
РEntit̩s multiples, gestion, relations et anonymat et Entit̩ multiples ;
– Nébuleuse sociétale et confiance – Chiffrement par défaut

Cette dissimulation d’un lien se fait avec un lien de type c. On a bien sûr dans le registre du lien visible l’entité qui génère ce lien, l’entité signataire. Et on a l’entité destinataire qui peut déchiffrer ce lien dissimulé et en extraire le vrai lien. Et comme dans la version publique de ce lien on a à la fois l’entité source et l’entité destinataire qui sont visibles, il n’y a pas d’anonymat. Ce type de lien permet juste de dissimuler l’usage d’un objet.

2015.06.27 lien c

Un lien dissimulé ne peut pas contenir un autre lien dissimulé. On interdit donc les multi-niveaux de liens dissimulés qui seraient un véritable calvaire à traiter.

Un lien peut être dissimulé pour soi-même. C’est à dire que l’entité signataire est aussi l’entité destinataire.

Si un lien doit être dissimulé pour plusieurs destinataires, il faut générer un lien pour chaque destinataire. La seule façon de réduire le nombre de liens pour un grand nombre de destinataires est d’utiliser la notion de groupe disposant de son propre bi-clé. Ce type de groupe est pour l’instant purement théorique.

Ce maintien comme public des entités sources et destinataires est une nécessité au niveau du lien, c’est une des bases de la confiance dans les liens. Pour que le lien puisse être validé et accepté par une entité ou retransmit par un relais, l’identification des entités est incontournable. Et donc avec l’identification nous avons aussi l’imputabilité et la non répudiation.

Si on veut assurer de l’anonymat pour les entités, puisque l’on ne peut pas travailler au niveau du lien, il faut travailler au niveau de l’entitié. On va dans ce cas travailler sur la notion de déception, c’est à dire faire apparaître des entités pour ce qu’elles ne sont pas ou tromper sur la nature des entités.
L’idée retenu consiste, pour chaque entité qui souhaite anonymiser ses échanges avec une autre entité, à générer une entité esclave avec laquelle elle n’a aucun lien. Ou plutôt, le lien d’entité maîtresse à entité esclave est un lien dissimulé pour l’entité maîtresse uniquement. Ici, personne à par l’entité maîtresse ne peut affirmer juste sur les liens que l’entité esclave lui est reliée.
Lorsque l’on veut échanger de façon anonyme, on transmet à l’entité destinataire l’identifiant de l’entité esclave, et vice versa. Cette transmission doit bien sûr être faîte par un autre moyen de communication ou au pire par un seul lien dissimulé.

L’anonymisation complète est donc la combinaison des liens de dissimulation de liens et d’une capacité multi-entités des programmes.

La dissimulation est en cours d’implémentation dans sylabe en programmation php orienté objet. Mais le plus gros du travail sera à faire dans la librairie nebule puisque c’est elle qui manipulera les liens et présentera ceux-ci à l’application, c’est à dire sylabe, dans une forme exploitable. L’application n’a pas à se soucier de savoir si le lien est dissimulé, elle peut le lire ou elle ne peut pas. Tout au plus peut-elle afficher qu’un lien est dissimulé pour information de l’utilisateur.
La capacité multi-entités de sylabe est maintenant beaucoup plus facile à gérer en programmation php orienté objet. Mais il reste à implémenter la génération des entités esclaves avec dissimulation de leur entité maîtresse.

Une autre dimension n’est pas prise en compte ici, c’est le trafic entre les serveurs pour les échanges d’informations. Il faudra faire attention à la remontée possible aux entités maîtresses par leurs échanges.

Enfin, pour terminer, aujourd’hui c’est la course au chiffrement par défaut de tous les échanges pour tout un tas de programmes et services sur Internet. Ce chiffrement par défaut est bon pour l’utilisateur en général. Et il masque dans la masse les échanges pour qui la confidentialité est critique. Ainsi il ne suffit plus d’écouter le trafic chiffré pour retrouver ses ennemis.
Mais cette logique est perverse. Le chiffrement par défaut est une aberration, un remède de cheval posé en urgence faut de mieux. Nous avons besoin d’échanger aussi des choses publiquement, comme sur un forum ou dans la presse. Nous ne devrions pas avoir des outils de communication tout chiffré et d’autres tout public, chaque outil devrait permettre les deux et clairement indiqué ce qui est protégé de ce qui ne l’est pas…

Authentification et mot de passe

Dans la version précédente, procédurale, de la librairie nebule en php, l’authentification était gérée via des variables de la session. On retrouvait l’ID de l’entité en cours ainsi que l’ID de la clé privée associée et le mot de passe (si déverrouillé) de cette clé privée.

Les anciennes variables :
– $_SESSION['nebule_publ_entite']
– $_SESSION['nebule_priv_entite']
– $_SESSION['nebule_pass_entite']

Dans la nouvelle version de la librairie, en programmation orientée objet, la première variable qui référence l’entité en cours d’utilisation est toujours nécessaire.
Par contre, la variable qui référence la clé privée est encore utilisé mais n’est déjà plus vraiment indispensable puisque l’instance (l’objet au sens programmation) de l’entité contient la référence à l’ID de sa clé privée. Cet ID de clé privée est pré-calculée lors de l’initialisation de l’instance et est accessible par une fonction publique. Il est même possible que cette variable de session pour la clé privée disparaisse à terme faute d’usage.
Enfin, la variable contenant le mot de passe de la clé privée, elle, disparaît définitivement. Elle n’était renseignées que lorsque l’entité était déverrouillées. Désormès, le mot de passe, lorsque fourni, est stocké dans l’instance de l’entité en cours. Cette instance référence ainsi la clé privée et le mot de passe associé. Ce mot de passe est bien sûr vérifié lors de son enregistrement puisque c’est la seule et unique condition pour considérer l’entité comme déverrouillée, que le mot de passe soit valide sur la clé privée.

En terme de sécurité du code, c’est plus propre. Le mot de passe ne peut être consulté directement par un module malveillant comme avec une variable de session par essence globale et donc accessible partout. Cependant, le mécanisme n’est pas parfait puisqu’une lecture brute de l’instance permet d’en extraire le contenu… et donc le mot de passe. Il faudra trouver un mécanisme pour renforcer ça…
L’usage d’un sel pour le mot de passe est en cours de réflexion sachant qu’il faudra dans ce cas créer un lien pour le rendre publique. C’est un renforcement de la sécurité du mot de passe mais potentiellement une source de panne.

En terme de gestion des entités, c’est plus facile si on change vers une entité que l’on maîtrise puisque les mots de passe des entités esclaves sont accessibles et peuvent être pré-injectés dans les entités correspondantes. Et puis en cas de bascule vers une de ces entités esclaves, le retour à l’entité maîtresse est plus facile aussi puisque le mot de passe pourra rester dans celle-ci.

En terme d’évolution, il est déjà prévisible qu’une forme avancée d’un usage multi-entité verra le jour. CF Entités multiples. La pré-initialisation des mots de passes de toutes les entités sous contrôle (entités esclaves) rendra cet usage beaucoup plus facile. Pour rappel, cet usage multi-entité permettra au choix soit d’utiliser une et une seule entité à un instant donné mais de pouvoir immédiatement et facilement changer d’entité, soit d’utiliser simultanément tout ou partie des entités sous contrôle. Dans ce dernier cas, les actions seront par contre faites avec une seule entité pré-definie pour cela.

Voici la structure de la classe Entity :

class Entity extends Object
{
	const ENTITY_MAX_SIZE = 16000;
	const ENTITY_PASSWORD_SALT_SIZE = 128;
	const ENTITY_TYPE = 'application/x-pem-file';

	private $_publicKey = '';
	private $_privateKeyID;
	private $_privateKey = '';
	private $_privateKeyPassword;
	private $_privateKeyPasswordSalt;
	private $_issetPrivateKeyPassword = false;
	private $_faceCache = array();

	public function __construct(nebule $nebuleInstance, $id);
	public function __destruct();
	public function __toString();
	private function _loadEntity($id);
	private function _createNewEntity();
	private function _verifyEntity($entity);
	public function getType();
	public function getKeyType();
	public function getPublicKeyID();
	public function getPublicKey();
	private function _findPublicKey();
	public function getPrivateKeyID();
	private function _findPrivateKeyID();
	private function _findPrivateKey();
	public function setPrivateKeyPassword($passwd);
	public function unsetPrivateKeyPassword();
	public function checkPrivateKeyPassword();
	public function changePrivateKeyPassword($newpasswd);
	public function getFullName();
	public function getLocalisations();
	public function getLocalisation();
	public function getFaceID($size=400);
}

Entités multiples

Dans la suite des réflexions sur Entités multiples, gestion, relations et anonymat, le développement de la librairie nebule en php continue en tenant compte de cette possibilité.

En gérant le mot de passe d’une entité dans l’objet (php) de cette entité, on peut avoir plusieurs entités déverrouillées à un instant donné. Et comme plusieurs entités sont potentiellement déverrouillées, lorsque l’on consulte un objet chiffré, il ne faut plus seulement regarder si l’entité courante est déverrouillée et donc peut le lire, mais il faut regarder dans tous les destinataires si une des entité n’est pas déverrouillée aussi. Une seule suffit pour déchiffrer l’objet et afficher son contenu.

Il faut cependant faire attention à ce que l’entité courante ait bien l’accès à l’objet chiffré avant de permettre son utilisation parce que cela dévoilerait immédiatement le lien de parenté entre les deux entités. Il est imaginable de basculer immédiatement d’entité courante sur une action de ce genre.

Si on souhaite une bascule complète sur une entité esclave sans interférence d’autres entités, il suffit de vider le mot de passe de tous les objets (php) des entités que l’on ne souhaite plus voir. Cela inclut aussi l’ancienne entité courante qui peut avoir été préalablement sauvegardée avec sont mot de passe pour une restauration ultérieure.

Une des applications de cette capacité multi-entité, c’est le cumule d’entité lors d’un Changement d’identifiant d’entité. Il est possible, le temps de migrer les liens, de pouvoir continuer à consulter les objets de l’ancienne entité tout en utilisant la nouvelle entité.

Avancement

La librairie nebule en bash évolue. Ça faisait longtemps…

Comme un nouveau fichier nebule.env est utilisé par la librairie nebule en php, en place de l’ancien env_nebule.php, il était naturel que ce fichier serve aussi à la librairie en bash. Ce fichier évolue pour intégrer des options spécifiques au bash. Certaines options sont spécifiques au php et d’autres, comme la crypto, sont communes.

Le gros changement ‘est surtout que les options ne sont plus des variables. Il est possible d’extraire directement une option de configuration au moment de l’utiliser, mais il est aussi possible d’en faire une variable, comme avant. C’est cette dernière solution qui est utilisée pour l’instant, par facilité.

Cette nouvelle version de la librairie nebule en bash sera prochainement diffusée par bachue…

Avancement

La remise en place des fonctions de la librairie nebule en php orienté objet ainsi que la ré-écriture du bootstrap pour en profiter reprend pleinement.

La résolution du graphe des mises à jours des objets, c’est à dire le suivi des liens de mises à jours, est fonctionnelle. On peut donc maintenant rechercher la dernière version de la librairie ainsi que la dernière version du programme à charger par défaut.
La librairie ayant le minimum fonctionnel pour le bootstrap, elle y a été intégralement copiée. Plus tard, elle sera allégée des fonctions non utilisées. La librairie étant plus modulable, les modules non nécessaires au bootstrap ne seront simplement pas intégrés.

La cible : faire charger la librairie par le bootstrap et le programme par défaut.

Le programme sylabe est fonctionnel sur la librairie actuelle moyennant la conservation des fonctions procédurales. Ces anciennes fonctions seront progressivement transformées pour utiliser les nouvelles fonctions en programmation orienté objet… et/ou supprimées dès que sylabe aura été mis lui aussi à jour. En attendant, il intègre en bas de page les nouveaux compteurs du nouveau bootstrap.

nebule_bootstrap_-_Experimental_-_2014-11-16_10.21.26

Avancement

Afin de tester les nouvelles fonctions avec sylabe, et pour pouvoir aussi reprendre le développement de ce dernier, les anciennes fonctions de la librairie en php procédural sont réinjectées dans la librairie en php orienté objet. Ainsi sylabe fonctionne et les anciennes fonctions procédurales vont pouvoir être progressivement reprogrammées pour faire appel aux nouvelles fonctions orienté objet…

Le code n’est pas encore diffusé puisqu’il est assez ‘sale’. Mais ça viendra…

Avancement

La ré-implémentation de la librairie en php orienté objet avance.

Un gros point de blocage vient de sauter. Il s’agissait d’implémenter la résolution d’un graphe de liens de mises à jours. L’implémentation précédente fonctionnait bien mais nécessitait une sous fonction qui s’appelait elle-même au fur et à mesure du parcours des liens u. Ici, il fallait forcément implémenter une fonction de recherche des mises à jours sur un niveau pour un objet. Mais en contre-partie, et moyennant un fonctionnement plus complexe, il a été possible de ne plus utiliser la sous-fonction auto-appelée…
Bref, c’est plus complexe à comprendre mais c’est aussi plus propre :-)

Voici le genre de chemin suivi pour la résolution du graphe de mise à jour d’un objet. Ici le cheminement est linéaire entre les objets intermédiaires, il devra être éprouvé sur un cheminement non linéaire (avec des objets manquants).
On part de l’objet 47c1b111409c3a9ccb193b19c481b38715f9fc96da706d98c070ef9019890cb9 et on arrive à 672bad4d2c4bd4a5def227671a0eb22844dbb116d59d4cb948ecbaa4f6b0b549 (sur une base de liens plus réduite):

2013-12-06_u_47c1b111409c3a9ccb193b19c481b38715f9fc96da706d98c070ef9019890cb9_5376cfdb8b8d3e1c9c4832bb9d8cab0ba076bbf2d28ae53c8680088641d2aa85
2013-12-07_u_5376cfdb8b8d3e1c9c4832bb9d8cab0ba076bbf2d28ae53c8680088641d2aa85_e2e0fec866c726f3b284575435a81080f279e4afb46a7ba07edc39105f061a7f
2013-12-10_u_e2e0fec866c726f3b284575435a81080f279e4afb46a7ba07edc39105f061a7f_9864740a3679164edfc130ba64658926470227e6a94056ce200a1157f729a940
2013-12-11_u_9864740a3679164edfc130ba64658926470227e6a94056ce200a1157f729a940_aafc618df11870db1c833a6f0e31e8c4246645001b515040ee7d84cde135e617
2013-12-12_u_aafc618df11870db1c833a6f0e31e8c4246645001b515040ee7d84cde135e617_1e45b26a70a8f19e3515d981100fc7a135b6b6e480bb170d41d2033120a02fec
2013-12-13_u_1e45b26a70a8f19e3515d981100fc7a135b6b6e480bb170d41d2033120a02fec_0a2d68d69eca2bd3b83ea0306bc868c4ee684e8eb1665e9215263ea05a54c426
2013-12-24_u_0a2d68d69eca2bd3b83ea0306bc868c4ee684e8eb1665e9215263ea05a54c426_284ea4d9be9b206d73297bda696c77ef3389c47330e5b1d4c13dcf3ab3c5d20d
2013-12-26_u_284ea4d9be9b206d73297bda696c77ef3389c47330e5b1d4c13dcf3ab3c5d20d_182b6e830ba6b21411695e9f99fddfddd12c0bee61fce41368c98e0c1254dab5
2014-01-02_u_182b6e830ba6b21411695e9f99fddfddd12c0bee61fce41368c98e0c1254dab5_e304bf8534de8b6fba8a88bcbbcd520439527a8719579c1db2d3465465e463a9
2014-01-10_u_e304bf8534de8b6fba8a88bcbbcd520439527a8719579c1db2d3465465e463a9_ab46a8ed5c21a2d8ff9103088a8cdc07ea167eb577b3cc4ac0ec29b4388c4b0c
2014-01-13_u_ab46a8ed5c21a2d8ff9103088a8cdc07ea167eb577b3cc4ac0ec29b4388c4b0c_79ddbdd834c136e4616b71372de11d786b4730ea040bd732b1d91e17b10398b0
2014-01-16_u_79ddbdd834c136e4616b71372de11d786b4730ea040bd732b1d91e17b10398b0_d6d226f89a247ef361ae1c0b0eb1c5383ea2ee7c1ee607255f84727b7da2c962
2014-01-17_u_d6d226f89a247ef361ae1c0b0eb1c5383ea2ee7c1ee607255f84727b7da2c962_59b802549352603e2cc9d386788bbfe0336045cc841b96bdb707f87f4d9d0bbd
2014-01-18_u_59b802549352603e2cc9d386788bbfe0336045cc841b96bdb707f87f4d9d0bbd_0131a0b7b758d24be4ecc6701fc942c8c73044f3fa85aa2e82fe42b5cfcf05d9
2014-01-22_u_0131a0b7b758d24be4ecc6701fc942c8c73044f3fa85aa2e82fe42b5cfcf05d9_dd27f522db318f7fcf54852af861e656b184bd178c9718c7186efcedda49dba2
2014-01-23_u_dd27f522db318f7fcf54852af861e656b184bd178c9718c7186efcedda49dba2_72ebbabbf4687106a70b5bba7f9c10ab096febd649f306660411f2cc6215981e
2014-01-24_u_72ebbabbf4687106a70b5bba7f9c10ab096febd649f306660411f2cc6215981e_b364e1bf7181fa508032d5d26562350be6aadbb14949137e8d442bdc1912493b
2014-01-29_u_b364e1bf7181fa508032d5d26562350be6aadbb14949137e8d442bdc1912493b_cc1ec77ea4d137b7785c2de9dab0d818420f520f3502788aec56e1ca3cb081ac
2014-01-30_u_cc1ec77ea4d137b7785c2de9dab0d818420f520f3502788aec56e1ca3cb081ac_c971f678bbfeba808c0f0b4f23f6d3f3bed21c098437ecfe54e0c46891696462
2014-01-31_u_c971f678bbfeba808c0f0b4f23f6d3f3bed21c098437ecfe54e0c46891696462_27ec39235f7f49f1a862ac303e54125cc2941455b832000957583130e08896eb
2014-02-02_u_27ec39235f7f49f1a862ac303e54125cc2941455b832000957583130e08896eb_c92173177ed98cfbb651a76670b3e508834bbb217ac91b285c8ab20994f5b249
2014-02-03_u_c92173177ed98cfbb651a76670b3e508834bbb217ac91b285c8ab20994f5b249_02ef13f3824b6412cbd38b9c33266a601b18a8812b84aff3fffb7647723b1883
2014-02-05_u_02ef13f3824b6412cbd38b9c33266a601b18a8812b84aff3fffb7647723b1883_60de6086e63a85db4a39ca06f1bccb966eaa3cb6d805889210a6cc63c5c59757
2014-02-06_u_60de6086e63a85db4a39ca06f1bccb966eaa3cb6d805889210a6cc63c5c59757_8334ed17bfe94db33690049ecae724b58e420478d62a902503bb95ab17e013ba
2014-02-07_u_8334ed17bfe94db33690049ecae724b58e420478d62a902503bb95ab17e013ba_a6e76573b865ca90fb92b247c724474456db38023b6b9716b45ef41c6742e164
2014-02-08_u_a6e76573b865ca90fb92b247c724474456db38023b6b9716b45ef41c6742e164_b8fb4e2a4fa515cc8ce6d130ab7cfcfa7138150d3117357514bfb5d868a726c4
2014-02-09_u_b8fb4e2a4fa515cc8ce6d130ab7cfcfa7138150d3117357514bfb5d868a726c4_b338bd787b97e6cd85ce9965b00d17a86d51255b87c8686d0444b6a87ea7f034
2014-02-10_u_b338bd787b97e6cd85ce9965b00d17a86d51255b87c8686d0444b6a87ea7f034_d4115805c826483a0a5f6988be4fcc4bac8b04d300cbb3c8f0244194777931f9
2014-02-12_u_d4115805c826483a0a5f6988be4fcc4bac8b04d300cbb3c8f0244194777931f9_221ec95e1046265b03dc8800a7efed44df5e49b6db3b9f51048370009022698d
2014-02-13_u_221ec95e1046265b03dc8800a7efed44df5e49b6db3b9f51048370009022698d_b80e64fc316768932fab063b35d47e3651eed66be7ca8756d2cb0bc82afbd683
2014-02-16_u_b80e64fc316768932fab063b35d47e3651eed66be7ca8756d2cb0bc82afbd683_76e3f1f5d64a221bf1a28964ae74f9752af3b26763b46523ea3b5e6a2a20511a
2014-02-17_u_76e3f1f5d64a221bf1a28964ae74f9752af3b26763b46523ea3b5e6a2a20511a_d1fd4dba3ec0ec7fda4898a16eac6593d10e80cb575511fd9cbe85ec214e487f
2014-02-18_u_d1fd4dba3ec0ec7fda4898a16eac6593d10e80cb575511fd9cbe85ec214e487f_fbf7bcc5c27981b8953e2a8630f572774f6c16684ac8459bb240aeaca8bd8ff7
2014-02-20_u_fbf7bcc5c27981b8953e2a8630f572774f6c16684ac8459bb240aeaca8bd8ff7_8badc8ba4a855acbbe58de48e5ac3fa4aeb3c3c69858401778adf771ed19be15
2014-02-21_u_8badc8ba4a855acbbe58de48e5ac3fa4aeb3c3c69858401778adf771ed19be15_f05b4ac2d53b7287af3f15c3ab2e7da13fc3a80b37272cbbcfb400d287568f63
2014-02-22_u_f05b4ac2d53b7287af3f15c3ab2e7da13fc3a80b37272cbbcfb400d287568f63_761625eb463d1e3930b80cf88d43157d778d10a23f3d0cba463c552322492b72
2014-02-24_u_761625eb463d1e3930b80cf88d43157d778d10a23f3d0cba463c552322492b72_941752dc44b4a272bd7828724f7f3bd554fa1f3acca4dcb298f0ecf5428ecfbf
2014-02-25_u_941752dc44b4a272bd7828724f7f3bd554fa1f3acca4dcb298f0ecf5428ecfbf_a3d7fcf4f1c88ce5350f065e16ce770cc6d6de6334e7fb6dd8403398c86ea1e5
2014-02-26_u_a3d7fcf4f1c88ce5350f065e16ce770cc6d6de6334e7fb6dd8403398c86ea1e5_1f3e1cec5ab724a701d7665f13003dc50765c3a066227d322d64804651de0ade
2014-02-27_u_1f3e1cec5ab724a701d7665f13003dc50765c3a066227d322d64804651de0ade_5154aa3a5ea8956db2279dbaa2d3944b5a87218202e838c2a4cfc27da172ed6e
2014-03-04_u_5154aa3a5ea8956db2279dbaa2d3944b5a87218202e838c2a4cfc27da172ed6e_0a65036105b001b926d1d0336aa4de5fde1d8a476f325f9832e524d914e7e465
2014-03-26_u_0a65036105b001b926d1d0336aa4de5fde1d8a476f325f9832e524d914e7e465_5ac97a3a3c7c310b5afe24c210874c1b2ae69a80274755117cb7b8bb3b9299be
2014-03-28_u_5ac97a3a3c7c310b5afe24c210874c1b2ae69a80274755117cb7b8bb3b9299be_17bf49d31d9a2ab2d0d051ed1bb4c6a0acdfcad6da199fc86ebf47d8be284f40
2014-03-29_u_17bf49d31d9a2ab2d0d051ed1bb4c6a0acdfcad6da199fc86ebf47d8be284f40_9559ba4972cd3a4ada0d055101efdca7d6c0f942279c6bd05f23b2d0b118c111
2014-04-01_u_9559ba4972cd3a4ada0d055101efdca7d6c0f942279c6bd05f23b2d0b118c111_a6968f3bb36ea04264f6e2314c661af3f4acda829a4515b73b701aea244b1582
2014-04-02_u_a6968f3bb36ea04264f6e2314c661af3f4acda829a4515b73b701aea244b1582_f74debe6a24400c6dbbb4388eefac050d204b5073f643a3302c24fc15e7544c6
2014-04-03_u_f74debe6a24400c6dbbb4388eefac050d204b5073f643a3302c24fc15e7544c6_f6d07dd9f4e946bab71f1084d027f6b9cc16d7161e62cc4562e0bd94cce502d7
2014-04-04_u_f6d07dd9f4e946bab71f1084d027f6b9cc16d7161e62cc4562e0bd94cce502d7_c8dbec0f85e19c313317f552e7acfaa2a23097150e592da400643d4c18884b94
2014-04-08_u_c8dbec0f85e19c313317f552e7acfaa2a23097150e592da400643d4c18884b94_28ae03264ae8505767aa5e3a3cbaf7d0a8a96c92236de5a10c14d694c498438a
2014-04-09_u_28ae03264ae8505767aa5e3a3cbaf7d0a8a96c92236de5a10c14d694c498438a_33ae1c2aa592fb7ac7f95f03abfd5a6b46d4da48579a3153258890298336a01a
2014-04-10_u_33ae1c2aa592fb7ac7f95f03abfd5a6b46d4da48579a3153258890298336a01a_648f35156e67da0bdd9477020129c42e9ed07ac4f67e784f0f0cd931b1b4419c
2014-04-11_u_648f35156e67da0bdd9477020129c42e9ed07ac4f67e784f0f0cd931b1b4419c_907e5d86dec334e80a5e81d4e0b842bbeb0b491c7bba38699da25aa880ac49b8
2014-04-12_u_907e5d86dec334e80a5e81d4e0b842bbeb0b491c7bba38699da25aa880ac49b8_672bad4d2c4bd4a5def227671a0eb22844dbb116d59d4cb948ecbaa4f6b0b549

Gestion des modules – IO et gros objets

Suite de l’article Gestion des modules.

L’exportation du traitement des IO dans des modules entraîne un autre problème avec les gros objets.

Les gros objets peuvent être visualisés dans le navigateur quoi qu’il arrive puisque la lecture du contenu d’un objet est faite par le navigateur et ce contenu est transmis sans traitement par le serveur web. Ce quelque soit la taille de l’objet.
Par contre, si un objet nécessite un traitement, comme le déchiffrement, alors cela ne marche plus de la même façon.

Le traitement d’un objet nécessite qu’il soit placé en mémoire de l’instance PHP en cours, avec toutes les restrictions et limites que l’on va rencontrer. Il n’est pas possible de travailler facilement comme on le ferait sur bash avec une série de ‘pipes’.

Ce problème va aussi se poser lors de la synchronisation d’un objet sur une serveur web externe, via le module IO HTTP. Avant de pouvoir l’écrire localement, via le module IO FileSystem par exemple, il devra tenir en mémoire.
Il est peut-être possible, dans le das d’échanges entre IO, de mettre en place des copies progressives d’objets pour soulager la mémoire. A voir…

Pour le déchiffrement et l’affichage, il est possible de créer une fonction spécifique. Pour le chiffrement, il va falloir travailler par blocs.

IO HTTP et performances dans PHP

Pour les besoins du module des IO sur HTTP, j’ai réalisé quelques tests afin de déterminer la meilleur méthode pour vérifier la présence d’un dossier ou d’un fichier sur un serveur web via HTTP.

La méthode la plus simple consiste à appeler l’URL de ce que l’on veut avec l’instruction file_get_contents.
C’est très simple mais très lent puisque tout le contenu est téléchargé alors que l’on ne souhaite que l’entête de la réponse du serveur. En fait, on a juste besoin de la première ligne de la réponse pour connaître le code de réponse du serveur, 200 si un fichier est disponible. 404 si le fichier n’existe pas. 403 si le fichier n’est pas accessible pour cause de restriction.
A noter que cette instruction et d’autres comme fopen nécessitent d’autoriser explicitement l’ouverture des URL avec allow_url_fopen=On et allow_url_include=On. Ces options sont nécessaires au bon fonctionnement du bootstrap, cela n’introduit donc pas de configuration supplémentaire.

La seconde méthode consiste à demander l’entête (header) via l’instruction PHP correspondante, get_headers.
Sauf que ce n’est pas mieux puisque le contenu est malgré tout téléchargé même si au final on n’extrait que l’entête.

Une autre méthode consiste à utiliser la librairie CURL dans PHP. Cette librairie est spécialisée dans les manipulations des URL, mais cela oblige à l’installer, ce qui n’est pas forcément la meilleur solution.
Par contre, en terme de performance, c’est d’un autre niveau. On peut raisonnablement savoir si un gros fichier est présent sur le serveur sans avoir de temps de latence démesuré. Au moins pour ces performances, cela peut valoir le coût d’installer cette librairie.

Enfin, une dernière solution consiste à générer soit-même la requête à transmettre au serveur et d’analyse la réponse. Cela peut être fait avec l’instruction fsockopen. Mais il faut tout faire, générer la requête, la transmettre, recevoir la réponse et la traiter.
La requête doit être du type HEAD pour n’avoir que l’entête.
Après avoir fait divers tests, cette dernière solution semble la plus rapide.

Voir les temps de réponses pour savoir si le dossier l est présent sur le serveur web local (CF code en annexe) :

 file_get_contents
 HTTP/1.1 200 OK
 2.0584919452667s

 get_headers
 HTTP/1.1 200 OK
 1.8262121677399s

 curl
 200
 0.006443977355957s

 fsockopen
 200
 0.0010509490966797s

Le dossier en question contient 24000 fichiers.
Il est clair de fsockopen est la solution la plus performante. C’est celle qui sera utilisée.

Je ne traite pas le cas des renvois type 301 puisqu’il n’est pas prévu pour l’instant dans la librairie nebule de suivre ces renvois.

Continuer la lecture de IO HTTP et performances dans PHP

Gestion des modules

La gestion des modules existait au niveau de sylabe. Elle est ajoutée directement dans nebule en PHP. Ce qui permet de l’utiliser à la fois dans nebule et sylabe. Chaque programme peut utiliser ses propres modules.

La programmation orientée objet dans PHP permet de gérer plus facilement des modules puisque ce sont simplement des classes, une par module, qui respectent des interfaces précises et non des fonctions multiples par modules. Le mécanisme de gestion derrière consiste à recenser les classes qui respectent certains critères et les lister dans un tableau, pré-instanciées.

La pré-instanciation permet d’initialiser certains environnements comme un accès à une base de donnée par exemple.

Il y a deux niveau de gestion en fait.
Le premier se fait au niveau de nebule. L’instanciation de la classe nebule va rechercher tous les objets qui sont définis comme des modules, c’est à dire avec le bon type et qui sont liés uniquement par l’entité bachue. La recherche des modules se fait en mode strict, les autres entités sont ignorées sauf les entités marquées comme autorités locales.
Le deuxième niveau, toujours lors de l’instanciation de la classe nebule, va appeler une classe spécifique par catégorie de modules. Cette classe est dite classe de routage. Pour chaque catégorie de modules, la classe de routage va s’occuper de rechercher toutes les classes correspondants à des modules ayant la même interface.

La classe de routage respecte la même interface que les classes des modules concernés. Elle seule est définit et reconnu dans l’instance nebule. Et c’est elle qui, étant appelée, va transmettre les requêtes vers la classe, le module, la plus appropriée au traitement. Elle fait donc les rôles de découverte des modules et de routage vers ces modules. Comme la classe de routage partage la même interface, elle a le même comportement que celles-ci, ce qui facilite le développement.

Il existe actuellement deux classes de routages reconnues : io et social.
La classe communication a été fusionnée dans io n’existe plus.

Il y a cependant un problème. En intégrant les IO dans des modules à charger, on se coupe l’herbe sous les pieds puisque pour charger les modules il faut avoir des IO fonctionnels… alors que ces IO sont dans les modules que l’on veut charger…
Là, le bootstrap va nous aider puis qu’il contiendra la classe d’un module IO par défaut, les IO sur système de fichier (FileSystem). Lors du chargement de la librairie nebule en php, une nouvelle détection se fera mais sur les modules présents localement, c’est à dire sur le système de fichier.

Ce fonctionnement par défaut avec le bootstrap entraîne un autre problème. Puisque l’on va utiliser le module IO FileSystem par défaut, on ne prendra en compte que ce qui y est présent. Si la libraire charge par défaut un autre module IO, par exemple MYSQL, alors les mises à jours des objets, et donc des modules, ne seront pas écrit sur le système de fichiers, et donc ceux-ci ne seront pas mis à jour.
Il faut prévoir un mécanisme de mise à jour…

Téléchargement et pondération – Protocols multiples

Suite des articles Téléchargement et pondération et activation.

Jusque ici, on utilise que le protocole HTTP. C’est simple, pratique et instantané.

Mais il était prévu que les objets et liens nebule puissent transiter par d’autres protocoles, notamment la messagerie.

On va prendre pour commencer le cas de la messagerie instantanée, et plus précisément XMPP qui est à la fois fonctionnel, ouvert et universel.
Contrairement à ce que l’on pourrait penser, l’utilisation de ce protocole est assez aisé. Il faut gérer une connexion TCP, transmettre des messages pré-formatés en XML et récupérer la réponse toujours en XML.
Ce qui est plus problématique par contre, c’est qu’une instance de nebule soit bidirectionnelle, c’est à dire qu’elle soit aussi serveur. Pour qu’elle puisse être serveur, elle doit fonctionner en permanence, or en HTTP, une fois la page chargée, tout s’arrête jusqu’à la prochaine page demandée.
Il faut utiliser un serveur XMPP sur lequel se connecte un autre programme. Ce programme agira comme tout client XMPP et fera la traduction vers les spécificités nebule, en gros répondre aux demandes d’objets et de liens.
Le serveur XMPP peut garder des messages pour les clients déconnectés. Pour le côté programme serveur de nebule, ça n’a pas d’intérêt, ils peuvent être supprimés lors de la connexion initiale au serveur XMPP. Par contre, côté client nebule, ce pourrait être des réponses à des requêtes précédentes. Mais si l’on respecte le sens des échanges, on ne doit accepter que les réponses correspondantes à des requêtes, et donc il faut suivre ces requêtes.

On continue avec le protocole de messagerie SMTP. Contrairement à XMPP vu précédemment, la messagerie SMTP n’est pas temps réel, c’est à dire instantanée. C’est même pire, elle a une contrainte de temps très large. Et ceci même si un message peut traverser le monde dans la seconde. Ce qui est à son avantage en temps normal est un problème dans notre cas.
On peut donc l’inclure dans les protocoles en espérant que les réponses seront rapides.
Un autre problème, c’est qu’il faut travailler avec un serveur de messagerie tiers avec deux voir trois protocoles différents. En effet, le SMTP ne sert qu’à l’envoi, la réponse doit être consultée avec POP ou IMAP.
Difficile donc d’implémenter facilement ce protocole. Il faudrait presque refaire un serveur dédié à nebule, ce qui serait plutôt improductif…

Il va falloir maintenant normaliser pour chaque protocole les requêtes/réponses.

Évidemment, la liste supportée n’est pas fermée. D’autres protocoles pourront être ajoutés par la suite…

T̩l̩chargement et pond̩ration Рactivation

Suite aux réflexions sommaires de Téléchargement et pondération, la mise en place commence dans le code de la librairie.

Cependant, le fait de créer par défaut un lien de pondération pour une localisation peut poser problème. Les liens générés peuvent être exploités comme des traces de l’activité d’une entité. C’est une façon de savoir quand une personne, à qui appartient l’entité, est connectée et de suivre les connexions dans le temps.

Il y a deux parades à ça. La première, interdire par défaut les synchronisations sauf si c’est explicitement demandé. La deuxième, c’est de ne pas ajouter automatiquement la pondération aux localisations lors des synchronisations.

La première solution est plutôt à gérer du côté d’une application de type sylabe.

La seconde solution est à intégrer dans la librairie php sous la forme d’une option.

Avancement de la réimplémentation

La ré-implémentation de la librairie nebule php en orienté objet continue.

C’est plus long que prévu mais c’est intéressant. Cela oblige à refaire le tour des options et de leur pertinence avec le temps. C’est aussi l’occasion de revoir l’organisation de l’ensemble des fonctionnalités et de leurs places.

Je commence par le bootstrap puisque c’est l’implémentation la plus simple de nebule. Du coup, il ne change pas trop de forme mais il est réorganisé dans son fonctionnement. Un certain nombre de tests sont ajoutés pour vérifier le bon fonctionnement de l’ordinateur et de l’instance de nebule. Les entrées sorties sont vérifiées en lecture et écriture. Le bon fonctionnement de la cryptographie, qui se faisait jusque là dans sylabe, est aussi réalisée par le bootstrap. Le dysfonctionnement de certains tests critiques provoqueront le chargement de la page de bootstrap au lieu de l’application normale.

shot-2014-08-10_15-09-59

Le code correspondant, en cours de développement, est disponible ici :
http://stephane.nebule.fr/?mod=aff&obj=6ba665284be710117d2d2a2f81e8c9fe45d39e6fa270e54b7a515b63aa9eff3e

Lorsque le code sera intégré dans la librairie, les anciennes fonctions de la librairie procédurale seront ré-implémentées. Le code en orienté objet nécessite la connaissance de la programmation orientée objet, ce qui n’est pas à la portée de tout le monde puisque cela nécessite un temps de formation. Il faudra faire un guide d’utilisation de la librairie et de ses fonctions procédurales et orientées objet pour que n’importe qui puisse l’utiliser. Et puis, cela permettra aussi une transition facile pour le code de sylabe qui est en procédurale… et est assez volumineux pour moi à reprendre…

PHP et programmation objet

La librairie de référence php est en cours de portage en programmation objet, ce qui est différent de la notion d’objet propre au projet nebule.

Je me base sur différents tutoriels :
– http://fr.openclassrooms.com/informatique/cours/programmez-en-oriente-objet-en-php
– http://jcrozier.developpez.com/tutoriels/web/php/programmation-orientee-objet/
– http://stephaneey.developpez.com/tutoriel/php/php5_nouveautes/
– http://alain-sahli.developpez.com/tutoriels/php/les-interfaces/
– http://blog.xebia.fr/2011/07/18/les-principes-solid/

Les implémentations que je vais essayer de suivre pour leur côté éprouvé… et logique :
РLe mod̬le MVC.
– La notation PEAR.
РLe mod̬le Design by contract (DbC).
РLe mod̬le SOLID.

Le modèle MVC est assez logique, à tel point que c’est déjà quasiment la forme adoptée par le code de la librairie et de sylabe aujourd’hui.

Voici l’organisation du code pour l’instant :
– class nebule
– class Object extends nebule
– class Entity extends Object
– class Link extends nebule
– interface ioInterface
– class ioFileSystem implements ioInterface
– class Metrology

Exception à la notation PEAR, la classe nebule commence avec une minuscule et non une majuscule. C’est la seule.

Il y a des choses que je vais tout de suite bannir :
– On commence par les parent::quelquechose. Trop de risque de confusion et d’erreur.

A compléter…

Diffusion des mises à jours

L’entité bachue diffuse depuis hier soir les dernières versions de la librairie nebule en php et du bootstrap :

La librairie nebule en bash est en cours de mise à jours vers la version 1.2 .

Parcours restreint de graph de mise à jour

Dans sylabe, la mise en place de la traduction sous forme de modules a apporté son lot de problèmes de sécurité. Les modules peuvent contenir tout un tas de code qui ne sont pas en rapport avec la traduction. Il faut interdire par tous les moyens l’ajout de code malveillant inconnu. Il est très difficile de filtrer finement ces codes pour ne garder au mieux que ce qui concerne les traduction ou au pire rejeter l’objet qui le contient. La solution retenu est de ne reconnaître que les modules signés soit par bachue, soit par l’entité locale.

Les fonctions _l_grx et _l_gr1 de la librairie en php prennent maintenant en compte un paramètre pour restreindre la recherche des liens de mise à jours (résolution du graphe des mises à jours) aux deux entités citées ci-dessus.

Mais, si fonctionnellement c’est suffisant, on va maintenant plus loin. Au lieu de ne reconnaître que deux entités, il est maintenant possible d’en ajouter plus de façon statique. On crée en quelque sorte une liste d’autorités locales. Cette liste n’est valable que sur un serveur et pour une seule instance de sylabe ou tout autre programme similaire.

Ainsi, la variable $nebule_local_authority contient une liste des entités faisant office d’autorité locale. Elle est pré-remplie par défaut avec l’entité bachue. Elle peut être complétée.

Une autre variable $nebule_curentnotauthority permet d’interdire à l’entité courante d’être elle aussi autorité locale. A false par défaut, l’entité locale peut ajouter des modules. C’est notamment pratique pour le développement puisque l’on peut faire soi-même des évolutions de ces modules. A true, l’entité locale ne peut qu’utiliser les modules par défaut présents localement.

Il est bien sûr possible de positionner ces deux variables dans les fichiers de configuration env_nebule.php et env_sylabe.php. Cependant, leur comportement est un tout petit peu différent dans le bootstrap et dans la librairie (via une application comme sylabe).

Quelques explications s’imposent pour comprendre les différences. Schéma de fonctionnement global d’une instance :

1 – Appel du bootstrap (index.php) par le serveur web.
V
2 РEx̩cution du script php.
3 – Lecture du fichier de configuration env_nebule.php.
4 – Recherche de la librairie nebule valide à charger.
5 – Chargement de la librairie nebule (fonctions et variables).
6 – Recherche de l’application par défaut et valide.
(actuellement, c’est sylabe)
7 – Le bootstrap charge l’application et passe la main.
V
8 – Exécution du script php de l’application.
9 – Lecture du fichier de configuration env_sylabe.php.
10 – Déroulement du script de l’application…

Lors de l’exécution du bootstrap, celui-ci n’utilise pas la session utilisateur gérée par php. Il va cherche si le fichier e existe et si c’est une entité. Il prend cette entité comme étant l’entité propriétaire de l’instance. Si avec la variable $nebule_curentnotauthority on empêche de reconnaître cette entité comme autorité, seule bachue sera autorité et donc seuls ses mises à jours seront prises en compte. Ainsi, il n’est pas possible pour l’entité locale de modifier la librairie ou le programme (sylabe) sauf si ils sont signés par bachue. Une mise à jour régulière est possible.

Lors de l’exécution de l’application, ici sylabe, l’entité locale n’est pas forcément l’entité courante. Et l’entité courante n’est donc pas forcément propriétaire de l’instance mais juste utilisatrice. Si avec la variable $nebule_curentnotauthority on empêche de reconnaître cette entité comme autorité, seule bachue sera autorité et donc seuls ses modules seront pris en compte. Ainsi, il n’est pas possible pour l’entité courante de modifier les modules. Une mise à jour régulière est possible.

En clair, l’entité locale choisit la librairie nebule et le programme à charger, l’entité courante dans le programme choisit les modules. Si cela ne leur est pas interdit.

Pour ajouter d’autres autorités, il suffit de les ajouter à la variable $nebule_local_authority dans les fichiers de configuration :
$nebule_local_authority[]='88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea';

shot-2014-05-19_12-24-40