La dernière mise à jour de cette page été effectuée en 2021-01.

Note: We are no longer using monotone. The project has migrated all source repos to git.

Voici une version révisée du guide original de Complication , qui explique en détail l’utilisation de Monotone dans le développement d’I2P. Pour des instructions de base, consultez le guide de démarrage.

I2P a un modèle de développement distribué. Le code source est répliqué à travers des dépôts Monotone ("MTN") administrés indépendamment. Les développeurs ayant des droits d’engagement peuvent pousser leurs changements vers le dépôt (un contrat de licence nécessite d’être signé avant que les droits d’engagement soient attribués).

Certaines des remarquables qualités de Monotone sont : contrôle de version distribué, authentification cryptographique, contrôle d’accès, petite taille, avoir peu de dépendances, stockage de projets dans un fichier de base de données SQLite compressé, et avoir la capacité de reprendre des tentatives de synchronisation interrompues.

Utiliser un client Monotone

Génération de clés de Monotone

Une clé de transport vous accorde la capacité de pousser vos changements vers un serveur de dépôt Monotone. Afin d’engager du code dans Monotone (qui par essence signe votre code), une clé d’engagement est aussi nécessaire. Aucun des serveurs publics Monotone dans I2P n’exigent actuellement de clé pour lire (ou tirer) du code source.

Sans clé de transport, on ne peut pas :

  • tirer du code depuis un serveur qui ne permet pas l’accès global en lecture
  • pousser du code vers un serveur
  • exécuter un serveur Monotone

Sans une clé d’engagement, on ne peut pas :

  • engager du code

Si vous avez seulement l’intention de récupérer le code depuis MTN, n’hésitez pas à sauter jusqu’à la section suivante. Si vous souhaitez générer des clés, lisez la suite.

Par convention, les clés sont nommées comme des adresses courriel, mais il n’est pas requis qu’une adresse courriel correspondante existe. Par exemple, vos clés pourraient être nommées :

  • yourname@mail.i2p
  • yourname-transport@mail.i2p

Monotone stocke les clés sous $HOME/.monotone/keys dans des fichiers textes qui sont nommés identiquement aux clés. Par example :

  • /home/complication/.monotone/keys/complication@mail.i2p

Pour générer des clés de transport et d’engagement, saisissez les commandes suivantes dans une ligne de commande :

  • $ mtn genkey yourname-transport@someplace
  • $ mtn genkey yourname@someplace

Monotone vous demandera un mot de passe pour protéger vos clés. Vous êtes très fortement encouragés à mettre un mot de passe pour la clé d’engagement. Beaucoup d’utilisateurs laisseront un mot de passe vide pour la clé de transport, particulièrement ceux exécutant un serveur Monotone.

Confiance, et initialiser votre dépôt

Le modèle de sécurité de Monotone aide à assurer que personne ne puisse facilement interpréter le rôle d’un développeur sans être remarqué. Puisque les développeurs peuvent faire des erreurs et devenir compromis, seul l’examen manuel peut assurer la qualité du code. Le modèle de confiance de Monotone assure que vous lisez les bonnes diffs. Il ne remplace pas la lecture des diffs.

Un dépôt Monotone est un simple fichier (une base de données SQLite compressée) qui contient le code source de tout le projet et l’historique.

Après importation des clés des développeurs dans Monotone et mise en place des crochets d’évaluation de confiance, Monotone empêchera le code non fiable d’être approuvé dans votre espace de travail. Il existe des commandes pour nettoyer le code non fiable de votre espace de travail, mais dans la pratique elles n’ont pas été nécessaires, en raison des politiques d’accès en poussée mises en œuvre.

Un dépôt peut retenir beaucoup de branches. Par exemple, notre dépôt retient les branches principales suivantes :

  • i2p.i2p — Le routeur I2P et les programmes associés
  • i2p.www — Le site Web de projet d’I2P
  • i2p.syndie — Syndie, un outil de forums distribués

Par convention, le dépôt Monotone de I2P est nommé i2p.mtn. Avant de tirer le code depuis les serveurs, une base de données pour votre dépôt devra être initialisée. Pour initialiser votre dépôt local, allez dans le répertoire dans lequel vous voulez que le fichier i2p.mtn et les répertoires de branche soient stockés (ex: $HOME/.monotone/) et tapez la commande suivante :

  • $ mtn --db="i2p.mtn" db init

Obtention et déploiement de clés de développeurs

