tor-webwml.git

@@ -73,7 +73,7 @@ security</a>.</p>

 <hr />

 <ul>

-<li>12 March 2009:  Tor launches performance roadmap and campaign.  Read the <a href="<page press/2009-03-12-performance-roadmap-press-release>">Press Release</a> for more information</a>.</li>

+<li>12 March 2009:  Tor launches performance roadmap and campaign.  Read the <a href="<page press/2009-03-12-performance-roadmap-press-release>">Press Release</a> for more information.</li>

 <li>09 February 2009:  Tor 0.2.0.34 released as stable.  Read the <a

 href="http://archives.seul.org/or/announce/Feb-2009/msg00000.html">announcement</a>

 for the updates and changes.  This release fixes a security issue.</li>

@@ -1,5 +1,5 @@

 ## translation metadata

-# Based-On-Revision: 18926

+# Based-On-Revision: 18961

 # Translation-Priority: 4-optional

 # Last-Translator: bogdandr_at_op . pl

@@ -74,7 +74,7 @@ stawia wiele otwartych pytań i interesujących problemów na polu

 W tym roku mamy dwie listy pomysłów: jedna dla projektów mogących

 <a href="<page volunteer>#Projects">pomóc w rozwoju Tora</a>,

 a druga dla projektów mogących pomóc w rozwoju

-<a href="http://www.eff.org/testyourisp/switzerland">szwajcarskiego narzędzia

+<a href="http://switzerland.wiki.sourceforge.net/Projects">szwajcarskiego narzędzia

 EFF</a>. </p>

@@ -1,5 +1,5 @@

 ## translation metadata

-# Based-On-Revision: 18763

+# Based-On-Revision: 18950

 # Translation-Priority: 1-high

 # Last-Translator: bogdandr_at_op . pl, gooseondaloose /at- msn.com, laszpio -at$ gmail.com

@@ -82,6 +82,9 @@ złożenie <a href="<page donate>">dotacji, którą można odpisać od podatku.<

 <hr />

 <ul>

+<li>12 Marca 2009: Tor wydaje kampanię i plan rozwoju wydajności. Przeczytaj

+<a href="<page press/2009-03-12-performance-roadmap-press-release>">ogłoszenie prasowe</a>,

+by poznać szczegóły.</li>

 <li>09 Lutego 2009:  Tor 0.2.0.34 wydany jako wersja stabilna.  Przeczytaj <a

 href="http://archives.seul.org/or/announce/Feb-2009/msg00000.html">ogłoszenie</a>

 by dowiedieć się o zmianach i aktualizacjach. To wydanie naprawia problem bezpieczeństwa.</li>

@@ -1,5 +1,5 @@

 ## translation metadata

-# Based-On-Revision: 18925

+# Based-On-Revision: 18944

 # Translation-Priority: 4-optional

 # Last-Translator: bogdandr_at_op . pl

@@ -117,34 +117,50 @@ daje najlepsze programy.

 <ol>

-<!-- Mike is already working on this.

 <li>

-<b>Ulepszenie Skanera Węzłów Tora (Tor Node Scanner)</b>

+<b>Paczka Tora z Przeglądarką dla Linux/Mac OS X</b>

 <br />

-Podobnie do skanera wyjściowego SoaT (lub może nawet w czasie jego działania),

-można gromadzić statystyki odnośnie wiarygodności węzłów. Te węzły, które

-źle działają dla pewnej części swoich obwodów nie powinny być używane do

-statusu Strażnika, i być może powinny też mieć zmniejszoną swoją zgłaszaną

-przepustowość, lub po prostu być oznaczane jako Nieważne. Dodatkowo,

-węzły wykazujące bardzo niską średnią przepustowość strumienia,

-lecz zgłaszają bardzo wysoką, też mogą być oznaczone jako Nieważne.

-Większość zbierania statystyk już jest zrobiona, dane te muszą tylko

-zostać przetworzone na coś, co może być wysłane Serwerom Katalogowym,

-by ukarały/wyłączyły ze swoich list te węzły w taki sposób, że klienci

-się o tym dowiedzą.

+Priorytet: <i>Wysoki</i>

 <br />

-Dodatkowo, te same statystyki mogą być zbierane odnośnie ruchu przechodzącego

-przez węzeł. Do <a

-href="https://svn.torproject.org/svn/torctl/trunk/doc/howto.txt">Protokołu Kontroli

-Tora</a> można dodać zdarzenia mówiące, czy udaje się stworzyć obwód

-przechodzący przez ten węzeł, oraz można zbierać pasywne statystyki dotyczące

-zarówno przepustowości, jak i wiarygodności innych węzłów, poprzez oparty

-na węzłach program monitorujący takie zdarzenia. Taki skaner zgłaszałby też

-informacje o dziwnie zachowujących się węzłach do Serwerów Katalogowych,

-ale kanał łączności do tych celów jeszcze nie istnieje i też musiałby

-zostać stworzony.

+Poziom wysiłku: <i>Wysoki</i>

+<br />

+Poziom umiejętności: <i>Średni</i>

+<br />

+Prawdopodobni opiekunowie: <i>Steven</i>

+<br />

+Paczka Tora z Przeglądarką zawiera Tora, Firefoksa i interfejs użytkownika - Vidalię

+(i opcjonalnie komunikator Pidgin). Komponenty te są prekonfigurowane do bezpiecznego

+działania, a paczka ma małe wymagania co do systemu operacyjnego. Stała się więc

+jednym z najprostszych i najbardziej popularnych sposobów używania Tora na Windows.

+<br />

+Nie ma jednak w chwili obecnej porównywalnej paczki dla Linuksa i Mac OS X, więc celem

+tego projektu byłaby implementacja Paczki Tora z Przeglądarką dla tych systemów.

+Będzie to pociągało zmiany w Vidalii (C++), być może w Firefoksie (C), po czym stworzenie

+i testowanie programu uruchamiającego na różnych wersjach i konfiguracjach systemów operacyjnych,

+by sprawdzić przenośność.

+<br />

+Studenci powinni być zaznajomieni z rozwojem aplikacji na jednym, lub najlepiej obu,

+Linuksie i Mac OS X oraz czuć się swobodnie z C/C++ i pisaniem skryptów powłoki.

+</li>

+

+<li>

+<b>Wiki do tłumaczeń dla naszej strony</b>

+<br />

+Priorytet: <i>Wysoki</i>

+<br />

+Poziom wysiłku: <i>Średni</i>

+<br />

+Poziom umiejętności: <i>Średni</i>

+<br />

+Prawdopodobni opiekunowie: <i>Jacob</i>

+<br />

+Projekt Tor pracował w ciągu ostatniego roku nad uruchomieniem opartych na sieci narzędzi,

+by pomóc ochotnikom w tłumaczeniu naszych aplikacji na inne języki.

+W końcu stanęliśmy na Pootle i mamy dobry mechanizm sieciowy do tłumaczeń dla programów

+Vidalia, Torbutton i Torcheck. Ale Pootle tłumaczy tylko napisy w formacie "po", a

+nasza strona korzysta z plików wml. Celem tego projektu jest znalezienie sposobu na

+konwersję naszych plików wml na pliki "po" i z powrotem, by mogły być obsługiwane przez Pootle.

 </li>

--->

 <li>

 <b>Pomóż śledzić ogólny status Sieci Tora</b>

@@ -155,7 +171,7 @@ Poziom wysiłku: <i>Średni</i>

 <br />

 Poziom umiejętności: <i>Średni</i>

 <br />

-Prawdopodobni opiekunowie: <i>Karsten</i>

+Prawdopodobni opiekunowie: <i>Karsten, Roger</i>

 <br />

 Byłoby wspaniale uruchomić automatyczny system śledzenia stanu sieci w czasie,

 wyświetlanie wykresów itp. Częścią tego projektu byłoby wynalezienie lepszych

@@ -175,59 +191,16 @@ Skoro mówimy o stronach stanu Tora, spójrzcie na

 stanu Tora</a> napisaną przez Rogera.

 </li>

-<!-- Is this still a useful project? If so, move it to another section.

-<li>

