fr/volunteer.wml (a766dbdda) - tor-webwml.git

volunteer.wml

## translation metadata
# Based-On-Revision: 13966
# Last-Translator: fredzupy@gmail.com

#include "head.wmi" CHARSET="UTF-8" TITLE="Tor : Contribuer"

<h2>Trois choses que vous pouvez faire :</h2>
<ol>
<li> Pensez à <a href="<page docs/tor-doc-relay>">héberger 
un relais</a> pour aider à la croissance du réseau Tor.</li>
<li> Informez vos ami-e-s ! Faites-leur héberger des serveurs. Faites-leur utiliser les services 
cachés. Encouragez-les à informer leurs propres ami-e-s.</li>
<li> Nous recherchons des fonds et des mécènes. Si vous adhérez aux objectifs de Tor, prenez s'il-vous-plaît un moment 
 <a href="<page donate>">pour faire un don et aider aux développements 
 futurs de Tor</a>. De même, si vous connaissez des 
 entreprises, des ONGs, ou d'autres organisations qui souhaitent utiliser des communications 
 sécurisées, parlez-leur de nous.</li>
</ol>

<a id="Usability"></a>
<h2><a class="anchor" href="#Usability">Support d'applications</a></h2>
<ol>
<li>Nous avons besoin de méthodes efficaces d'interception des requêtes DNS, pour qu'elles ne laissent pas filtrer 
d'informations à un observateur local pendant que nous tentons d'être anonymes. (Ce qui 
arrive lorsque l'application fait sa résolution DNS avant de passer par 
le proxy SOCKS.)</li>
<li>Élements tsocks/dsocks :
<ul>
<li>Nous avons besoin <a href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches">d'appliquer 
tout nos patchs à tsocks</a> et d'en maintenir une nouvelle branche. Nous l'hébergerons si 
vous le souhaitez.</li>
<li>Nous devrions patcher le programme « dsocks » développé par Dug Song pour utiliser les commandes 
mapaddress de Tor depuis l'interface de contrôle, de manière à ne pas faire 
inutilement un aller-retour complet dans Tor pour faire la résolution avant la 
connexion.</li>
<li>Notre script torify doit détecter lequel de tsocks ou 
dsocks est installé pour l'appeler correctement. Cela nécessite certainement 
d'unifier leurs interfaces, et peut amener à faire un mix des deux 
voire à en éliminer un des deux.</li>
</ul>
</li>
<li>Les gens qui hébergent des serveurs nous signalent qu'ils aimeraient avoir une passante allouée 
durant une partie de la journée, et une autre bande passante à un autre moment. 
Plutôt que de coder ceci dans Tor, nous aimerions utiliser un petit 
script qui communique avec <a href="<page gui/index>">l'interface de contrôle de Tor</a>, 
et ferait un setconf pour changer la valeur de la bande passante. Éventuellement, ce pourrait être un script lancé 
par cron, ou qui se lancerait à certaines heures (
ce qui est certainement plus portable). Quelqu'un pourrait-il écrire cela pour nous, 
nous l'ajouterons à <a href="<svnsandbox>tor/contrib/">tor/contrib/</a> ? 
C'est une bonne entrée pour la <a href="<page gui/index>"> compétition pour l'interface 
graphique de Tor</a>.
 
</li>
<li>Tor peut <a 
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">quitter 
le réseau Tor par un noeud de sortie particulier</a>, mais il serait pratique 
de n'avoir qu'à spécifier un pays, et que le serveur de sortie soit choisi automatiquement. Le 
meilleur moyen est probablement de récupérer le répertoire de Blossom, et d'utiliser en local un client 
qui récupère ce répertoire de manière sûre (via Tor et en vérifiant sa 
signature), lise les noms des machines <tt>.country.blossom</tt> et se charge ensuite
de choisir le serveur.</li>
<li>En parlant de géolocalisation, quelqu'un devrait faire une carte de la Terre 
indiquant chaque serveur Tor par un point. La cerise sur le gâteau serait la mise à jour dynamique 
de la carte à mesure que le réseau Tor évolue et grandit. Malheureusement, les moyens aisés de faire cela 
passent par l'envoi de toutes les données à Google pour qu'il trace cette carte pour vous. Dans quelle mesure 
cela jouerait-il sur la confidentialité, et par ailleurs, existe-t-il des solutions de remplacement valables ?</li>
</ol>

<a id="Documentation"></a>
<h2><a class="anchor" href="#Documentation">Documentation</a></h2>
<ol>
<li>Aidez Matt Edman à documenter et à écrire des tutoriaux pour son 
contrôleur Tor,
<a href="http://vidalia-project.net/">Vidalia</a>.</li>
<li>Évaluez et documentez 
<a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">notre 
liste de programmes</a> pouvant être utilisés avec Tor.</li>
<li>Nous avons besoin d'une meilleure documentation traitant de l'interception dynamique de 
connexions et de leur envoi à travers Tor. tsocks (Linux), dsocks (BSD), 
et freecap (Windows) semblent être de bons candidats, et utiliserait au mieux
notre nouvelle fonctionnalité Transport.</li>
<li>Nous avons toute une liste de <a href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">programmes 
potentiellement utiles qui s'interfacent avec Tor</a>. Lesquels sont utiles et dans quelles 
situations ? Contribuez à les tester et à documenter les résultats.</li>
<li>Aidez-nous à traduire le site et la documentation dans d'autres 
langues. Allez voir les <a href="<page translation>">conseils de 
traduction</a> si vous souhaitez le faire. Nous avons besoin plus spécialement de personnes pour 
traduire en Arabe ou en Persan pour les utilisateurs Tor situés dans les zones censurées.</li>
</ol>