Les clés que les développeurs utilisent pour engager du code sont essentielles pour l’évaluation de confiance dans Monotone. Les clés de transport des autres développeurs sont seulement exigées pour les opérateurs de serveurs Monotone.

Les clés d’engagement des développeurs sont fournies signées en GPG sur une autre page.

Pour importer les clés de développeurs après avoir vérifié leur authenticité, copiez toutes les clés dans un nouveau fichier. Créez ce fichier (ex: keys.txt) dans le même répertoire dans lequel i2p.mtn est localisé. Importez les clés avec la commande :

  • $ mtn --db="i2p.mtn" read < keys.txt

Note: ne jamais ajouter de clés à $HOME/.monotone/keys manuellement.

Mettre en place des crochets d’évaluation de confiance

La politique de confiance de Monotone par défaut est beaucoup trop faible pour nos exigences : chaque contributeur est digne de confiance par défaut. Ceci n’est pas acceptable pour le développement de I2P.

Allez dans le répertoire $HOME/.monotone puis ouvrez le fichier monotonerc avec un éditeur de texte. Copiez et collez les deux fonctions suivantes dans ce fichier : 

-- This implements a list of trusted signers.
-- It is used on checkout and update.
-- It is not used for repo sync/push/pull.
-- If you do not include this function in ~/.monotone/monotonerc, the
-- default is to trust everybody, which is probably a bad thing
-- in an anonymous network.
-- Update the list below to reflect the signers YOU trust.
--
-- ref: http://www.monotone.ca/docs/Trust-Evaluation-Hooks.html
-- Modified to use key identities instead of key names, since
-- monotone allows duplicate key names, so any key-name-based
-- trust system is insecure.

--
--  Modified from intersection() to use key identities instead of key names, since
--  monotone allows duplicate key names.
--
--  a: table of ID structures (see above)
--  b: table of hex IDs
--
function keyintersection(a,b)
    local s={}
    local t={}
    for k,v in pairs(a) do s[v.id] = 1 end
    for k,v in pairs(b) do if s[v] ~= nil then table.insert(t,v) end end
    return t
end

--
-- from mtn source project.hh and lua_hooks.cc:
-- signers is a table of integers (starting with 1) to the following ID structure:
-- struct ID
-- {
--   id: (key_id in key_identity_info) hex of revision id hash;
--   given_name: (given_name in key_identity_info) // name given when creating the key
--   name: (official_name in key_identity_info) // name returned by hooks or (once implented) policy
-- };
-- id: hex of revision id hash;
-- name: cert_name
-- val: cert_value
--
function get_revision_cert_trust(signers, id, name, val)
   local trusted_signers = {
		"5bc185cfd680eb512fdb9626b9fb4298e136215e",	--  BlubMail@mail.i2p
		"f6706ac205e6b5d7a7e3ea4244ab0ef497f0a099",	--  cervantes@mail.i2p
		"690f278ff6c6157cbaf23b0d602b6d6dcf368313",	--  complication@mail.i2p
		"eb4ac08d5ddbb2bd73889f86c1211424025a6f07",	--  dev@robertfoss.se
		"aae785027c240ebbb0a883fd8ebcf8d6ecee4104",	--  dev@welterde.de
		"86478595288d1b96b58f0c8cd8a8971bc430f8fd",	--  dg2@mail.i2p
		-- completed dev agreement 2013-07 but never checked in anything
		--"5f75b8f0769770edc3267c21ddc9a00ddae31394",	--  digit@mail.i2p
		"4ebaace9973913416af92ee8d0fb93d64753df4c",	--  dream@mail.i2p
		"7e498ae94c9c322404adfc61b16bed388095906b",	--  duck@mail.i2p
		"6c728b0ffed3c2bf7fb0f3c583b30f966d9bacd5",	--  echelon2@mail.i2p
		"0e4e7ebebafbdf4cdacc45a47ba155b1215d8e8b",	--  forget@mail.i2p
		"f332b3d3b11b2efdae220cea75b9d5ba9ec3b52d",	--  hamada@mail.i2p
		"d681db14fd98da1efd6f8ceb2be6b91d784bdf5c",	--  hankhill19580@gmail.com
		"e246444b4fe69ba599e13403c4ab931066de902f",	--  hiddenz@mail.i2p
		"a61146ee69ddb9fcf3b82b19a62b8114b60d367e",	--  HungryHobo@mail.i2p
		"4844b1fd45f5a68744fa28d2f3e3b61a3cf83b95",	--  kytv@mail.i2p
		"6b2acfc9fe2f69b796631a514660fd7bdd237e2d",	--  laziestgravy@mail.i2p
		"c9b970f5e8917eada663d4c6b22096617021c95c",	--  m1xxy@mail.i2p
		"3be64909d6ab7c3d7afe16f20f24e672708b576b",	--  magma@mail.i2p
		"2977a6f4e11819a3f928783175caadc0071fc4de",	--  mathiasdm@mail.i2p
		"de9d196e8057e1629178edbfa1ed754c648d7340",	--  meeh@mail.i2p
		"2a0bba98558d7a9d7e4b1bd807789601252c0024",	--  mkvore-commit@mail.i2p
		"6ade4b7a9a6425194f482ab351950e4230dbbc85",	--  neutron@mail.i2p
		"bc74b49fd8a20513b2745a3d13414b7e9818dd18",	--  Oldaris@mail.i2p
		"3fb8d1ee1e82981a8076ddbcbf4d18f372b8bba7",	--  privateer@mail.i2p
		"e3815f0c985663182534fbd7d6a2bf93204a0bd0",	--  russiansponsor@mail.i2p
		"2ef1ae1e73a30e1afc0b4a7af89b4380b3dd46b7",	--  slumlord@mail.i2p
		"1092773c40f5813b9179d52a8ab7b499b9554da3",	--  sponge@mail.i2p
		"01265f0c817b24548478341fb75e672720a78b21",	--  str4d@mail.i2p
		"38fe2aa37e1eb9a300a2061ef153265c48031c6b",	--  walking@mail.i2p
		"a0eb78d437efad120dd9edcd776a327ec2c2adde",	--  zab@mail.i2p
		"2158706490e62a17c8140b6e9eabca965b681bc7",	--  zab2@mail.i2p
		"56810cd6434ab33593260e188b32bb83e4e9a139",	--  z3r0fox@mail.i2p
		"896e399990704373125f782ae2ee19b6611ac612"	--  zzz@mail.i2p
   }
   local t = keyintersection(signers, trusted_signers)
   if t == nil then return false end
   if #t>= 1 then return true end
   return false