-<b>Lepsze wsparcie i pakowanie dla Debiana/Ubuntu</b>

-<br />

-Vidalia obecnie nie współpracuje dobrze na Debianie i Ubuntu z domyślnymi

-paczkami Tora. Bieżące paczki Tora automatycznie uruchamiają Tora jako demona

-systemowego z konta użytkownika debian-tor i (rozsądnie) nie mają zdefiniowanego

-ControlPort w domyślnym torrc. Stąd Vidalia będzie próbować uruchomić własny

-proces Tora, bo nie może połączyć się z istniejącym, po czym proces Tora

-uruchomiony przez Vidalię zamknie się z błędem, którego użytkownik raczej nie zrozumie,

-jako że Tor nie będzie mógł podpiąć się pod swoje porty nasłuchowe, które są

-już zajęte przez pierwszy proces Tora.

-<br />

-Bieżące rozwiązanie to albo mówienie użytkownikowi, by zatrzymał istniejący

-proces Tora i pozwolił Vidalii uruchomić własny, albo tłumaczenie, jak ustawić

-port kontrolny i hasło w pliku torrc. Lepszym rozwiązaniem na Debianie byłoby używanie

-ControlSocket Tora, który umożliwia Vidalii komunikowanie się z Torem poprzez

-gniazdo w domenie Unix i mógłby być domyślnie włączony w paczkach Tora dla Debiana.

-Vidalia może wtedy uwierzytelnić się do Tora używając ciasteczek, jeśli użytkownik

-uruchamiający Vidalię jest w grupie debian-tor.

-<br />

-Pierwsza część tego projektu będzie polegała na dodaniu obsługi ControlSocket

-do Vidalii. Potem student stworzy i przetestuje paczki Vidalii na Debianie i

-Ubuntu, które będą zgodne ze standardami pakowania w Debianie, oraz upewni się,

-że działają dobrze z istniejącymi paczkami Tora. Możemy też stworzyć repozytorium

-apt zawierające nowe paczki Vidalia.

-<br />

-Kolejnym wyzwaniem byłoby znalezienie intuicyjnego sposobu, by Vidalia mogła

-zmienić konfigurację Tora (torrc) mimo iż ta jest w <code>/etc/tor/torrc</code>,

-a więc nienaruszalna. Najlepszy jak dotąd pomysł, na jaki wpadliśmy, to

-przekazanie Torowi nowej konfiguracji poprzez ControlSocket w czasie uruchamiania

-Vidalii, ale jest to zły pomysł, gdyż Tor za każdym razem uruchamia się z inną

-konfiguracją niż użytkownik by tego chciał. Drugi najlepszy pomysł jest taki, by

-Vidalia stworzyła tymczasowy plik konfiguracyjny i poprosiła użytkownika, by

-ręcznie przeniósł go do <code>/etc/tor/torrc</code>, ale to jest zły pomysł, gdyż

-użytkownicy nie powinni być zmuszani do bezpośredniego zajmowania się plikami.

-<br />

-Osoba podejmująca się tego projektu powinna znać system pakowania Debiana i

-mieć trochę doświadczenia z C++. Uprzednie doświadczenie z Qt będzie przydatne,

-ale nie jest wymagane.

-</li>

--->

-

 <li>

 <b>Polepszanie naszych zdolności opierania się cenzurze</b>

 <br />

-Priorytet: <i>Wysoki</i>

+Priorytet: <i>Średni do wysokiego</i>

 <br />

-Poziom wysiłku: <i>Wysoki</i>

+Poziom wysiłku: <i>Średni</i>

 <br />

 Poziom umiejętności: <i>Wysoki</i>

 <br />

-Prawdopodobni opiekunowie: <i>Nick</i>

+Prawdopodobni opiekunowie: <i>Nick, Roger, Steven</i>

 <br />

 Wersje 0.2.0.x Tora robią <a

 href="<svnsandbox>doc/design-paper/blocking.html">znaczne postępy</a> w opieraniu

@@ -253,66 +226,80 @@ się atakom nawet po tym, jak atakujący pozna projekt, po czym równoważenie

 odporności na cenzurę z użytecznością i siłą.

 </li>

-<!-- This should be mostly done.

 <li>

-<b>Framework automatycznej aktualizacji programów Tor/Polipo/Vidalia.</b>

+<b>Tuneup Tor!</b>

 <br />

-Potrzebujemy dobrego frameworka automatycznej aktualizacji.

-Vidalia już ma możliwość informowania, że użytkownik używa przestarzałej lub

-niezalecanej wersji Tora. W chwili obecnej Vidalia po prostu pokazuje małe

-okienko, które informuje użytkownika, że powinien dokonać ręcznej aktualizacji.

-Celem tego projektu jest rozszerzenie Vidalii o możliwość pobrania i

-zaktualizowania nowej wersji Tora za użytkownika. Jeśli czas pozwoli,

-chcielibyśmy móc aktualizować też inne aplikacje z paczek, jak Polipo czy

-Vidalia.

+Priorytet: <i>Średni</i>

 <br />

-By wykonać ten projekt, student będzie musiał najpierw poznać istniejące

-mechanizmy aktualizacji (np. Sparkle na OS X), by zbadać ich mocne i słabe punkty,

-cechy bezpieczeństwa i możliwości zintegrowania z Vidalią. Jeśli żaden nie okaże

-się przydatny, student zaprojektuje własny framework aktualizacyjny,

-udokumentuje projekt i przedyskutuje go z innymi deweloperami na temat

-jego bezpieczeństwa. Potem zaimplementuje go (lub zintegruje istniejący)

-i przetestuje.

+Poziom wysiłku: <i>Średni</i>

 <br />

-Osoba podejmująca się tego projektu powinna dobrze znać C++.

-Uprzednie doświadczenie z Qt będzie przydatne, ale nie jest wymagane.

-Powinno się mieć też podstawowe pojęcie o powszechnych praktykach

-bezpieczeństwa, jak weryfikacja podpisu paczki. Dobre zdolności w

-pisaniu też są ważne w tym projekcie, gdyż ważnym krokiem będzie

-zrobienie dokumentacji projektu do przejrzenia i przedyskutowania

-z innymi ludźmi przed implementacją.

+Poziom umiejętności: <i>Średni do wysokiego</i>

+<br />

+Prawdopodobni opiekunowie: <i>Nick, Roger, Mike</i>

+<br />

+W chwili obecnej węzły Tora mierzą i zgłaszają własną przepustowość łącza,

+a klienci Tora wybierają, których węzłów używać po części opierając się

+na tej zgłaszanej przepustowości. To podejście jest podatne na

+<a href="http://freehaven.net/anonbib/#bauer:wpes2007">ataki, w których węzły oszukują

+na temat przepustowości swoich łączy</a>; by to zmienić, Tor aktualnie ogranicza

+maksymalną przepustowość każdego węzła, w którą jest w stanie uwierzyć. To jest

+ograniczone rozwiązanie i marnotrawienie przepustowości. Zamiast tego,

+Tor powinien w miarę możliwości mierzyć przepustowość łączą w rozproszony sposób,

+jak jest napisane w dokumencie

+<a href="http://freehaven.net/anonbib/author.html#snader08">"A Tuneup for Tor"</a> autorstwa

+Snadera i Borisova. Można byłoby użyć bieżącego kodu testującego, by sprawdzić

+odkrycia napisane w tym dokumencie i zweryfikować, w jakim stopniu opisują one

+normalnie działającego Tora i określić dobre sposoby na wcielenie tych odkryć

+do sieci Tora bez dodawania niepożądanego ruchu wielkości między węzłami a serwerami

+katalogowymi.

 </li>

--->

 <li>

-<b>Poprawiona i bardziej użyteczna mapa sieci w programie Vidalia</b>

+<b>Ulepszenie Polipo na Windows</b>

 <br />

 Priorytet: <i>Średni</i>

 <br />

-Poziom wysiłku: <i>Średni</i>

+Poziom wysiłku: <i>Niski</i>

 <br />

 Poziom umiejętności: <i>Średni</i>

 <br />