<a id="Coding"></a>
<a id="Summer"></a>
<a id="Projects"></a>
<h2><a class="anchor" href="#Projects">Projets de code sympas</a></h2>
<ol>
 	 
<li>
Tor/Polipo/Vidalia cadre de mise à jour automatiques
 
Priorité : élevée
 
Niveau d'effort : élevé
 
Niveau de connaissane : élevé
 
Mentors probables : Matt, d'autres
 
Vidalia à déjà la capacité de notifier quand un utilisateur fait tourner une
ancienne version ou une version non recommandée de Tor. Pour l'instant, Vidalia signale simplement
à l'utilisateur qu'il doit manuellement mettre à
jour. Le but de ce projet serait d'étendre la capacité de Vidalia en lui 
permettant également de rappatrier et installer la mise à jour de Tor à la place de
l'utilisateur. Si le temps le permet, nous aimerions aussi être capable de faire de même
pour les autres applications du « tout en un » comme Polipo et 
Vidalia lui même.
 
Pour mener à bien ce projet, l'étudiant devra premièrement avoir besoin d'enquêter
sur les ensembles de mises à jour déjà existant (p.e. Sparkle sur OS X) pour évaluer
leur forces, leurs faiblesses, les implications de sécurité, et la capacité à être
intégré dans Vidalia. Si aucun ne convient, l'étudiant
fera son propre cadre de mise à jour automatique, documentera la conception, et
discutera alors avec les autres développeurs pour évaluer tout problème de 
sécurité. L'étudiant pour alors implémenter son cadre (ou intégrer
l'existant) et le tester.
 
L'étudiant qui entreprendra ce projet devra avoir une bonne expérience en 
développement C++. Une expérience passée sur Qt est utile, mais non requise. L'
étudiant devrait avoir également une compréhension basique des pratiques de sécurité
usuelles, telle que la vérification de signature de paquet. Une bonne capacité d'écriture
est également importante pour ce projet, puisqu'une étape cruciale conciste à produire
un document de conception pour que les autres puissent le relire et discuter avec l'étudiant
avant l'implémentation.
</li>
 	 
<li>
Une carte du réseau étendue et plus utilisable
 
L'une des options existante de Vidalia est une carte du réseau qui montre la localisation
géographique approximative du relais dans le réseau Tor et
trace le chemin du trafic utilisateur tel qu'il est tunnellisé à travers le
réseau Tor. La carte n'est pour l'instant pas très interactive et est plutôt 
pauvre graphiquement. À la place, nous aimerions profiter du widget Marble de KDE
qui nous apporterait une carte de meilleur qualité et étendrait l'interactivité,
en permettant à l'utilisateur de cliquer sur des relais ou circuit pour 
obtenir des informations supplémentaires. Il serait aussi souhaitable de permettre
à l'utilisateur de cliquer sur un relais particulier ou un pays contenant un ou
plusieurs relais Tor de sortie et dire « je souhaite que mes connexions à truc.com sortent
par là ».
 
Ce projet nécessite d'abord que l'étudiant soit à l'aise avec Vidalia
et l'API de l'objet Marble. L'étudiant devra alors intégrer l'objet dans 
Vidalia et configurer Marble pour s'indapter dans notre application,
comme faire des circuits cliquable, stocker des données cartes dans le répertoire
de donnée de Vidalia, et adapter quelques une des boites de dialogue.
 
L'étudiant prenant en charge ce projet devra avoir une bonne expérience en 
développement C++. Une expérience avec Qt et CMake est utile, mais non
requise.
</li>
 	 
<li>
Mise en paquet Debian et support
 
Vidalia ne s'intègre pas facilement sous Debian et Ubuntu avec les 
paquets par défaut Tor. Le paquet Tor courant démarre automatiquement Tor
en tant que démon tournant avec l'utilisateur debian-tor et (judicieusement) n'a pas 
de ControlPort défini dans son torrc par défaut. En conséquence de quoi, Vidalia tente
de lancer son propre processus Tor puisqu'il n'arrive pas à se connecter à un Tor existant, 
Le Tor de Vidalia quitte ensuite avec un message d'erreur que 
l'utilisateur a des chances de ne pas comprendre puisque Tor n'arrive pas à prendre le port
d'écoute—-il est déjà pris par le démon Tor original.
 
La solution actuelle implique soit de dire à l'utilisateur de stopper le Tor
existant et laisser Vidalia lancer son propre processus Tor, ou
expliquer à l'utilisateur comment paramètrer le port de control et le mot de passe dans leur
torrc. Une meilleur solution sous Debian serait d'utiliser le ControlSocket de Tor,
qui permet à Vidalia de communiquer avec Tor par une socket Unix, et pourrait 
être activée par défaut dans le paquet Debian. Vidalia pourrait 
alors s'identifier sur Tor en utilisant une identification par cookie si l'utilisateur faisant tourner
Vidalia est également dans le groupe debian-tor.
 
Ce projet devra premièrement ajouter le support dans Tor d'une ControlSocket 
pour Vidalia. L'étudiant devra alors développer et tester les paquets pour Debian et
Ubuntu qui se conforment aux standards de déploiment Debian et
s'assurer que ça fonctionne bien avec les paquets Tor courant. We nous pouvons également
mettre en place un dépôt apt pour héberger les nouveaux paquets Vidalia.
 
L'étudiant qui prendra en charge ce projet devra avoir une expérience passée dans 
la gestion des paquets Debian et une expérience en développement C++. Des connaissances
sur Qt aident mais ne sont pas requises.
</li>
 	 
<li>
Interface d'évenements de status Tor
 