end

La première fonction détermine une intersection entre deux ensembles, dans notre cas un signataire de révision et un signataire éprouvés.

La deuxième fonction détermine la confiance en une révision donnée, en appelant le première fonction avec "signataires" et "éprouvé" comme arguments. Si l’intersection est vide, la révision est non digne de confiance. Si l’intersection n’est pas vide, la révision est digne de confiance. Autrement, la révision est non digne de confiance.

Plus d’informations sur les crochets d’évaluation de confiance se trouvent dans la documentation officielle de Monotone.

Tirer les branches i2p.i2p, i2p.www et i2p.syndie

I2P est livré avec un tunnel pré-configuré pointant vers le serveur Monotone du projet. Assurez que ce tunnel a été démarré dans I2PTunnel avant de tenter de tirer le code source depuis 127.0.0.1:8998.

Saisissez dans le répertoire dans lequel vous avez initialisé le code i2p.mtn. Selon que vous voulez seulement les sources d’I2P, ou aussi les sources du site Web I2P et de Syndie, vous pouvez accomplir l’opération pull de différentes façons.

Si vous souhaitez seulement des sources d’I2P :

  • $ mtn --db="i2p.mtn" -k "" pull "mtn://127.0.0.1:8998?i2p.i2p"

Si vous souhaitez toutes les branches :

  • $ mtn --db="i2p.mtn" -k "" pull "mtn://127.0.0.1:8998?i2p.*"
Si le transfert s’arrête avant l’achèvement complet, répétez simplement la commande de traction ce qui reprendra le transfert.

Le tirage lors des exemples susdits est fait anonymement en spécifiant une clé de transport vide. Si tout le monde tire anonymement ce sera plus dur pour un attaquant qui prendrait le contrôle du serveur de fournir sélectivement à quelques personnes des données trifouillées.

Vérifier que l’évaluation de confiance fonctionne