-Prawdopodobni opiekunowie: <i>Matt</i>

+Prawdopodobni opiekunowie: <i>Martin</i>

 <br />

-Jedną z istniejących cech Vidalii jest mapa sieci, która pokazuje użytkownikowi

-przybliżone lokalizacje geograficzne przekaźników sieci Tora i rysuje

-ścieżki, przez które przechodzi ruch użytkownika w sieci Tora.

-Mapa jest w tej chwili niezbyt interaktywna i ma raczej słabą grafikę.

-Zamiast tego, zaimplementowaliśmy widget Marble z KDE, który daje mapę lepszej jakości i

-umożliwia lepszą interaktywność, jak na przykład pozwalanie użytkownikowi na

-klikanie w poszczególne przekaźniki lub obwody, by wyświetlić dodatkowe

-informacje. Chcemy też dodaće możliwość klikania przez

-użytkownika na dany przekaźnik lub kraj z co najmniej jednym przekaźnikiem i

-stwierdzenia "chcę, by moje połączenia do wychodziły stąd."

+Pomóż przenieść <a

+href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> na Windows.

+1) zdolność do asynchronicznego wysyłania zapytań do

+serwerów nazw. 2) natywna obsługa zdarzeń i buforów (tj. w

+systemach uniksopodobnych Polipo domyślnie używa 25% pamięci RAM, a pod Windows

+jest to cokolwiek wpisane w plik konfiguracyjny). 3) jakieś narzędzie z

+graficznym interfejsem do konfiguracji i raportowania, dodatkowe punkty, jeśli

+ma ikonkę w zasobniku z opcjami menu po kliknięciu prawym przyciskiem myszy.

+Podwójny bonus, jeśli działa na wielu platformach.

+4) umożliwienie programowi używania rejestru Windowsa i obsługiwania prawidłowych

+ścieżek w Windowsie, np. "C:\Program Files\Polipo".

+</li>

+

+<li>

+<b>Zaimplementowanie opartego na torrencie sposobu pobierania paczek Thandy</b>

 <br />

-Podczas tego projektu, osoba najpierw zapozna się z Vidalią i API widgetu

-Marble. Potem zintegruje widget z Vidalią i zmieni go, by bardziej pasował

-do naszych zastosowań, np. można było klikać w obwody, zapisywać mapy we

-własnym katalogu Vidalii i dostosować część okien dialogowych widgetu.

+Priorytet: <i>Średni</i>

 <br />

-Osoba podejmująca się tego projektu powinna dobrze znać C++.

-Uprzednie doświadczenie z Qt i CMake będzie przydatne, ale nie jest wymagane.

+Poziom wysiłku: <i>Wysoki</i>

+<br />

+Poziom umiejętności: <i>Średni do wysokiego</i>

+<br />

+Prawdopodobni opiekunowie: <i>Martin, Nick</i>

+<br />

+<a

+href="http://git.torproject.org/checkout/thandy/master/specs/thandy-spec.txt">Thandy</a>

+jest względnie nowym oprogramowaniem, które umożliwia wspomagane aktualizacje Tora i

+związanych z nim programów. W tej chwili użytkowników jest niewielu, ale oczekujemy, że

+Thandy będzie w przyszłości używane przez prawie każdego użytkownika Tora. By uniknąć

+padających serwerów w dniu aktualizacji Tora, potrzebujemy nowych sposobów na

+wydajną dystrybucję nowych paczek, a wykorzystanie libtorrent zdaje się być

+możliwym rozwiązaniem. Jeśli myślisz o innych dobrych pomysłach, to wspaniale

+- proszę dać nam znać!<br />

+Musimy też zbadać, jak lepiej dołączyć nasze mirrory. Jeśli to możliwe, powinien

+znaleźć się łatwy sposób na to, by łatwo pomogły w dystrybucji paczek.

 </li>

 <li>

@@ -322,7 +309,7 @@ Priorytet: <i>Średni</i>

 <br />

 Poziom wysiłku: <i>Średni</i>

 <br />

-Poziom umiejętności: <i>Średni</i>

+Poziom umiejętności: <i>Niski do średniego</i>

 <br />

 Prawdopodobni opiekunowie: <i>Matt</i>

 <br />

@@ -358,30 +345,376 @@ Dodatkowe punkty za jakiś projekt graficzny /Photoshop fu, gdyż moglibyśmy

 chcieć/potrzebować nowych ikonek.

 </li>

-<!-- Jake already did most of this.

+

 <li>

-<b>Ulepszenia naszego aktywnego testera konfiguracji przeglądarek</b> -

-<a href="https://check.torproject.org">https://check.torproject.org</a>

+<b>Polepszenie procesu testów jednostkowych</b>

 <br />

-Mamy w tej chwili funkcjonalną stronę www, która sprawdza, czy Tor działa.

-Ma jednak parę miejsc, w których działa źle. Wymaga ulepszeń dotyczących

-domyślnych języków i funkcjonalności. W chwili obecnej odpowiada tylko po angielsku.

-Ponadto, jest to kawał skryptu Perla, który nigdy nie powinien był ujrzeć światła

-dziennego. Strona powinna prawdopodobnie zostać przepisana w Pythonie

-z uwagą na wielojęzyczności. Teraz używa <a

-href="http://exitlist.torproject.org/">listy punktów wyjściowych Tor DNS</a>

-i powinna to robić w przyszłości. Może to dawać fałszywe pozytywne wyniki - te

-powinny zostać wykryte, udokumentowane i naprawione, gdzie to będzie możliwe.

-Ktokolwiek pracujący nad tym projektem powinien interesować się DNS,

-znać podstawy Perla lub lepiej - Pythona. Będzie musiał tylko minimalnie

-stykać się z Torem, by testować swój kod.

+Priorytet: <i>Średni</i>

 <br />

-Jeśli chcesz, by ten projekt był bardziej ekscytujący i zawierał więcej

-projektowania i programowania, przeczytaj <a

-href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">propozycję

-131-verify-tor-usage.txt</a>.

+Poziom wysiłku: <i>Średni</i>

+<br />

+Poziom umiejętności: <i>Średni</i>

+<br />

+Prawdopodobni opiekunowie: <i>Nick, Roger</i>

+<br />

+Tor musi zostać znaczniej bardziej przetestowany. To jest projekt wieloczęściowy.

+Na początek, nasze testy jednostkowe powinny znacznie się wzbogacić, zwłaszcza

+w obszarach poza funkcjami narzędziowymi. Będzie to wymagało poważnych zmian

+niektórych części Tora, aby oddzielić jak najwięcej programu od zmiennych

+globalnych.<br />

+Ponadto, musimy zautomatyzować nasze testy wydajności dla wszystkich systemów.

+Mamy już buildbota do automatyzacji naszej zwyczajnej integracji i kompilacji testów

+(ale potrzebujemy osoby do uruchomienia tego pod Windows), ale

+musimy zaktualizować nasze testy symulacji sieci (takie, jak w <a

+href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>)

+do nowszych wersji Tora i zaprojektować je tak, by uruchamiać sieci testowe

+albo na jednej maszynie, albo na kilku, abyśmy mogli automatycznie

+badać zmiany wydajności na maszynach pełniących różne zadania.

 </li>

--->

+

+<li>

+<b>Pomóż wznowić niezależną implementację klienta Tora</b>

+<br />

+Priorytet: <i>Średni</i>

+<br />

+Poziom wysiłku: <i>Wysoki</i>

+<br />

+Poziom umiejętności: <i>Średni do wysokiego</i>

+<br />

+Prawdopodobni opiekunowie: <i>Karsten, Nick</i>

+<br />

+Reanimuj jedno z podejść do implementacji klienta Tora w Javie, np.

+<a href="http://onioncoffee.sourceforge.net/">projekt OnionCoffee</a>

+i spraw, by działał pod <a href="http://code.google.com/android/">Androidem</a>.

+Pierwszym krokiem byłoby przeniesienie istniejącego kodu i uruchomienie go

+w środowisku Android. Potem kod powinien zostać zaktualizowany, by obsługiwać

+nowsze wersje protokołu Tora, jak na przykład