Il existe de nombreux changement de status pour lequel l'utilisateur devrait 
être informé. Par exemple, si l'utilisateur essaye de mettre au point un 
relais Tor et que Tor montre que le relais utilisateur n'est pas atteignable à l'exterieur
du réseau utilisateur, nous devrions alerter l'utilisateur. Pour l'instant, l'utilisateur n'a
que deux ligne dans les messages de log de Vidalia, qui ont des chances de n'être jamais vues
puisqu'aucune notification du dysfonctionnement n'est envoyée. Même si l'utilisateur regarde les messages,
la plupart sont sans significations pour l'utilisateur novice.
 
Tor a la capacité d'informer Vidalia de changement de status similaires, et
nous avons récemment implémenté le support pour deux de ces évennements. Mais
il y'a beaucoup d'autres evènements pour lesquels l'utilisateur doit être informé et nous
avons besoin d'une meilleur interface graphique pour les afficher à l'utilisateur.
 
Le but de ce projet est de concevoir et implémenter une interface graphique 
pour afficher les évenements de status Tor à l'utilisateur. Par exemple, nous pourrions mettre un
petit badge sur l'icone de Vidalia pour alerter l'utilisateur d'un nouvel 
évenement qu'il devrait regarder. Double-cliquer sur l'icone pourrait ouvrir 
une fenêtre qui résumerait les évenements récent en termes simples et pourquoi pas,
suggerer une solution pour tout status négatif s'ils sont corrigeable par l'
utilisateur. Bien entendu, ceci n'est qu'un exemple et l'étudiant est libre de
proposer une autre approche.
 
L'étudiant qui prendra en charge ce projet devra avoir une bonne expérience dans la conception et l'ergonomie 
des interfaces graphique et quelques expériences en développement C++. Des expériences passées avec 
Qt et Qt Designer seraient très utiles, mais non requises. Une
bonne capacité d'écriture en Anglais sera très utile, puisque ce projet à des chances
de nécessiter la rédaction de petites aides qui puissent être comprises
par des personnes non techniques. Des points de bonus pour la modelisation de nouvelles
icone puisque nous en auront surement besoin.
</li>
 	 
<li>
Un Wiki traduction
 
Nous avons besoin d'un moyen d'éditer et traduire le site web &mdash;
qui pourrait aboutir à un patch pour l'arbre svn. L'actuel
«Coût» de la publication des modifications apportées au site Web est assez élevé, même pour l'anglais.
Les mainteneurs ont besoin de consulter nos fichiers modèles, les traduire
et nous envoyez la traduction. Pour changer un seul mot ou n'importe quel type de
changement mineur, la page ne peut jamais être corrigées ou traduites. Il serait
bien d'avoir un wiki qui a été spécialement conçu pour la traduction
et pourrait traquer à partir de la version officielle (anglaise) si
une nouvelle traduction est nécessaire. Cela semble être le travail d'un intégrateur wiki
ou un auteur de logiciel wiki. Certes, la personne devra
être intéressées par les langues et de la traduction. Il devrait au moins
à minima être familier avec ce que Tor est mais n'aurait pas d'interaction
avec le logiciel, seulement la documentation sur le site.
</li>
 	 
<li>
Améliorations de notre testeur de configuration active de navigateur -
<a href="https://check.torproject.org">https://check.torproject.org</a>
 
Actuellement, nous avons une page Web fonctionnelle pour détecter si Tor fonctionne. Il 	 
ya des manques à quelques endroits. Il nécessite quelques améliorations s'agissant
des langues par défaut et des fonctionnalités. Il répond pour l'instant qu'en
Anglais. De plus, c'est un hack d'un script perl qui n'aurait
jamais dû voir le jour. Il devrait être réécrit en python
avec un support multi-langues. Il utilise actuellement la liste de sortie DNS 
Tor et devrait continuer à faire de même dans le futur. Il peut y'avoir de temps en temps
des faux positif et ceci devrait être découvert, documenté et corrigé lorsque 
c'est possible. Toute personne travaillant sur ce projet devrait être interessée par 
DNS, les bases de perl ou de préférence python et auront un peu à interagir avec
Tor pour tester leur code.
</li>
 	 
<li>
Amélioration de notre liste de sortie DNS -
<a href="http://exitlist.torproject.org">http://exitlist.torproject.org</a>
 
Le logiciel exitlist est écrit par notre fabuleux contributeur 
anonyme Tup. C'est un serveur DNS écrit en Haskell qui supporte une partie de notre <a
href="https://www.torproject.org/svn/trunk/doc/contrib/torel-design.txt">document
de conception exitlist</a>. Actuellement, c'est fonctionnel et utilisé par
check.torproject.org et d'autres utilisateurs. Les problèmes qui sont en suspens
sont pour la plupart esthétiques. Ce service merveilleux pourrait bien mieux utiliser
le site web en utilisant la charte graphique Tor. It serait mieux servi avec une meilleure
documentation pour les services communs qui utilisent une RBL. Il pourrait y'avoir d'avantage
de publicité. La personne travaillant sur ce projet devrait être interessée par les DNS,
la configuration basique de RBL pour des services populaires, et écrire de la documentation.
La personne devrait avoir un peu d'interaction avec Tor &mdash; tester leur propre
documentation au minimum. De plus, ce serait utile
qu'il soit interessé par Haskell et souhaite implémenter d'avantages des suggestions du 
torel-design.txt.
</li>
 	 
<li>
Tester l'intégration de Tor avec les navigateur pour nos utilisateurs finaux