Pour vérifier que l’évaluation de confiance fonctionne :

  • Faites une sauvegarde de votre fichier monotonerc.
  • Modifiez monotonerc en modifiant la variable trusted_signers de façon suivante : 
           local trusted_signers = {}
  • Avec monotonerc configuré comme ci–dessus, Monotone n’aura plus confiance en aucun des engagés. Confirmez–ceci en allant dans le répertoire où i2p.mtn a été créé, puis tentez d’obtenir la branche I2P :
    • $ mtn --db="i2p.mtn" co --branch="i2p.i2p"

    Un répertoire nommé i2p.i2p ne devrait pas apparaître. Vous devriez rencontrer beaucoup de messages d’erreurs tels que : 

        mtn: warning: trust function disliked 1 signers
    of branch cert on revision 523c15f6f50cad3bb002f830111fc189732f693b
    mtn: warning: trust function disliked 1 signers
    of branch cert on revision 8ac13edc2919dbd5bb596ed9f203aa780bf23ff0
    mtn: warning: trust function disliked 1 signers
    of branch cert on revision 8c4dd8ad4053baabb102a01cd3f91278142a2cd1
    mtn: misuse: branch 'i2p.i2p' is empty

    Si les résultats vous conviennent, restaurez la sauvegarde de monotonerc qui a été créée à l’étape précédente. Si vous n’avez pas créé de sauvegarde comme conseillé, relisez Mettre en place des crochets d’évaluation de confiance.

    Obtenir une copie fonctionnelle de la dernière version

    Si vous avez déjà obtenu une branche, passez à la section suivante.

    Allez dans le répertoire où i2p.mtn est placé. Là–bas envoyez :

    • $ mtn --db="i2p.mtn" co --branch="i2p.i2p"

    L’obtention (checkout) devrait être complète sans messages d’erreur et un répertoire nommé i2p.i2p devrait apparaître dans le répertoire actuel. Félicitations ! vous avez obtenu avec succès les dernières sources d’I2P, prêtes à être compilées.

    Mise à jour de votre copie de travail vers la dernière version

    Si vous n’avez pas déjà fait ceci, tirez le code frais hors du serveur vers votre dépôt Monotone local. Pour accomplir ceci, allez dans le répertoire où i2p.mtn est localisé, puis entrez :

    • $ mtn --db="i2p.mtn" -k "" pull "mtn://127.0.0.1:8998?i2p.i2p"

    Maintenant allez dans votre répertoire i2p.i2p, et là–bas envoyez :

    • $ mtn update

    Si il n’y a pas d’erreurs …Félicitations ! vous avez réussi à vous mettre à jour aux dernières sources d’I2P. Elles devraient être prêtes à être compilées.

    Opérer un serveur Monotone

    Obtention et déploiement des clés de transport de développeur

    En tant qu’opérateur de serveur vous pouvez vouloir accorder l’accès en poussée à certains développeurs.

    Octroi des accès en poussée et traction

    Par défaut le serveur Monotone refuse tout accès.

    Pour accorder l’accès en traction à tous les clients, mettez la chose suivante dans $HOME/.monotone/read-permissions: 

        pattern "*"
    allow "*"

    Personne ne pourra pousser du code vers votre serveur sans permission accordée explicitement. Accorder l’accès en poussée :

    • Ajoutez le nom de l’utilisateur de clé de transport à $HOME/.monotone/write-permissions, tel que 
      zzz-transport@mail.i2p
complication-transport@mail.i2p
      avec une clé par ligne.
    • Importez la/les clé(s) de transport dans votre base de données. La procédure pour importer des clés de transport est la même que pour importer des clés d’engagement, qui est décrite dans la section Obtention et déploiement des clés de transport de développeur.

    Exécuter Monotone en mode serveur

    Une base de données séparée devrait être utilisée pour votre serveur Monotone, car Monotone verrouillera la base de données si elle est servie à d’autres. Faites une copie de votre base de données de développement, puis lancez le serveur avec :

    • $ mtn serve --bind="127.0.0.1:8998" --db="i2p.mtn" --key "myserver-transport@mail.i2p"
    Si votre clé est protégée par une phrase de passe, Monotone pourrait demander la phrase de passe quand le premier client se connecte. Vous pouvez contourner cela en établissant la première connexion client vers votre serveur (ou en effaçant la phrase de passe de votre clé de transport).

    Pour que votre serveur puisse être accessible à d’autres via I2P, vous devrez créer un tunnel de serveur pour cela. Utilisez le type de tunnel "Standard" et le profil "Bulk".

    Différences sous Debian GNU/Linux

    Debian (parmi d’autres distributions) a intégré Monotone dans leur framework de démons/services. Bien que les serveurs Monotone puissent toujours être exécutés de la "façon ordinaire" sur des systèmes Debian, le faire à la "façon Debian" peut être plus direct.

    Les droits sont donnés en éditant les fichiers /etc/monotone/read-permissions et /etc/monotone/write-permissions. Vous devrez aussi éditer /etc/default/monotone pour activer le lancement de Monotone lors de l’amorçage ou pour personnaliser l’hôte, le port ou l’emplacement de la base de données.