+<a href="<svnsandbox>doc/spec/dir-spec.txt">protokół katalogowy w wersji 3</a>.

+Poza tym, obsługa żądań lub choćby dostarczania usług ukrytych Tora byłaby fajna,

+choć nie wymagana.<br />

+ Perspektywiczny deweloper powinien rozumieć i umieć pisać nowy kod w Javie, łącznie

+z korzystaniem z kryptograficznego API Javy. Umiejętność czytania kodu w C

+też byłaby przydatna. Powinno się mieć chęć do czytania istniejącej dokumentacji,

+implementacji kodu w oparciu o nią oraz, jeśli będzie to potrzebne, poprawiać

+dokumentację, jeśli jest niejasna. Ten projekt składa się w dużym stopniu z

+pisania kodu i w mniejszym - z projektowania.

+</li>

+

+<li>

+<b>Nowe funkcjonalności Torbuttona</b>

+<br/>

+Priorytet: <i>Średni</i>

+<br />

+Poziom wysiłku: <i>Wysoki</i>

+<br />

+Poziom umiejętności: <i>Wysoki</i>

+<br />

+Prawdopodobni opiekunowie: <i>Mike</i>

+<br/>

+Jest kilka <a

+href="https://bugs.torproject.org/flyspray/index.php?tasks=all&project=5&type=2">dobrych

+próśb o nowe funkcjonalności</a> w sekcji Flyspray Torbuttona. W szczególności, <a

+href="https://bugs.torproject.org/flyspray/index.php?do=details&id=523">Integracja

+'Nowej Tożsamości' z Vidalią</a>,

+<a href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=940">sposoby

+zarządzania wieloma plikami z ciasteczkami/tożsamościami</a>, <a

+href="https://bugs.torproject.org/flyspray/index.php?do=details&id=637">zachowywanie

+określonych ciasteczek</a> gdy ciasteczka są usuwane,

+<a href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=524">lepsza

+podmiana odnośnika wstecznego</a>, <a

+href="https://bugs.torproject.org/flyspray/index.php?do=details&id=564">prawidłowe

+zgłaszanie stanu Tora</a>, i <a

+href="https://bugs.torproject.org/flyspray/index.php?do=details&id=462">adresy "tor://"

+i "tors://"</a> są interesującymi cechami, które można byłoby dodać.

+<br />

+Ta praca byłaby niezależnym programowaniem w Javascripcie i przyjemnym świecie <a

+href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>, z

+niewielkim zaangażowaniem w wewnętrzne sprawy Tora.

+</li>

+

+<li>

+<b>Nowe funkcjonalności Thandy</b>

+<br />

+Priorytet: <i>Średni</i>

+<br />

+Poziom wysiłku: <i>Średni</i>

+<br />

+Poziom umiejętności: <i>Średni do wysokiego</i>

+<br />

+Prawdopodobni opiekunowie: <i>Martin</i>

+<br />

+Potrzebujemy dodatkowych funkcjonalności do wspomaganych aktualizacji całego

+oprogramowania związanego z Torem na Windows i innych systemach operacyjnych.

+Niektóre funkcjonalności do rozważenia to:

+1) Integracja <a

+href="http://chandlerproject.org/Projects/MeTooCrypto">biblioteki Pythona MeTooCrypto</a>

+do uwierzytelnianych pobierań przez HTTPS. 2) Dodanie poziomu niezależności między

+sygnaturami czasowymi a plikami załączonymi w aktualizacji. Przeczytaj wątek

+"Thandy attacks / suggestions" na or-dev.

+3) Obsługa specyficznych dla lokalizacji instalacji i konfiguracji wspomaganych

+aktualizacji w oparciu o ustawienia języka według preferencji, hosta lub konta użytkownika.

+Znajomość stron kodowych Windows, unikodu i innych zestawów znaków będzie pomocna,

+jak również ogólne doświadczenie w programowaniu win32 i POSIX API oraz biegłość w Pythonie.

+</li>

+

+<li>

+<b>Symulator wolnych połączeń internetowych</b>

+<br />

+Priorytet: <i>Średni</i>

+<br />

+Poziom wysiłku: <i>Średni</i>

+<br />

+Poziom umiejętności: <i>Średni</i>

+<br />

+Prawdopodobni opiekunowie: <i>Steven</i>

+<br />

+Wielu użytkowników Tora ma łącza internetowe niskiej jakości, dające niską przepustowość,

+długie czasy trwania operacji i wysoki współczynnik utraty lub przekładania pakietów.

+Z doświadczeń użytkowników wiemy, że Tor źle reaguje na te warunki, ale ciężko jest

+poprawić tę sytuację bez możliwości powtórzenia tych problemów w laboratorium.

+<br />

+Celem tego projektu byłoby zbudowania środowiska symulacyjnego, które replikowałoby

+tę słabą łączność, by można było zmierzyć jej działanie na wydajność Tora. Innymi

+komponentami byłby program testujący, w celu określenia dostępnych parametrów połączenia

+i mierzenia wpływu zmian polepszających wydajność Tora.

+<br />

+Wybór narzędzi zależałby od studenta/ki, ale dummynet (dla FreeBSD) i

+nistnet (pod Linux) są dwoma potencjalnymi komponentami, na których można byłoby zbudować ten

+projekt. Studenci powinni mieć doświadczenie w programowaniu i debugowaniu sieciowym i TCP/IP

+oraz najlepiej znać C i język skryptowy.

+</li>

+

+<li>

+<b>Poprawiona i bardziej użyteczna mapa sieci w programie Vidalia</b>

+<br />

+Priorytet: <i>Średni</i>

+<br />

+Poziom wysiłku: <i>Średni</i>

+<br />

+Poziom umiejętności: <i>Średni</i>

+<br />

+Prawdopodobni opiekunowie: <i>Matt</i>

+<br />

+Jedną z istniejących cech Vidalii jest mapa sieci, która pokazuje użytkownikowi

+przybliżone lokalizacje geograficzne przekaźników sieci Tora i rysuje

+ścieżki, przez które przechodzi ruch użytkownika w sieci Tora.

+Mapa jest w tej chwili niezbyt interaktywna i ma raczej słabą grafikę.

+Zamiast tego, zaimplementowaliśmy widget Marble z KDE, który daje mapę lepszej jakości i

+umożliwia lepszą interaktywność, jak na przykład pozwalanie użytkownikowi na

+klikanie w poszczególne przekaźniki lub obwody, by wyświetlić dodatkowe

+informacje. Chcemy też dodaće możliwość klikania przez

+użytkownika na dany przekaźnik lub kraj z co najmniej jednym przekaźnikiem i

+stwierdzenia "chcę, by moje połączenia do wychodziły stąd."

+<br />

+Podczas tego projektu, osoba najpierw zapozna się z Vidalią i API widgetu

+Marble. Potem zintegruje widget z Vidalią i zmieni go, by bardziej pasował

+do naszych zastosowań, np. można było klikać w obwody, zapisywać mapy we

+własnym katalogu Vidalii i dostosować część okien dialogowych widgetu.

+<br />

+Osoba podejmująca się tego projektu powinna dobrze znać C++.

+Uprzednie doświadczenie z Qt i CMake będzie przydatne, ale nie jest wymagane.

+</li>

+

+<li>

+<b>Ożywienie projektu moniTor</b>

+<br />

+Priorytet: <i>Średni</i>

+<br />

+Poziom wysiłku: <i>Średni</i>

+<br />

+Poziom umiejętności: <i>Niski do średniego</i>

+<br />

+Prawdopodobni opiekunowie: <i>Karsten, Jacob</i>

+<br />

+Zaimplementuj narzędzie <a href="http://www.ss64.com/bash/top.html">podobne do top</a>

+dla przekaźników siei Tora. Celem takiego narzędzia byłoby monitorowanie lokalnego przekaźnika

+sieci poprzez jego port kontrolny i dołączanie użytecznych informacji systemowych

+samej maszyny. Podczas działania, narzędzie to dynamicznie aktualizowałoby

+swoje informacje, tak jak program top robi to dla procesów linuksowych.

+<a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">Ta