Le Projet Tor manque actuellement de test solide pour s'assurer que 
l'utilisateur a proprement configuré son navigateur. Il devrait tester la plupart
des problèmes connus autant que possible. Il devrait essayer de découvrir 
l'utilisateur par tous les moyens possibles. Deux pages web qui tracent ces
type de problèmes sont fournies par Greg et HD Moore. Greg conserve une bonne <a
href="http://pseudo-flaw.net/tor/torbutton/">liste de problèmes avec 
leur code de preuve de concept, les bugs, etc</a>. HD Moore fournit
le <a href="http://metasploit.com/research/misc/decloak/">site
decloak</a>. Une personne interessée par l'attaque de Tor peut commencer
par collecter autant de solutions fonctionnelles et de méthodes connues pour réveller
un utilisateur Tor. La personne devrait être familière des écueils courants mais pourrait
avoir d'autres méthodes en tête pour implémenter des outils de désanonymisation. Le
site web devrait s'assurer d'informer l'utilisateur de ce que sont ses problèmes. Il
devra l'aider à les résoudre ou les renvoyer directement sur le bon canal de 
soutien. La personne devra être très familière dans l'utilisation de Tor et comment
palier aux fuites de Tor.
</li>
 	 
<li>
Accroitre notre capacité à résister à la censure.
 
Tor a besoin de d'avantage de mécanisme de résistance à la censure. Il y a
plusieurs mécanismes qui peuvent aider. Tor pourrait être capable d'écouter sur de multiples
adresses et ports, et autoriser les clients à se connecter sur l'ensemble d'entre eux.
Tor pourrait apparaitre comme un serveur web (HTTP ou HTTPS) lorsqu'il
est contacté par scanner de ports.
</li>
 	 
<li>
Amélioration de l'intégration Libevent et Tor
 
Tor devrait faire un meilleur usage des récentes options de Niels Provos dans
la bibliothèque Libevent. Libevent apporte déjà HTTP et des tampons de socket ;
Le code de Tor pour ces choses pourrait être remplacé. Nous aurons à améliorer le code
de libevent autant que nécessaire ; particulièrement, pour ajouter un bon support openssl au dessus de
la couche d'abstraction des tampons de libevent.
</li>
 	 
<li>
Étendre les performances de Tor!
 
Tor pourrait mesurer la bande passante de manière distribuée, comme dans cette publication
<a href="http://freehaven.net/anonbib/">« A Tuneup for Tor »</a>
de Snader et Borisov. L'étudiant pourrait utiliser le code déjà existant
pour contrôler les conclusions de ce document et vérifier dans quelle mesure elles
rejoignent Tor dans la réalité, et déterminer de bonnes méthodes de les incorporer
dans le réseau Tor sans ajouter un trafic indésirable d'ordre n² 
sur les annuaires principaux.
</li>
 	 
<li>
Améliorer le processus qualité de Tor : Intégration continue pour les paquets Windows
 
Il serait interessant d'avoir une automatisation des compilation pour Windows et
probablement d'autres plateformes. Le but d'avoir une intégration continue
des environnements est de s'assurer que Windows n'est pas mis de coté pour aucun
des projets logiciels utilisés par le Projet Tor où ses contributions. 
Buildbot serait un bon choix pour ça puisqu'il semble supporter l'ensemble des 
platformes de Tor. Voyez l'
<a href="http://en.wikipedia.org/wiki/BuildBot">entrée wikipedia pour
buildbot</a>. 
Il pourrait y'avoir de meilleurs options et la personne prenant en charge cette tâche devrait
évaluer d'autres options. Toute personne travaillant sur ce processur de compilation 
automatique devrait avoir ou être en mesure d'avoir l'expérience pour apprendre à construire l'ensemble
des sources relatives à Tor à partir du début. En outre, la
personne devrait avoir l'expérience de la compilation sous un environnement
Windows puisqu'il s'agit de l'audience finale dont nous voulons nous assurer que nous ne les laissons
pas à la traine. Ça devrait nécessiter un travail proche du code source de Tor mais
probablement uniquement sous l'aspect compilation, pas de rédaction de code. 
De plus, nous avons besoin d'automatiser nos tests de performance pour toutes les plateformes.
Nous avons buildbot (excepté sous Windows &mdash; comme dit au dessus) pour automatiser
notre intégration régulièrement et tester la compilation déjà,
mais nous avons besoin d'avoir notre test de simulation de réseau (comme dans torflow)
mis à jour pour des versions plus récentes de Tor, et faites pour lancer un test
de réseau à la fois sur une seule machine, et sur plusieurs, afin que nous puissions tester
les changements de performance sur des machins de roles différents automatiquement. 
</li>
 	 
<li>
Amélioration de notre banc de test
 
Tor doit être bien plus testé. C'est un effort multi-partie. Pour commencer,
Notre unité de couverture de test devrait augmenter substantiellement, spécialement dans
les zones en dehors des fonctions utilitaires. Ceci devra conduire à une refonte
significative des certaines parties de Tor, dans le but de dissocier autant de logique
que possible de la globalité. 
De plus, nous avons besoin d'automatiser nos tests de performance pour toutes les plateformes.
Nous avons buildbot (excepté sous Windows &mdash; comme dit au dessus) pour automatiser
notre intégration régulièrement et tester la compilation déjà,
mais nous avons besoin d'avoir notre test de simulation de réseau (comme dans torflow)
mis à jour pour des versions plus récentes de Tor, et faites pour lancer un test
de réseau à la fois sur une seule machine, et sur plusieurs, afin que nous puissions tester
les changements de performance sur des machins de roles différents automatiquement. 
</li>
 	 
<li>
Aider à raviver la communauté Java autour de Tor
 
