Autorité temporaire : le maître des poupées

Une entité avait été généré en novembre 2012. Elle avait pour rôle de simuler une autorité de haut niveau. Voir l’article Autorité temporaire.

Le bi-clé de cette entité n’ayant pas été généré et manipulé dans des conditions spartiates de sécurité, il était difficile d’avoir pleinement confiance en cette entité.
Il fallait donc régénérer une nouvelle entité de façon plus propre.

Une machine a été installée de façon renforcée, et est prévue pour être manipulée hors réseau.
Tous les systèmes ont leurs faiblesses, et ont donc un besoin récurrent de mise à jour. Le système le moins vulnérable face à l’absence prolongée de mises à jours, c’est OpenBSD. C’est aussi actuellement le système le moins vulnérable par défaut. La non utilisation du réseau réduit très fortement les problèmes potentiels. Il est cependant possible, en cas de nécessité, de réaliser une mise à jour manuelle.
Le disque dur est partiellement chiffré.

Cette machine a donc permit de générer une nouvelle entité racine.
Ce rôle est toujours temporaire. Il ne se justifie que pour coller à un modèle de sécurité actuel, basé sur des autorités racines de confiance. On ne peut faire confiance à une entité que si elle est validée par l’entité racine. Cependant, ce modèle de sécurité n’a pas vocation à subsister en l’état. Soit il y aura d’autres autorités racines, soit elles disparaîtront toutes.

Puppetmaster, le nouveau maître des poupées est identifié comme :

88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea

Et il reprend l’emplacement de l’ancien puppetmaster :

http://puppetmaster.nebule.org/

Pour l’instant, puppetmaster ne reconnaît aucune autre entité. Ce sera fait bientôt. Et le nouveau puppetmaster réformera (lien u) aussi officiellement l’ancien puppetmaster.
Le maître des poupées est mort, vive le maître des poupées!

OpenBSD echo off

Sous OpenBSD, c’est ksh par défaut et non bash.

Or la fonction read de ksh n’a pas d’option pour demander une saisie au clavier sans afficher ce que l’on tape, le retour clavier. C’est gênant pour la saisie d’un mot de passe par exemple. De son côté, la fonction read de bash l’accepte sous cette forme :

read -s -p "password" variable

Sous ksh, nous pouvons cependant préalablement désactiver le retour clavier, demander le mot de passe, et enfin réactiver le retour clavier. Comme ceci :

stty -echo
read variable
stty echo

Ca évite d’installer bash pour si peu…

Evenement unique multiple

Je fais une erreur depuis quelques temps dans les scripts. Le concept de base est bon mais l’implémentation est mauvaise.

En effet, lors de l’ajout d’un lien à un objet, si celui-ci existe déjà, il n’est pas ajouté. C’est un doublon.

Mais j’implémentais la vérification d’unicité du lien sur les champs Action, HashSource, HashDestination et HashMeta. Ce qui signifie que tout lien précédent disposant de ces quatre champs invalide le nouveau lien. Pourtant ce n’est pas tout à fait le même, même si il lie exactement les mêmes objets dans le même ordre et avec la même action. Ce lien peut être fait par une autre entité, rien de grave, quoique ça dépend du sens. Mais il peut être aussi généré avec une autre date, ce qui à une signification particulière = c’est le même lien volontairement refait plus tard…

L’exemple qui permet simplement de valider cette réflexion sur la multiplicité de ces liens, c’est la possible désactivation de lien.
Soit un lien L. Il peut y avoir un lien intermédiaire X (de type x) dans le temps qui invalide la première instance du lien L. Et on peut recevoir un deuxième lien L’ identique dans l’action demandé sur les même objets, et ce sans forcément avoir reçu le lien intermédiaire X de désactivation. Si l’on ne tient pas compte de la date, cela entraîne une désactivation du lien L’ à posteriori alors qu’il avait été volontairement refait après…

Une autre raison, si on se place sur un comportement plus sociale, on peut avoir répondu plusieurs fois la même chose à quelqu’un… mais à des moments différents.

Implémentation de liens sécurisés

Une première implémentation en shell bash a été réalisée pour la lecture et l’écriture de lien sécurisés.

Ces liens sont dits sécurisés parce qu’ils sont signés par une entité, et donc leur intégrité et leur provenance peuvent être vérifiés. Si la signature est invalide, ils sont simplement ignorés.

Voir l’implémentation de référence en bash.

Exemple de résultats (empreintes tronquées à 16 caractères) :
sha256:03e7785a6-975571a8a470a6d9-20120914182239-L-975571a8a470a6d9-970bdb5df1e79592-93d4a5f3ef1fc5c8
sha256:2ec7df2b9
-975571a8a470a6d9-20120914182239-L-975571a8a470a6d9-7c512aaa1c5e3837-a6b4edb371e864e4
sha256:86d8d0f2f
-975571a8a470a6d9-20120914182240-F-6a4b7f1100b87044-975571a8a470a6d9
sha256:2c7911d50
-975571a8a470a6d9-20120914182240-L-975571a8a470a6d9-37d22e047bd0173f-703c4a9a2573f76a
sha256:90952b31d
-975571a8a470a6d9-20120914182241-L-975571a8a470a6d9-69eb5187e4469dfd-93d4a5f3ef1fc5c8
sha256:3ed5b8f4c
-975571a8a470a6d9-20120914182242-L-975571a8a470a6d9-6bf6ae23819cd0d1-0e87632cd46bd490
sha256:0626480c2
-975571a8a470a6d9-20120914182243-L-975571a8a470a6d9-4b9a7f50c0bb198c-911f9ec89c20f340
sha256:51b955e0b
-975571a8a470a6d9-20120914182243-L-975571a8a470a6d9-3514acf61732f662-5ef523ac47dae4aa
sha256:01bcc6d09
-975571a8a470a6d9-20120914182243-L-975571a8a470a6d9-8527a891e2241369-b5977b836b445eaf
sha256:58a62c5ab
-975571a8a470a6d9-20120914182243-L-975571a8a470a6d9-4ec9599fc203d176-dc80905e9df6dac2
sha256:bf51f9067
-975571a8a470a6d9-20120914182244-L-975571a8a470a6d9-785f3ec7eb32f30b-28cdd20eaf134a05
sha256:553af0cc7
-975571a8a470a6d9-20120914182244-L-975571a8a470a6d9-aea92132c4cbeb26-9d64d711a2a1123e
sha256:162bfc0c5
-975571a8a470a6d9-20120914182244-L-975571a8a470a6d9-caa1aedb2a6ce96b-c0f059214d078968