+wiadomość na or-dev</a> może być dobrą lekturą na początek.<br />

+ Obsoba powinna znać lub

+być chętną do nauki administrowania przekaźnikiem Tora i konfigurowania go

+za pomocą portu kontroli. Jako że wstępny prototyp jest napisany w Pythonie,

+pewna wiedza na temat pisania programów w tym języku też byłaby przydatna.

+Ten projekt z jednej strony opiera się na określeniu wymagań dla takiego

+narzędzia i zaprojektowania dla niego interfejsu, a z drugiej strony

+wymaga również dużo programowania.

+</li>

+

+<li>

+<b>Odpowiednik Torbuttona dla Thunderbirda</b>

+<br />

+Priorytet: <i>Średni</i>

+<br />

+Poziom wysiłku: <i>Wysoki</i>

+<br />

+Poziom umiejętności: <i>Wysoki</i>

+<br />

+Prawdopodobni opiekunowie: <i>Mike</i>

+<br />

+Od ciągle powiększającej się grupy użytkowników słyszymy, że chcą używać Thunderbirda z

+Torem. Jest jednak wiele spraw na poziomie aplikacji, na przykład to, że Thunderbird

+domyślnie umieści Twoją nazwę hosta w wysyłanej przez siebie poczcie. W pewnym momencie

+powinniśmy zapoczątkować nowe działania mające na celu stworzenie rozszerzenia dla

+Thunderbirda, podobnego do Torbuttona.

+</li>

+

+<li>

+<b>Sterownik Pośredniego Poziomu Sieci</b>

+<br />

+Priorytet: <i>Niski</i>

+<br />

+Poziom wysiłku: <i>Wysoki</i>

+<br />

+Poziom umiejętności: <i>Wysoki</i>

+<br />

+Prawdopodobni opiekunowie: <i>Martin</i>

+<br />

+Sterownik WinPCAP używany przez Tor VM do działań sieciowych nie obsługuje sporej

+liczby kart bezprzewodowych i nie-ethernetowych. Zaimplementowanie sterownika

+pośredniego poziomu sieciowego dla win32 i 64-bitowego dałoby możliwość przechwytywania

+i przekierowywania ruchu w takich sieciach. Ten projekt wymaga znajomości i doświadczenia

+z pisaniem i testowaniem sterowników poziomu jądra Windows. Znajomość Winsock i Qemu

+też byłaby pomocna.

+</li>

+

+<li>

+<b>Przynieś nowe pomysły!</b>

+<br />

+<li>Nie podoba Ci się żaden z tych pomysłów? Sięgnij do <a

+ href="<svnsandbox>doc/roadmaps/2008-12-19-roadmap-full.pdf">planu rozwoju Tora</a> po więcej

+ pomysłów.

+ Niektórym z <a href="<svnsandbox>doc/spec/proposals/">bieżących propozycji</a>

+ też może brakować deweloperów.</li>

+

+<!-- Mike is already working on this.

+<li>

+<b>Ulepszenie Skanera Węzłów Tora (Tor Node Scanner)</b>

+<br />

+Podobnie do skanera wyjściowego SoaT (lub może nawet w czasie jego działania),

+można gromadzić statystyki odnośnie wiarygodności węzłów. Te węzły, które

+źle działają dla pewnej części swoich obwodów nie powinny być używane do

+statusu Strażnika, i być może powinny też mieć zmniejszoną swoją zgłaszaną

+przepustowość, lub po prostu być oznaczane jako Nieważne. Dodatkowo,

+węzły wykazujące bardzo niską średnią przepustowość strumienia,

+lecz zgłaszają bardzo wysoką, też mogą być oznaczone jako Nieważne.

+Większość zbierania statystyk już jest zrobiona, dane te muszą tylko

+zostać przetworzone na coś, co może być wysłane Serwerom Katalogowym,

+by ukarały/wyłączyły ze swoich list te węzły w taki sposób, że klienci

+się o tym dowiedzą.

+<br />

+Dodatkowo, te same statystyki mogą być zbierane odnośnie ruchu przechodzącego

+przez węzeł. Do <a

+href="https://svn.torproject.org/svn/torctl/trunk/doc/howto.txt">Protokołu Kontroli

+Tora</a> można dodać zdarzenia mówiące, czy udaje się stworzyć obwód

+przechodzący przez ten węzeł, oraz można zbierać pasywne statystyki dotyczące

+zarówno przepustowości, jak i wiarygodności innych węzłów, poprzez oparty

+na węzłach program monitorujący takie zdarzenia. Taki skaner zgłaszałby też

+informacje o dziwnie zachowujących się węzłach do Serwerów Katalogowych,

+ale kanał łączności do tych celów jeszcze nie istnieje i też musiałby

+zostać stworzony.

+</li>

+-->

+

+<!-- Is this still a useful project? If so, move it to another section.

+<li>

+<b>Lepsze wsparcie i pakowanie dla Debiana/Ubuntu</b>

+<br />

+Vidalia obecnie nie współpracuje dobrze na Debianie i Ubuntu z domyślnymi

+paczkami Tora. Bieżące paczki Tora automatycznie uruchamiają Tora jako demona

+systemowego z konta użytkownika debian-tor i (rozsądnie) nie mają zdefiniowanego

+ControlPort w domyślnym torrc. Stąd Vidalia będzie próbować uruchomić własny

+proces Tora, bo nie może połączyć się z istniejącym, po czym proces Tora

+uruchomiony przez Vidalię zamknie się z błędem, którego użytkownik raczej nie zrozumie,

+jako że Tor nie będzie mógł podpiąć się pod swoje porty nasłuchowe, które są

+już zajęte przez pierwszy proces Tora.

+<br />

+Bieżące rozwiązanie to albo mówienie użytkownikowi, by zatrzymał istniejący

+proces Tora i pozwolił Vidalii uruchomić własny, albo tłumaczenie, jak ustawić

+port kontrolny i hasło w pliku torrc. Lepszym rozwiązaniem na Debianie byłoby używanie

+ControlSocket Tora, który umożliwia Vidalii komunikowanie się z Torem poprzez

+gniazdo w domenie Unix i mógłby być domyślnie włączony w paczkach Tora dla Debiana.

+Vidalia może wtedy uwierzytelnić się do Tora używając ciasteczek, jeśli użytkownik

+uruchamiający Vidalię jest w grupie debian-tor.

+<br />

+Pierwsza część tego projektu będzie polegała na dodaniu obsługi ControlSocket

+do Vidalii. Potem student stworzy i przetestuje paczki Vidalii na Debianie i

+Ubuntu, które będą zgodne ze standardami pakowania w Debianie, oraz upewni się,

+że działają dobrze z istniejącymi paczkami Tora. Możemy też stworzyć repozytorium

+apt zawierające nowe paczki Vidalia.

+<br />

+Kolejnym wyzwaniem byłoby znalezienie intuicyjnego sposobu, by Vidalia mogła

+zmienić konfigurację Tora (torrc) mimo iż ta jest w <code>/etc/tor/torrc</code>,

+a więc nienaruszalna. Najlepszy jak dotąd pomysł, na jaki wpadliśmy, to

+przekazanie Torowi nowej konfiguracji poprzez ControlSocket w czasie uruchamiania

+Vidalii, ale jest to zły pomysł, gdyż Tor za każdym razem uruchamia się z inną

+konfiguracją niż użytkownik by tego chciał. Drugi najlepszy pomysł jest taki, by

+Vidalia stworzyła tymczasowy plik konfiguracyjny i poprosiła użytkownika, by

+ręcznie przeniósł go do <code>/etc/tor/torrc</code>, ale to jest zły pomysł, gdyż

+użytkownicy nie powinni być zmuszani do bezpośredniego zajmowania się plikami.

+<br />

+Osoba podejmująca się tego projektu powinna znać system pakowania Debiana i

+mieć trochę doświadczenia z C++. Uprzednie doświadczenie z Qt będzie przydatne,

+ale nie jest wymagane.

+</li>

+-->

+

+<!-- This should be mostly done.

+<li>

+<b>Framework automatycznej aktualizacji programów Tor/Polipo/Vidalia.</b>