Réanimer l'une des approches d'implématation d'un client Tor en Java,
p.e. le <a href="http://onioncoffee.sourceforge.net/">Projet
OnionCoffee</a>, et le faire tourner sur <a
href="http://code.google.com/android/">Android</a>. La première étape
pourrait être de porter le code existant et l'exécuter dans un environnement
Android. Ensuite, le code pourrait être mis à jour pour supporter les nouvelles
version de protocole comme la <a href="<svnsandbox>doc/spec/dir-spec.txt">v3
des protocole d'annuaire</a>. Ensuite, le support pour les requêtes ou même
apporter des services cachés serait sympa, mais non requis. L'étudiant
devrait être capable de comprendre et écrire du code Java, comprenant
une API de cryptographie Java. Capable de lire du code C serait utile,
également. L'étudiant devrait être prêt à lire la documentation existante,
implémenter du code de celle ci, et, si nécessaire, refaire la documentation
si des éléments ne sont pas documentés. Ce projet est principalement du codage et
à un degré moindre, de la conception.
</li>
 	 
<li>
Devenir le Maître PuppeTor
 
Écrire un outil qui lance un système de tests automatique en plus
de l'unité de tests existante. Le simulateur Tor en Java <a
href="https://tor-svn.freehaven.net/svn/puppetor/trunk/">PuppeTor</a>
devrait être un bon départ pour commencer un réseau privé Tor, l'utiliser 
quelques temps, et verifier qu'au moins quelques parties fonctionnent. Ce
projet nécessite de concevoir un plan pour effectuer les tests système
du réseau privé Tor, avant de commencer à coder. Les tests typiques
vont de la simple requête dans le réseau privé à la
manipulation des messages echangés et 
voir si les nœuds peuvent correctement prendre en compte les messages corrompus.
L'étudiant devrait pouvoir obtenir une bonne comprehension de 
comment Tor fonctionne et quels problèmes ou bugs peuvent survenir pour concevoir de bons
bancs de tests. Comprendre le code Tor et la documentation existante est
vital. Si PuppeTor est utilisé, l'étudiant devrait aussi être en mesure de comprendre
et éventuellement étendre une application Java existante. Ce projet est en partie
de la conception et en partie du codage.
</li>
 	 
<li>
Donner vie à moniTor
 
Implémenter un outil <a href="http://www.ss64.com/bash/top.html">comme top</a>
d'administration pour les relais Tor. Le but de cet outil serait de
superviser un relais Tor local via son port de control et inclure des informations
système utiles de la machine. Lorsque l'outil tourne, il 
devrait dynamiquement se mettre à jour comme top le faire pour les processus Linux.
<a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">Ce
post sur or-dev</a> devrait être un point d'entré. L'étudiant devrait être familier
ou prêt à apprendre l'administration d'un relais Tor et sa configuration
à travers son port de control. Du fait qu'un prototype exist en Python
quelques connaissances en Python serait interessantes. Ce projet porte sur
l'identification des nécessités pour un tel outil et sur la conception d'une interface ;
et d'un autre coté nécessite beaucoup de codage.
</li>
 	 
<li>
Amélioration du scanneur des sorties Tor
 
Priorité : élevée
 
Niveau d'effort : élevé
 