+<br />

+Potrzebujemy dobrego frameworka automatycznej aktualizacji.

+Vidalia już ma możliwość informowania, że użytkownik używa przestarzałej lub

+niezalecanej wersji Tora. W chwili obecnej Vidalia po prostu pokazuje małe

+okienko, które informuje użytkownika, że powinien dokonać ręcznej aktualizacji.

+Celem tego projektu jest rozszerzenie Vidalii o możliwość pobrania i

+zaktualizowania nowej wersji Tora za użytkownika. Jeśli czas pozwoli,

+chcielibyśmy móc aktualizować też inne aplikacje z paczek, jak Polipo czy

+Vidalia.

+<br />

+By wykonać ten projekt, student będzie musiał najpierw poznać istniejące

+mechanizmy aktualizacji (np. Sparkle na OS X), by zbadać ich mocne i słabe punkty,

+cechy bezpieczeństwa i możliwości zintegrowania z Vidalią. Jeśli żaden nie okaże

+się przydatny, student zaprojektuje własny framework aktualizacyjny,

+udokumentuje projekt i przedyskutuje go z innymi deweloperami na temat

+jego bezpieczeństwa. Potem zaimplementuje go (lub zintegruje istniejący)

+i przetestuje.

+<br />

+Osoba podejmująca się tego projektu powinna dobrze znać C++.

+Uprzednie doświadczenie z Qt będzie przydatne, ale nie jest wymagane.

+Powinno się mieć też podstawowe pojęcie o powszechnych praktykach

+bezpieczeństwa, jak weryfikacja podpisu paczki. Dobre zdolności w

+pisaniu też są ważne w tym projekcie, gdyż ważnym krokiem będzie

+zrobienie dokumentacji projektu do przejrzenia i przedyskutowania

+z innymi ludźmi przed implementacją.

+</li>

+-->

+

+<!-- Jake already did most of this.

+<li>

+<b>Ulepszenia naszego aktywnego testera konfiguracji przeglądarek</b> -

+<a href="https://check.torproject.org">https://check.torproject.org</a>

+<br />

+Mamy w tej chwili funkcjonalną stronę www, która sprawdza, czy Tor działa.

+Ma jednak parę miejsc, w których działa źle. Wymaga ulepszeń dotyczących

+domyślnych języków i funkcjonalności. W chwili obecnej odpowiada tylko po angielsku.

+Ponadto, jest to kawał skryptu Perla, który nigdy nie powinien był ujrzeć światła

+dziennego. Strona powinna prawdopodobnie zostać przepisana w Pythonie

+z uwagą na wielojęzyczności. Teraz używa <a

+href="http://exitlist.torproject.org/">listy punktów wyjściowych Tor DNS</a>

+i powinna to robić w przyszłości. Może to dawać fałszywe pozytywne wyniki - te

+powinny zostać wykryte, udokumentowane i naprawione, gdzie to będzie możliwe.

+Ktokolwiek pracujący nad tym projektem powinien interesować się DNS,

+znać podstawy Perla lub lepiej - Pythona. Będzie musiał tylko minimalnie

+stykać się z Torem, by testować swój kod.

+<br />

+Jeśli chcesz, by ten projekt był bardziej ekscytujący i zawierał więcej

+projektowania i programowania, przeczytaj <a

+href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">propozycję

+131-verify-tor-usage.txt</a>.

+</li>

+-->

 <!-- If we decide to switch to the exit list in TorStatus, this is obsolete.

 <li>

@@ -445,143 +778,34 @@ Niełatwe również będzie dodanie ograniczanie transferu do Libevent.

 </li>

 -->

-<li>

-<b>Tuneup Tor!</b>

-<br />

-Priorytet: <i>Średni</i>

-<br />

-Poziom wysiłku: <i>Średni</i>

-<br />

-Poziom umiejętności: <i>Średni do wysokiego</i>

-<br />

-Prawdopodobni opiekunowie: <i>Nick, Roger, Mike</i>

-<br />

-W chwili obecnej węzły Tora mierzą i zgłaszają własną przepustowość łącza,

-a klienci Tora wybierają, których węzłów używać po części opierając się

-na tej zgłaszanej przepustowości. To podejście jest podatne na

-<a href="http://freehaven.net/anonbib/#bauer:wpes2007">ataki, w których węzły oszukują

-na temat przepustowości swoich łączy</a>; by to zmienić, Tor aktualnie ogranicza

-maksymalną przepustowość każdego węzła, w którą jest w stanie uwierzyć. To jest

-ograniczone rozwiązanie i marnotrawienie przepustowości. Zamiast tego,

-Tor powinien w miarę możliwości mierzyć przepustowość łączą w rozproszony sposób,

-jak jest napisane w dokumencie

-<a href="http://freehaven.net/anonbib/author.html#snader08">"A Tuneup for Tor"</a> autorstwa

-Snadera i Borisova. Można byłoby użyć bieżącego kodu testującego, by sprawdzić

-odkrycia napisane w tym dokumencie i zweryfikować, w jakim stopniu opisują one

-normalnie działającego Tora i określić dobre sposoby na wcielenie tych odkryć

-do sieci Tora bez dodawania niepożądanego ruchu wielkości między węzłami a serwerami

-katalogowymi.

-</li>

-

 <!--

 <li>

 <b>Polepszenie procesu QA Tora: Ciągła integracja dla paczek pod Windows</b>

 <br />

-Przydałby się automatyczny system tworzenia paczek dla Windows i być może

-innych systemów. Celem posiadania środowiska ciągłej integracji jest

-upewnienie się, że Windows nie zostanie w tyle z żadnym z projektów

-używanych lub związanych z projektem Tor. Buildbot

-może być dobrym rozwiązaniem, gdyż zdaje się obsługiwać te same platformy, co Tor.

-Przeczytaj (po angielsku) <a href="http://en.wikipedia.org/wiki/BuildBot">wpis na

-Wikipedii dotyczący Buildbota</a>.<br />

-Może jednak są lepsze rozwiązania, więc osoba podejmująca się tego zadania

-powinna rozważyć inne opcje. Jakakolwiek osoba pracująca nad tym systemem

-automatycznego budowania powinna mieć doświadczenie lub chęć do nauczenia

-się tego, jak buduje się wszystkie odpowiednie elementy Tora od zera.

-Ponadto, ta osoba powinna mieć jakieś doświadczenie w kompilowaniu

-programów w Windows, jako że to jest ta część użytkowników, których nie chcemy

-zostawiać w tyle. Zadanie będzie wymagała bliskiej pracy z kodem Tora,

-ale prawdopodobnie tylko od strony kompilacji, nie pisania.<br />

-Ponadto, musimy zautomatyzować nasze testy wydajności dla wszystkich systemów.

-Mamy już buildbota (za wyjątkiem Windows — jak napisane powyżej) do

-automatyzacji naszej zwyczajnej integracji i kompilacji testów, ale

-musimy zaktualizować nasze testy symulacji sieci (takie, jak w torflow)

-do nowszych wersji Tora i zaprojektować je tak, by uruchamiać sieci testowe

-albo na jednej maszynie, albo na kilku, abyśmy mogli automatycznie

-badać zmiany wydajności na maszynach pełniących różne zadania.<br />

-</li>

--->

-

-<li>

-<b>Polepszenie procesu testów jednostkowych</b>

-<br />

-Priorytet: <i>Średni</i>

-<br />

-Poziom wysiłku: <i>Średni</i>

-<br />

-Poziom umiejętności: <i>Średni</i>

-<br />

-Prawdopodobni opiekunowie: <i>Nick</i>

-<br />

-Tor musi zostać znaczniej bardziej przetestowany. To jest projekt wieloczęściowy.

-Na początek, nasze testy jednostkowe powinny znacznie się wzbogacić, zwłaszcza

-w obszarach poza funkcjami narzędziowymi. Będzie to wymagało poważnych zmian

-niektórych części Tora, aby oddzielić jak najwięcej programu od zmiennych

-globalnych.<br />

-Ponadto, musimy zautomatyzować nasze testy wydajności dla wszystkich systemów.

-Mamy już buildbota do automatyzacji naszej zwyczajnej integracji i kompilacji testów

-(ale potrzebujemy osoby do uruchomienia tego pod Windows), ale

-musimy zaktualizować nasze testy symulacji sieci (takie, jak w <a

-href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>)

-do nowszych wersji Tora i zaprojektować je tak, by uruchamiać sieci testowe

-albo na jednej maszynie, albo na kilku, abyśmy mogli automatycznie

-badać zmiany wydajności na maszynach pełniących różne zadania.

-</li>

-

-<li>

-<b>Pomóż wznowić niezależną implementację klienta Tora</b>

-<br />

-Priorytet: <i>Średni</i>

-<br />

-Poziom wysiłku: <i>Wysoki</i>

-<br />

-Poziom umiejętności: <i>Średni do wysokiego</i>

-<br />

-Prawdopodobni opiekunowie: <i>Karsten, Nick</i>

-<br />

-Reanimuj jedno z podejść do implementacji klienta Tora w Javie, np.

-<a href="http://onioncoffee.sourceforge.net/">projekt OnionCoffee</a>

-i spraw, by działał pod <a href="http://code.google.com/android/">Androidem</a>.

-Pierwszym krokiem byłoby przeniesienie istniejącego kodu i uruchomienie go

-w środowisku Android. Potem kod powinien zostać zaktualizowany, by obsługiwać

-nowsze wersje protokołu Tora, jak na przykład

-<a href="<svnsandbox>doc/spec/dir-spec.txt">protokół katalogowy w wersji 3</a>.

-Poza tym, obsługa żądań lub choćby dostarczania usług ukrytych Tora byłaby fajna,

-choć nie wymagana.<br />

- Perspektywiczny deweloper powinien rozumieć i umieć pisać nowy kod w Javie, łącznie

-z korzystaniem z kryptograficznego API Javy. Umiejętność czytania kodu w C

-też byłaby przydatna. Powinno się mieć chęć do czytania istniejącej dokumentacji,

-implementacji kodu w oparciu o nią oraz, jeśli będzie to potrzebne, poprawiać

-dokumentację, jeśli jest niejasna. Ten projekt składa się w dużym stopniu z

-pisania kodu i w mniejszym - z projektowania.

-</li>

-

-<li>

-<b>Ożywienie projektu moniTor</b>

-<br />

-Priorytet: <i>Średni</i>

-<br />

-Poziom wysiłku: <i>Średni</i>

-<br />

-Poziom umiejętności: <i>Niski do średniego</i>

-<br />

-Prawdopodobni opiekunowie: <i>Karsten, Jacob</i>

-<br />

-Zaimplementuj narzędzie <a href="http://www.ss64.com/bash/top.html">podobne do top</a>

-dla przekaźników siei Tora. Celem takiego narzędzia byłoby monitorowanie lokalnego przekaźnika

-sieci poprzez jego port kontrolny i dołączanie użytecznych informacji systemowych

-samej maszyny. Podczas działania, narzędzie to dynamicznie aktualizowałoby

-swoje informacje, tak jak program top robi to dla procesów linuksowych.

-<a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">Ta

-wiadomość na or-dev</a> może być dobrą lekturą na początek.<br />

- Obsoba powinna znać lub

-być chętną do nauki administrowania przekaźnikiem Tora i konfigurowania go

-za pomocą portu kontroli. Jako że wstępny prototyp jest napisany w Pythonie,

-pewna wiedza na temat pisania programów w tym języku też byłaby przydatna.

-Ten projekt z jednej strony opiera się na określeniu wymagań dla takiego

-narzędzia i zaprojektowania dla niego interfejsu, a z drugiej strony

-wymaga również dużo programowania.

+Przydałby się automatyczny system tworzenia paczek dla Windows i być może

+innych systemów. Celem posiadania środowiska ciągłej integracji jest

+upewnienie się, że Windows nie zostanie w tyle z żadnym z projektów

+używanych lub związanych z projektem Tor. Buildbot

+może być dobrym rozwiązaniem, gdyż zdaje się obsługiwać te same platformy, co Tor.

+Przeczytaj (po angielsku) <a href="http://en.wikipedia.org/wiki/BuildBot">wpis na

+Wikipedii dotyczący Buildbota</a>.<br />

+Może jednak są lepsze rozwiązania, więc osoba podejmująca się tego zadania

+powinna rozważyć inne opcje. Jakakolwiek osoba pracująca nad tym systemem

+automatycznego budowania powinna mieć doświadczenie lub chęć do nauczenia

+się tego, jak buduje się wszystkie odpowiednie elementy Tora od zera.

+Ponadto, ta osoba powinna mieć jakieś doświadczenie w kompilowaniu

+programów w Windows, jako że to jest ta część użytkowników, których nie chcemy

+zostawiać w tyle. Zadanie będzie wymagała bliskiej pracy z kodem Tora,

+ale prawdopodobnie tylko od strony kompilacji, nie pisania.<br />

+Ponadto, musimy zautomatyzować nasze testy wydajności dla wszystkich systemów.

+Mamy już buildbota (za wyjątkiem Windows — jak napisane powyżej) do

+automatyzacji naszej zwyczajnej integracji i kompilacji testów, ale

+musimy zaktualizować nasze testy symulacji sieci (takie, jak w torflow)

+do nowszych wersji Tora i zaprojektować je tak, by uruchamiać sieci testowe

+albo na jednej maszynie, albo na kilku, abyśmy mogli automatycznie

+badać zmiany wydajności na maszynach pełniących różne zadania.<br />

 </li>

+-->

 <!-- Removed, unless Mike still wants this to be in.

 <li>

@@ -605,30 +829,6 @@ bez zbytniego zagłębiania się do wnętrzności Tora.

 </li>

 -->

-<li>

-<b>Ulepszenie Polipo na Windows</b>

-<br />

-Priorytet: <i>Średni</i>

-<br />

-Poziom wysiłku: <i>Niski</i>

-<br />

-Poziom umiejętności: <i>Średni</i>

-<br />

-Prawdopodobni opiekunowie: <i>Martin</i>

-<br />

-Pomóż przenieść <a

-href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> na Windows.

-1) zdolność do asynchronicznego wysyłania zapytań do

-serwerów nazw. 2) natywna obsługa zdarzeń i buforów (tj. w

-systemach uniksopodobnych Polipo domyślnie używa 25% pamięci RAM, a pod Windows

-jest to cokolwiek wpisane w plik konfiguracyjny). 3) jakieś narzędzie z

-graficznym interfejsem do konfiguracji i raportowania, dodatkowe punkty, jeśli

-ma ikonkę w zasobniku z opcjami menu po kliknięciu prawym przyciskiem myszy.

-Podwójny bonus, jeśli działa na wielu platformach.

-4) umożliwienie programowi używania rejestru Windowsa i obsługiwania prawidłowych

-ścieżek w Windowsie, np. "C:\Program Files\Polipo".

-</li>

-

 <!-- Is Blossom development still happening?

 <li>

 <b>Zmiana i rozszerzenie Blossom</b>

@@ -675,80 +875,7 @@ niespójności Internetu są podstawą projektu Blossom.

 </li>

 -->

-<li>

-<b>Zaimplementowanie opartego na torrencie sposobu pobierania paczek Thandy</b>

-<br />

-Priorytet: <i>Średni</i>

-<br />

-Poziom wysiłku: <i>Wysoki</i>

-<br />

-Poziom umiejętności: <i>Średni do wysokiego</i>

-<br />

-Prawdopodobni opiekunowie: <i>Martin, Nick</i>

-<br />

-<a

-href="http://git.torproject.org/checkout/thandy/master/specs/thandy-spec.txt">Thandy</a>

-jest względnie nowym oprogramowaniem, które umożliwia wspomagane aktualizacje Tora i

-związanych z nim programów. W tej chwili użytkowników jest niewielu, ale oczekujemy, że

-Thandy będzie w przyszłości używane przez prawie każdego użytkownika Tora. By uniknąć

-padających serwerów w dniu aktualizacji Tora, potrzebujemy nowych sposobów na