Mentors supposés : Mike Perry
 	 
 
Le scanner des nœuds de sortie Tor 'SoaT', partie du <a
 	 href="https://www.torproject.org/svn/torflow/">projet Torflow</a>, est
 	 pour l'instant écrit dans un perl plutôt bancal et s'appuie sur des MD5sums de
 	 documents entier dans le but de savoir si un nœud de sortie modifie des contenusin order to determine if exit nodes are modifying
 	 content. The problem with this is threefold: 1) Perl sucks at life.
 	 2) The scanner can't verify pages that are dynamic, and attackers can
 	 focus malicious content injection on only those dynamic pages. 3)
 	 Pages change after a while (or based on GeoIP) and begin generating
 	 false positives.
 	 
 	 Ideally, soat.pl would be reimplemented in a sane language with a
 	 robust html parser library (since the rest of Torflow is in Python,
 	 that would be nice, but not required), and calculate signatures only for
 	 tags and content likely to be targeted by a malicious attacker (script
 	 tags, object links, images). It should also be robust in the face of
 	 changes to content outside of Tor, and ultimately even GeoIP localized
 	 content.
 	 
 	 This scanner would likely be run by the directory authorities and
 	 report its results to the control port via the AuthDirBadExit config
 	 setting.
 	 
 	 </li>
 	 <li>
 	 Tor Node Scanner Improvements
 	 
 	 Priority: High
 	 
 	 Effort Level: Medium-High
 	 
 	 Likely Mentors: Mike Perry
 	 
 	 Similar to the exit scanner (or perhaps even during exit scanning),
 	 statistics can be gathered about the reliability of nodes. Nodes that
 	 fail a certain percentage of their circuits should not be used for
 	 Guard status, and perhaps should have their reported bandwidth
 	 penalized by some ratio as well, or just get marked as Invalid. In
 	 addition, nodes that exhibit a very low average stream capacity but
 	 advertise a very high node bandwidth can also be marked as Invalid.
 	 Much of this statistics gathering is already done, it just needs to be
 	 transformed into something that can be reported to the Directory
 	 Authorities to blacklist/penalize nodes in such a way that clients
 	 will listen.
 	 
 	 In addition, these same statistics can be gathered about the traffic
 	 through a node. Events can be added to the <a
 	 href="https://www.torproject.org/svn/torctl/doc/howto.txt">Tor Control
 	 Protocol</a> to
 	 report if a circuit extend through the node succeeds or fails, and
 	 passive statistics can be gathered on both bandwidth and reliability
 	 of other nodes via a node-based monitor using these events. Such a
 	 scanner which would also report information on oddly-behaving nodes to
 	 the Directory Authorities, but a communication channel for this
 	 currently does not exist and would need to be developed as well.
 	 </li>
 	 <li>
 	 Tor path selection improvements
 	 
 	 Priority: High
 	 
 	 Effort Level: Low-Medium
 	 
 	 Likely Mentors: Mike Perry
 	 
 	 Some simple improvements can be made to Tor's path selection to vastly
 	 improve Tor speed. For instance, some of the (unofficial) <a
 	 href="http://wiki.noreply.org/noreply/TheOnionRouter/FireFoxTorPerf">Tor
 	 Performance Recommendations</a> on the wiki are to increase the number of
 	 guards and decrease the CircuitBuildTimeout. Ideally, the client would
 	 learn these values by gathering statistics on circuit construction
 	 time (and/or using values gained from Torflow), and set the timeouts
 	 low enough such that some high percentile (75%, 90%, 1-stddev?) of
 	 circuits succeed, yet extremely slow nodes are avoided. This would
 	 involve some statistics gathering+basic research, and some changes to
 	 Tor path selection code.
 	 
 	 
 	 In addition, to improve path security, some elements from the <a
 	 href="http://www.torproject.org/svn/trunk/doc/spec/proposals/115-two-hop-paths.txt">Two
 	 Hop Paths proposal</a> could be done as part of this (since it will
 	 likely touch the same code anyways), regardless of the adoption of
 	 thatproposal. In particular, clients probably should avoid guards thatseem to
 	 fail an excessive percentage of their circuits through them, and non-bridged
 	 clients should issue a warn if they are only able toconnect to a limited set
 	 of guard nodes.
 	 
 	 </li>
 	 <li>
 	 Torbutton improvements
 	 
 	 Priority: Low
 	 
 	 Effort Level: Medium-High
 	 
 	 Likely Mentors: Mike Perry
 	 
 	 
 	 Torbutton has a number of improvements that can be made in the post-1.2
 	 timeframe. Most of these are documented as feature requests in the <a
 	 href="https://bugs.torproject.org/flyspray/index.php?tasks=all&project=5">Torbutton
 	 flyspray section</a>. Good examples include: stripping off node.exit on http
 	 headers, more fine-grained control over formfill blocking, improved referrer
 	 spoofing based on the domain of the site (a-la refspoof extension), tighter
 	 integration with Vidalia for reporting Tor status, a New Identity button with
 	 Tor integration and multiple identity management, and anything else you might
 	 think of.
 	 
 	 
 	 
 	 This work would be independent coding in Javascript and the fun world of <a
 	 href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
 	 with not too much involvement in the Tor internals.
 	 
 	 </li>
 	 <li>
 	 Help track the overall Tor Network status
 	 Torstatus. Set up an automated system for tracking network health
 	 over time, graphing it, etc. Better metrics for assessing network
 	 health and growth. Make it short and simple. Unbloated and easy to audit.
 	 </li>
 	 
 	 <li>vidalia and upnp</li>
 	 <li>nymble</li>
 	 
 	 <li>
 	 Porting Polipo to Windows
 	 
 	 Help port <a
 	 href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to
 	 Windows. 1) handle spaces in path names and understand the filesystem
 	 namespace &mdash; namespace meaning where application data, personal data,
 	 and program data typically reside in various versions of Windows. 2) the
 	 ability to handle ipv6 communications. 3) the ability to asynchronously
 	 query name servers, find the system nameservers, and manage netbios
 	 and dns queries. 4) use native regex capabilities of Windows, rather
 	 than using 3rd party GNU regex libraries. 5) manage events and buffers
 	 natively (i.e. in Unix-like OSes, Polipo defaults to 25% of ram, in
 	 Windows it's whatever the config specifies). 6) some sort of GUI config
 	 and reporting tool, bonus if it has a systray icon with right clickable
 	 menu options. Double bonus if it's cross-platform compatible.
 	 </li>
 	 
 	 <li>
 	 Make our diagrams beautiful and automated
 	 
 	 a way to generate the website diagrams from source, so we can translate
 	 them as utf-8 text rather than with gimp. (svg? or imagemagick?)
 	 integrate this with a wml file so translations are easy and images are
 	 generated in multiple languages at web publish
 	 </li>
 	 
 	 <li>
 	 Improve the LiveCD offerings for the Tor community
 	 
 	 How can we make the <a
 	 href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
 	 easier to maintain, improve, and document?</li>
 	 <li>We need a distributed testing framework. We have unit tests,
 	 but it would be great to have a script that starts up a Tor network, uses
 	 it for a while, and verifies that at least parts of it are working.</li>
 	 
 	 <li>
 	 Bring up new ideas!
 	 
 	 Don't like any of these? Look at the <a
 	 href="<svnsandbox>doc/design-paper/roadmap-future.pdf">Tor development
 	 roadmap</a> for more ideas. 
 	 Don't see your idea here? We probably need it anyway! Contact
 	 us and find out.</li>
 	 </ol>
<h2><a class="anchor" href="#Coding">Conception et Code</a></h2>
<ol>
<li>Les serveurs de Tor ne fonctionnent pas parfaitement sur Windows XP. Sur
Windows, Tor utilise l'appel système standard <tt>select()</tt>, 
qui utilise l'espace non paginé dans le pool. Ce qui implique 
que les serveurs de taille moyenne vont vider l'espace non paginé, <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">provocant 
l'instabilité et le plantage du système</a>. Nous devrions probablement utiliser des E/S recouvrables 
à la place. Une solution pourrait-être d'apprendre à la <a
href="http://www.monkey.org/~provos/libevent/">libevent</a> comment utiliser 
les E/S recouvrables à la place de select() sous Windows, et alors d'adapter Tor à 
la nouvelle interface libevent.</li> Christian King à 
<a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">bien
démarré</a> sur ce point l'été dernier.</li>
<li>Comment pouvons nous faire en sorte que <a
href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
soit plus simple à maintenir, étendre, et à documenter ?</li>
<li>Notre interface graphique préférée pour Tor, nommée
<a href="http://vidalia-project.net/">Vidalia</a>, nécessite toutes sortes 
de dévelopments.</li>
<li>Nous avons besoin maintenant de commencer l'élaboration de notre <a href="<page
documentation>#DesignDoc">conception de résistance au blocage</a>. Ceci implique 
une refonte de la conception, une modification de différents aspects de Tor, une adaptation de
<a href="http://vidalia-project.net/">Vidalia</a> pour qu'il supporte les nouvelles
fonctionnalités, et planifier le deploiement.</li>
<li>Nous avons besoin d'un ensemble d'outils flexibles de simulation pour étudier de bout en bout
les trafics de confirmation d'attaque. Beaucoups de chercheurs ont conçu des simulateurs ad hoc
pour confirmer leurs intuitions comme quoi soit l'attaque marche 
vraiment bien ou que les défenses fonctionnent. Pouvons nous construire un simulateur
qui soit clairement documenté et suffisament ouvert pour que tout le monde sache qu'il
donne une réponse raisonnable ? Ceci stimulera un grand nombre de nouvelles recherches.
Voyez l'entrée <a href="#Research">suivante</a> sur les confirmations d'attaque pour les 
détails sur le coté recherche de cette tâche &mdash; qui sait, quand ceci sera 
fait peut-être pouvez aider en écrivant un papier ou deux.</li>
<li>Nous avons besoin d'un banc de test distribué. Nous avons des unités de tests,
mais il serait sympa d'avoir un script qui lance un réseau Tor, 
l'utilise quelque temps, et vérifie que, au moins, quelques aspects fonctionnent.</li>
<li>Aidez Mike Perry sur sa bibliothèque <a
href="https://www.torproject.org/svn/torflow/">TorFlow</a> (<a href="https://www.torproject.org/svn/torflow/TODO">TODO</a>):
c'est une bibliothèque python qui utilise le <a
href="https://www.torproject.org/svn/torctl/doc/howto.txt">protocole du contrôleur Tor
</a> pour apprendre à Tor à construire des circuits de différentes manières,
et ensuite mesure les performances et essaye de détecter les anomalies.</li>
<li>Tor 0.1.1.x inclut le support d'accélérateurs matériels de chiffrage 
via OpenSSL. Cependant, personne ne l'a jamais testé. Est-ce que quelqu'un voudrait se procurer 
une carte et nous dire ce qu'il en est ?</li>
<li>Faire une analyse de sureté de Tor avec <a
href="http://en.wikipedia.org/wiki/Fuzz_testing">du "fuzz"</a>. Déterminer 
s'il existe déjà de bonnes bibliothèques de fuzz pour ce que nous voulons faire. La célébrité pour celui-lle 
grâce à qui une nouvelle version pourra voir le jour !</li>
<li>Tor utilise TCP pour le transport et TLS pour le chiffrage 
des liens. C'est simple et efficace, mais cela implique que toutes les unités (cellules) 
d'un lien sont mises en attente lorsqu'un seul paquet est perdu, et 
cela signifie que seuls des flux TCP peuvent être raisonnablement supportés. Nous avons dressé une <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP"> liste 
de raisons pour lesquelles nous n'avons pas bifurqué vers le transport par UDP</a>, mais ce serait 
bien de voir cette liste se raccourcir. Nous avons aussi proposé <a 
href="<svnsandbox>tor/doc/100-tor-spec-udp.txt">une spécification pour Tor et 
UDP</a> &mdash; lisez-la et faites-nous part de vos remarques et critiques, s'il-vous-plaît.</li>
<li>Nous ne sommes plus très loin d'avoir le support pour IPV6 entre les serveurs de sorties 
et les adresses finales. Si IPV6 vous tient à cœur, partir de là est sans doute 
un premier pas.</li>
<li>Quelque chose vous déplait ? Regardez la <a
href="<svnsandbox>doc/design-paper/roadmap-future.pdf">planification du développement
de Tor</a> pour plus d'idées.</li>
<li>Vous ne voyez pas vos idées ici ? Nous en avons peut-être besoin ! Contactez
nous et aidez.</li>
</ol>

<a id="Research"></a>
<h2><a class="anchor" href="#Research">Recherche</a></h2>
<ol>
<li>"L'attaque par empreinte de sites": faire une liste de quelques 
centaines de sites populaires, en télécharger les pages, et faire des 
"signatures" pour chaque site. Ensuite, observer le trafic d'un client Tor. 
L'analyse de ses réceptions de données donne rapidement une idée 
des sites qu'il visite. Premièrement, quelle est l'efficacité 
de cette attaque sur le code actuellement utilisé dans Tor ? Ensuite, tester 
les défenses possibles : par exemple, changer la taille des cellules de Tor de 512 
octets à 1024, utiliser des techniques de remplissage comme <a
href="http://freehaven.net/anonbib/#timing-fc2004">le lâcher défensif</a>, 
ou ajouter des délais de trafic. Quel impact ces stratégies de défense ont-elles, 
et, dans les cas où elles sont efficaces en défense, quel impact ont-elles 
en terme de perte d'utilisabilité de Tor (à quantifier) ?</li>
<li>"L'attaque par corrélation des trafics aux extrémités": 
par l'observation des trafics de Alice et Bob, il est possible de <a
href="http://freehaven.net/anonbib/#danezis:pet2004">comparer 
les signatures des trafics et d'en déduire qu'il s'agit du même 
flux</a>. Jusqu'ici, Tor considère ce type d'attaque comme intrinsèque 
et donc inévitable. Tout d'abord, est-ce réellement vrai ? Quelle 
quantité de trafic - et avec quelle distribution - est-elle nécessaire pour que l'adversaire 
soit certain d'avoir gagné ? Est-ce qu'il existe des scénarios (par exemple avoir un trafic faible) 
pour ralentir cette attaque ? Est-ce que certains types de remplissage ou de modelage de trafic
fonctionnent mieux que d'autres ?</li>
<li>"L'attaque par zones de routage" : la littérature spécialisée considère 
le plus souvent que le chemin réseau entre Alice et son noeud d'entrée (et entre le noeud de sortie 
et Bob) comme un lien unique dans un graphe. En pratique, 
cependant, le chemin passe par de nombreux systèmes autonomes (Autonomous Systems : ASes), et <a
href="http://freehaven.net/anonbib/#feamster:wpes2004">il n'est pas inhabituel 
de retrouver le même AS sur les chemins d'entrée et de sortie</a>.
Malheureusement, pour prévoir précisément si le chemin "Alice, entrée, 
sortie, Bob" sera dangereux, nous devrions télécharger une zone de routage 
internet complète et faire dessus des calculs lourds. Est-ce qu'il existe 
des approximations utilisables, comme par exemple d'ignorer les adresses IP d'un réseau /8 ?</li>
<li>D'autres questions de recherche concernant la diversité géographique considèrent 
la différence entre choisir un circuit efficace et en choisir un aléatoire.
Lisez l' <a
href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">argumentation
</a> de Stephen Rollyson sur comment eviter les nœuds lents sans trop impacter
l'anonymat. Cet axe de raisonnement nécessite davantage de travail et de 
réflexion, mais semble très prometteur.</li>
<li>Tor ne fonctionne pas très bien lorsque les serveurs ont des bandes passantes 
asymétriques (par exemple câble ou DSL). Comme Tor a des connexions TCP séparées entre 
chaque saut, si les octets arrivent correctement mais que les octets sortants 
sont bloqués sur place, les mécanismes de refoulement de TCP 
ne retransmettent pas vraiment cette information aux flux entrants.
Peut-être Tor devrait-il détecter s'il perd beaucoup de paquets sortants, 
et limiter la vitesse du flux entrant pour réguler cela lui-même ? Je peux concevoir 
un schéma de type augmentation-descente dans lequel on choisit un débit "sûr", 
que l'on augmente jusqu'à perdre des paquets, puis qui redescend, puis qui réaugmente. Nous 
avons besoin de quelq'un-e de fort-e en réseau pour simuler ce fonctionnement et aider à concevoir 
des solutions. De manière générale, l'évaluation des pertes de performances 
d'un tel système pourrait peut-être - dans le cas où elles sont grandes - 
servir de motivation pour reconsidérer la question du transport UDP.
<li>Un sujet lié est le contrôle de congestion : notre système 
actuel est-il suffisant pour un usage intensif ? Peut-être 
devrions-nous expérimenter des fenêtres de taille variable 
plutôt qu'à taille fixe ? C'est apparu assez efficace pour cette <a
href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">expérience 
sur ssh</a>. Nous aurons à faire des mesures et des réglages, et peut-être 
une révision de Tor si les résulats sont bons.</li>
<li>Pour permettre à des dissident-e-s de se connecter sans être bloqué-e-s 
par les pare-feu de leur pays, nous avons besoin de dizaines de milliers de 
relais et pas seulement de quelques centaines. Nous pourrions imaginer un client Tor graphique qui 
aurait un bouton "Tor pour la liberté" pour activer l'ouverture d'un port et le relais 
de quelques KB/s de trafic pour le réseau Tor. (Quelques KB/s ne devraient pas être trop 
pénibles et il y a peu de risque d'abus puisqu'il ne s'agirait pas de noeuds de 
sortie.) Mais comment distribuer la liste de ces clients volontaires aux 
bons dissidents de manière automatique, tout en ne permettant pas aux 
pare-feux au niveau national de l'intercepter et de lister ces clients ? Probablement, il faut faire 
intervenir la confiance, au niveau humain. Voir notre <a href="<page documentation>#DesignDoc">document 
préliminaire sur la résistance au blocage</a> et notre 
<a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#BlockingResistance">entrée 
dans la FAQ</a> à ce sujet, puis lire <a 
href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">la section 
sur la résistance à la censure de anonbib</a>.</li>
<li>Les circuits Tor sont construits saut par saut, donc en théorie nous pouvons 
faire sortir des flux au second saut, au 
troisième, etc. Cela paraît bien car cassant l'ensemble des flux sortants 
qu'un serveur peut voir. Mais si nous voulons que chaque flux soit sûr, 
le chemin "le plus court" devrait comporter au moins 3 sauts dans notre logique actuelle, et 
les sorties suivantes seraient encore plus lointaines. Nous devons évaluer ce rapport 
performance/sûreté.</li>
<li>Il n'est pas difficile de provoquer un DoS sur les serveurs et les serveurs de répertoires Tor. Est-ce 
que les puzzles de clients sont la bonne réponse ? Existe-t-il d'autres approches réalisables ? Il y a un bonus 
si elles sont rétro-compatibles avec le protocol actuel de Tor.</li>
</ol>

<a href="<page contact>">Contactez-nous</a> si vous avez avancé sur 
ces points !

</div>

#include <foot.wmi>

tor-webwml.git

update fr/volunteer.wml