-wydajną dystrybucję nowych paczek, a wykorzystanie libtorrent zdaje się być

-możliwym rozwiązaniem. Jeśli myślisz o innych dobrych pomysłach, to wspaniale

-- proszę dać nam znać!<br />

-Musimy też zbadać, jak lepiej dołączyć nasze mirrory. Jeśli to możliwe, powinien

-znaleźć się łatwy sposób na to, by łatwo pomogły w dystrybucji paczek.

-</li>

-

-<li>

-<b>Odpowiednik Torbuttona dla Thunderbirda</b>

-<br />

-Priorytet: <i>Średni</i>

-<br />

-Poziom wysiłku: <i>Wysoki</i>

-<br />

-Poziom umiejętności: <i>Wysoki</i>

-<br />

-Prawdopodobni opiekunowie: <i>Mike</i>

-<br />

-Od ciągle powiększającej się grupy użytkowników słyszymy, że chcą używać Thunderbirda z

-Torem. Jest jednak wiele spraw na poziomie aplikacji, na przykład to, że Thunderbird

-domyślnie umieści Twoją nazwę hosta w wysyłanej przez siebie poczcie. W pewnym momencie

-powinniśmy zapoczątkować nowe działania mające na celu stworzenie rozszerzenia dla

-Thunderbirda, podobnego do Torbuttona.

-</li>

-

-<li>

-<b>Nowe funkcjonalności Torbuttona</b>

-<br/>

-Priorytet: <i>Średni</i>

-<br />

-Poziom wysiłku: <i>Wysoki</i>

-<br />

-Poziom umiejętności: <i>Wysoki</i>

-<br />

-Prawdopodobni opiekunowie: <i>Mike</i>

-<br/>

-Jest kilka <a

-href="https://bugs.torproject.org/flyspray/index.php?tasks=all&project=5&type=2">dobrych

-próśb o nowe funkcjonalności</a> w sekcji Flyspray Torbuttona. W szczególności, <a

-href="https://bugs.torproject.org/flyspray/index.php?do=details&id=523">Integracja

-'Nowej Tożsamości' z Vidalią</a>,

-<a href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=940">sposoby

-zarządzania wieloma plikami z ciasteczkami/tożsamościami</a>, <a

-href="https://bugs.torproject.org/flyspray/index.php?do=details&id=637">zachowywanie

-określonych ciasteczek</a> gdy ciasteczka są usuwane,

-<a href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=524">lepsza

-podmiana odnośnika wstecznego</a>, <a

-href="https://bugs.torproject.org/flyspray/index.php?do=details&id=564">prawidłowe

-zgłaszanie stanu Tora</a>, i <a

-href="https://bugs.torproject.org/flyspray/index.php?do=details&id=462">adresy "tor://"

-i "tors://"</a> są interesującymi cechami, które można byłoby dodać.

-<br />

-Ta praca byłaby niezależnym programowaniem w Javascripcie i przyjemnym świecie <a

-href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>, z

-niewielkim zaangażowaniem w wewnętrzne sprawy Tora.

-</li>

-

+<!-- not really suited for GSoC; integrated into TBB for Linux/Mac OS X

 <li>

 <b>Badania używalności Tora</b>

 <br />

@@ -765,132 +892,8 @@ To by bardzo pomogło w dowiedzeniu się, co musi zostać zrobione w dziedzinie

 błędów lub nowych funkcjonalności. W tej chwili dostajemy to nieformalnie, ale lepszy

 byłby bardziej strukturalny proces.

 </li>

+-->

-<li>

-<b>Wiki do tłumaczeń dla naszej strony</b>

-<br />

-Priorytet: <i>Wysoki</i>

-<br />

-Poziom wysiłku: <i>Średni</i>

-<br />

-Poziom umiejętności: <i>Średni</i>

-<br />

-Prawdopodobni opiekunowie: <i>Jacob</i>

-<br />

-Projekt Tor pracował w ciągu ostatniego roku nad uruchomieniem opartych na sieci narzędzi,

-by pomóc ochotnikom w tłumaczeniu naszych aplikacji na inne języki.

-W końcu stanęliśmy na Pootle i mamy dobry mechanizm sieciowy do tłumaczeń dla programów

-Vidalia, Torbutton i Torcheck. Ale Pootle tłumaczy tylko napisy w formacie "po", a

-nasza strona korzysta z plików wml. Celem tego projektu jest znalezienie sposobu na

-konwersję naszych plików wml na pliki "po" i z powrotem, by mogły być obsługiwane przez Pootle.

-</li>

-

-<li>

-<b>Nowe funkcjonalności Thandy</b>

-<br />

-Priorytet: <i>Średni</i>

-<br />

-Poziom wysiłku: <i>Średni</i>

-<br />

-Poziom umiejętności: <i>Średni do wysokiego</i>

-<br />

-Prawdopodobni opiekunowie: <i>Martin</i>

-<br />

-Potrzebujemy dodatkowych funkcjonalności do wspomaganych aktualizacji całego

-oprogramowania związanego z Torem na Windows i innych systemach operacyjnych.

-Niektóre funkcjonalności do rozważenia to:

-1) Integracja <a

-href="http://chandlerproject.org/Projects/MeTooCrypto">biblioteki Pythona MeTooCrypto</a>

-do uwierzytelnianych pobierań przez HTTPS. 2) Dodanie poziomu niezależności między

-sygnaturami czasowymi a plikami załączonymi w aktualizacji. Przeczytaj wątek

-"Thandy attacks / suggestions" na or-dev.

-3) Obsługa specyficznych dla lokalizacji instalacji i konfiguracji wspomaganych

-aktualizacji w oparciu o ustawienia języka według preferencji, hosta lub konta użytkownika.

-Znajomość stron kodowych Windows, unikodu i innych zestawów znaków będzie pomocna,

-jak również ogólne doświadczenie w programowaniu win32 i POSIX API oraz biegłość w Pythonie.

-</li>

-

-<li>

-<b>Sterownik Pośredniego Poziomu Sieci</b>

-<br />

-Priorytet: <i>Niski</i>

-<br />

-Poziom wysiłku: <i>Wysoki</i>

-<br />

-Poziom umiejętności: <i>Wysoki</i>

-<br />

-Prawdopodobni opiekunowie: <i>Martin</i>

-<br />

-Sterownik WinPCAP używany przez Tor VM do działań sieciowych nie obsługuje sporej

-liczby kart bezprzewodowych i nie-ethernetowych. Zaimplementowanie sterownika

-pośredniego poziomu sieciowego dla win32 i 64-bitowego dałoby możliwość przechwytywania

-i przekierowywania ruchu w takich sieciach. Ten projekt wymaga znajomości i doświadczenia

-z pisaniem i testowaniem sterowników poziomu jądra Windows. Znajomość Winsock i Qemu

-też byłaby pomocna.

-</li>

-

-<li>

-<b>Paczka Tora z Przeglądarką dla Linux/Mac OS X</b>

-<br />

-Priorytet: <i>Wysoki</i>

-<br />

-Poziom wysiłku: <i>Wysoki</i>

-<br />

-Poziom umiejętności: <i>Średni</i>

-<br />

-Prawdopodobni opiekunowie: <i>Steven</i>

-<br />

-Paczka Tora z Przeglądarką zawiera Tora, Firefoksa i interfejs użytkownika - Vidalię

-(i opcjonalnie komunikator Pidgin). Komponenty te są prekonfigurowane do bezpiecznego

-działania, a paczka ma małe wymagania co do systemu operacyjnego. Stała się więc

-jednym z najprostszych i najbardziej popularnych sposobów używania Tora na Windows.

-<br />

-Nie ma jednak w chwili obecnej porównywalnej paczki dla Linuksa i Mac OS X, więc celem

-tego projektu byłaby implementacja Paczki Tora z Przeglądarką dla tych systemów.

-Będzie to pociągało zmiany w Vidalii (C++), być może w Firefoksie (C), po czym stworzenie

-i testowanie programu uruchamiającego na różnych wersjach i konfiguracjach systemów operacyjnych,