- tor-commits - lists.torproject.org

[torspec/master] Update proposal index
by nickm＠torproject.org 20 Oct '11

20 Oct '11

commit e7f498d3a3ae3d2de918b5f479e2fbf087a1c229 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Oct 19 20:05:23 2011 -0400 Update proposal index --- proposals/000-index.txt | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index de31a92..7c54411 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -103,10 +103,12 @@ Proposals by number: 180 Pluggable transports for circumvention [OPEN] 181 Optimistic Data for Tor: Client Side [CLOSED] 182 Credit Bucket [DRAFT] -183 Refill Intervals [OPEN] +183 Refill Intervals [CLOSED] 184 Miscellaneous changes for a v3 Tor link protocol [OPEN] 185 Directory caches without DirPort [OPEN] 186 Multiple addresses for one OR or bridge [DRAFT] +187 Reserve a cell type to allow client authorization [OPEN] +188 Bridge Guards and other anti-enumeration defenses [OPEN] Proposals by status: @@ -137,9 +139,10 @@ Proposals by status: 177 Abstaining from votes on individual flags [for 0.2.3.x] 178 Require majority of authorities to vote for consensus parameters [for 0.2.3.x] 180 Pluggable transports for circumvention [for 0.2.3.x] - 183 Refill Intervals 184 Miscellaneous changes for a v3 Tor link protocol [for 0.2.3.x] 185 Directory caches without DirPort + 187 Reserve a cell type to allow client authorization [for 0.2.3.x] + 188 Bridge Guards and other anti-enumeration defenses ACCEPTED: 110 Avoiding infinite length circuits [for 0.2.3.x] [in 0.2.1.3-alpha] 117 IPv6 exits [for 0.2.3.x] @@ -193,6 +196,7 @@ Proposals by status: 171 Separate streams across circuits by connection metadata [in 0.2.3.3-alpha] 174 Optimistic Data for Tor: Server Side [in 0.2.3.1-alpha] 181 Optimistic Data for Tor: Client Side [in 0.2.3.3-alpha] + 183 Refill Intervals [in 0.2.3.5-alpha] SUPERSEDED: 112 Bring Back Pathlen Coin Weight 113 Simplifying directory authority administration

1 0

[torspec/master] proposal 183 was implemented in 0.2.3.5-alpha
by nickm＠torproject.org 20 Oct '11

20 Oct '11

commit 86bda8195e256aacd7c58b5d500c763edee909ce Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Oct 17 15:18:59 2011 -0400 proposal 183 was implemented in 0.2.3.5-alpha --- proposals/183-refillintervals.txt | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/proposals/183-refillintervals.txt b/proposals/183-refillintervals.txt index c823d40..81ff5b0 100644 --- a/proposals/183-refillintervals.txt +++ b/proposals/183-refillintervals.txt @@ -2,7 +2,8 @@ Filename: 183-refillintervals.txt Title: Refill Intervals Author: Florian Tschorsch and Björn Scheuermann Created: 03-Dec-2010 -Status: Open +Status: Closed +Implemented-In: 0.2.3.5-alpha Overview:

1 0

[torspec/master] Proposal for Tor instances to accept other cell types before VERSIONS
by nickm＠torproject.org 20 Oct '11

20 Oct '11

commit cc2d3209079682ccc285a1e9a89caaf14be3fbe8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Sun Oct 16 16:50:26 2011 -0400 Proposal for Tor instances to accept other cell types before VERSIONS --- proposals/187-allow-client-auth.txt | 131 +++++++++++++++++++++++++++++++++++ 1 files changed, 131 insertions(+), 0 deletions(-) diff --git a/proposals/187-allow-client-auth.txt b/proposals/187-allow-client-auth.txt new file mode 100644 index 0000000..3d3cf25 --- /dev/null +++ b/proposals/187-allow-client-auth.txt @@ -0,0 +1,131 @@ +Filename: 187-allow-client-auth.txt +Title: Reserve a cell type to allow client authorization +Author: Nick Mathewson +Created: 16-Oct-2011 +Status: Open +Target: 0.2.3.x + +Overview: + + Proposals 176 and 184 introduce a new "v3" handshake, coupled with + a new version 3 link protocol. This is a good time to introduce + other stuff we might need. + + One thing we might want is a scanning resistance feature for + bridges. This proposal suggests a change we should make right + away to enable us to deploy such a feature in future versions of + Tor. + +Motivation: + + If an adversary has a suspected bridge address/port combination, + the easiest way for them to confirm or disconfirm their suspicion + is to connect to the address and see whether they can do a Tor + handshake. The easiest way to fix this problem seems to be to + give out bridge addresses along with some secret that clients + should know, but which an adversary shouldn't be able to learn + easily. The client should prove to the bridge that it's + authorized to know about the bridge, before the bridge acts like a + bridge. If the client doesn't show knowledge of the proper + secret, the bridge should at like an HTTPS server or a bittorrent + tracker or something. + + This proposal *does not* specify a way for clients to authorize + themselves at bridges; rather, it specifies changes that we should + make now in order to allow this kind of authorization in the + future. + +Design: + + Currently, now that proposal 176 is implemented, if a server + provides a certificate that indicates a v3 handshake, and the + client understands how to do a V3 handshake, we specify that the + client's first cell must be a VERSIONS cell. + + Instead, we make the following specification changes: + + We reserve a new variable-length cell type, "AUTHORIZE." + + We specify that any number of PADDING or VPADDING or AUTHORIZE + cells may be sent by the client before it sends a VERSIONS cell. + Servers that do not require client authorization MUST ignore such + cells, except to include them when calculating the HMAC that will + appear in the CLOG part of a client's AUTHENTICATE cell. + + We still specify that clients SHOULD send VERSIONS as their first + cell; only in some future version of Tor will an AUTHORIZE cell be sent + first. + +Discussion: + + This change allows future versions of the Tor client to know that + some bridges need authorization, and to send them authentication + before sending them anything recognizably Tor-like. + + The authorization cell needs to be received before the server can + send any Tor cells, so we can't just patch it in after the + VERSIONS cell exchange: the server's VERSIONS cell is unsendable + until after the AUTHORIZE has been accepted. + + Note that to avoid scanning attacks, it's not sufficient to wait + for a single cell, and then either handle it as authorization or + reject the connection. Instead, we need to decide what kind of + server we're impersonating, and respond once the client has + provided *either* an authorization cell, *or* a recognizably valid + or invalid command in the impersonated protocol. + + +Alternative design: Just use pluggable transports + + Pluggable transports can do this too, but in general, we want to + avoid designing the Tor protocol so that any particular desirable + feature can only be done with a pluggable transport. That is, any + feature that *every* bridge should want, should be doable in Tor + proper. + + Also, as of 16 Oct 2011, pluggable transports aren't in general + use. Past experience IMO suggests that we shouldn't offload + architectural responsibilities to our chickens until they've + hatched. + +Alternative design: Out-of-TLS authorization + + There are features (like port-knocking) designed to allow a client + to show that it's authorized to use a bridge before the TLS + handshake even happens. These are appropriate for bunches of + applications, but they're trickier with an adversary who is + MITMing the client. + +Alternative design: Just use padding. + + Arguably, we could only add the "VPADDING" cell type to the list + of those allowed before VERSIONS cells, and say that any client + authorization we specify later on will be sent as a VPADDING + cell. But that design is kludgy: padding should be padding, not + semantically significant. Besides, cell types are still fairly + plentiful. + +Counterargument: specify it later + + We could, later on, say that if a client learns that a bridge + needs authorization, it should send an AUTHORIZE cell. So long as + a client never sends an AUTHORIZE to anything other than a bridge that + needs authorization, it'll never violate the spec. + + But all things considered, it seems easier (just a few lines of + spec and code) to let bridges eat unexpected authorization now + than it does to have stuff fail later when clients think that a + bridge needs authorization but it doesn't. + +Counterargument: it's too late! + + We've already got the prop176 branch merged and running on a few + servers. But as of this writing, it isn't in any Tor version. + + Even if it *is* out in an alpha before we can get this proposal + accepted and implemented, that's not a big disaster. In the worst + case, where future clients don't know whom to send authorization + to so they need to send it to _all_ v3 servers, they will at worst + break their connections only to a couple of alpha versions which + one hopes by then will be long-deprecated already. +

1 0

[torspec/master] Proposal for bridges to redirect traffic through guard nodes
by nickm＠torproject.org 20 Oct '11

20 Oct '11

commit 1e20a8fac4d9ede8961c6fc920e73d3f96e2e889 Author: Nick Mathewson <nickm(a)torproject.org> Date: Sun Oct 16 16:49:42 2011 -0400 Proposal for bridges to redirect traffic through guard nodes --- proposals/188-bridge-guards.txt | 213 +++++++++++++++++++++++++++++++++++++++ 1 files changed, 213 insertions(+), 0 deletions(-) diff --git a/proposals/188-bridge-guards.txt b/proposals/188-bridge-guards.txt new file mode 100644 index 0000000..249d794 --- /dev/null +++ b/proposals/188-bridge-guards.txt @@ -0,0 +1,213 @@ +Filename: 188-bridge-guards.txt +Title: Bridge Guards and other anti-enumeration defenses +Author: Nick Mathewson +Created: 14 Oct 2011 +Status: Open + +1. Overview + + Bridges are useful against censors only so long as the adversary + cannot easily enumerate their addresses. I propose a design to make + it harder for an adversary who controls or observes only a few + nodes to enumerate a large number of bridges. + + Briefly: bridges should choose guard nodes, and use the Tor + protocol's "Loose source routing" feature to re-route all extend + requests from clients through an additional layer of guard nodes + chosen by the bridge. This way, only a bridge's guard nodes can + tell that it is a bridge, and the attacker needs to run many more + nodes in order to enumerate a large number of bridges. + + I also discuss other ways to avoid enumeration, recommending some. + + These ideas are due to a discussion at the 2011 Tor Developers' + Meeting in Waterloo, Ontario. Practically none of the ideas here + are mine; I'm just writing up what I remember. + +2. History and Motivation + + Under the current bridge design, an attacker who runs a node can + identify bridges by seeing which "clients" make a large number of + connections to it, or which "clients" make connections to it in the + same way clients do. This has been a known attack since early + versions {XXXX check} of the design document; let's try to fix it. + +2.1. Related ideas: Guard nodes + + The idea of guard nodes isn't new: since 0.1.1, Tor has used guard + nodes (first designed as "Helper" nodes by Wright et al in {XXXX}) + to make it harder for an adversary who controls a smaller number of + nodes to eavesdrop on clients. The rationale was: an adversary who + controls or observes only one entry and one exit will have a low + probability of correlating any single circuit, but over time, if + clients choose a random entry and exit for each circuit, such an + adversary will eventually see some circuits from each client with a + probability of 1, thereby building a statistical profile of the + client's activities. Therefore, let each client choose its entry + node only from among a small number of client-selected "guard" + nodes: the client is still correlated with the same probability as + before, but now the client has a nonzero chance of remaining + unprofiled. + +2.2. Related idea: Loose source routing + + Since the earliest versions of Onion Routing, the protocol has + provided "loose source routing". In strict source routing, the + source of a message chooses every hop on the message's path. But + in loose source routing, the message traverses the selected nodes, + but may also traverse other nodes as well. In other words, the + client selects nodes N_a, N_b, and N_c, but the message may in fact + traverse any sequence of nodes N_1...N_j, so long as N_1=N_a, + N_x=N_b, and N_y=N_c, for 1 < x < y. + + Tor has retained this feature, but has not yet made use of it. + +3. Design + + Every bridge currently chooses a set of guard nodes for its + circuits. Bridges should also re-route client circuits through + these circuits. + + Specifically, when a bridge receives a request from a client to + extend a circuit, it should first create a circuit to its guard, + and then relay that extend cell through the guard. The bridge + should add an additional layer of encryption to outgoing cells on + that circuit corresponding to the encryption that the guard will + remove, and remove a layer of encryption on incoming cells on that + circuit corresponding to the encryption that the guard will add. + +3.1. An example + + This example doesn't add anything to the design above, but has some + interesting inline notes. + + - Alice has connected to her bridge Bob, and built a circuit + through Bob, with the negotiated forward and reverse keys KB_f + and KB_r. + + - Alice then wants to extend the circuit to node Charlie. She + makes a hybrid-encrypted onionskin, encrypted to Charlie's + public key, containing her chosen g^x value. She puts this in + an extend cell: "Extend (Charlie's address) (Charlie's OR + Port) (Onionskin) (Charlie's ID)". She encrypts this with + KB_f and sends it as a RELAY_EARLY cell to Bob. + + - Bob receives the RELAY_EARLY cell, and decrypts it with KB_f. + He then sees that it's an extend cell for him. + + So far, this is exactly the same as the current procedure that + Alice and Bob would follow. Now we diverge: + + - Instead of connecting to Charlie directly, Bob makes sure that + he is connected to his guard, Guillaume. Bob uses a + CREATE_FAST cell (or a CREATE cell, but see 4.1 below) to open a + circuit to Guillaume. Now Bob and Guillaume share keys KG_f + and KG_b. + + - Now Bob encrypts the Extend cell body with KG_f and sends it + as a RELAY_EARLY cell to Guillaume. + + - Guillaume receives it, decrypts it with KG_f, and sees: + "Extend (Charlie's address) (Charlie's OR Port) (Onionskin) + (Charlie's ID)". Guillaume acts accordingly: creating a + connection to Charlie if he doesn't have one, ensuring that + the ID is as expected, and then sending the onionskin in a + create cell on that connection. + + Note that Guillaume is behaving exactly as a regular node + would upon receiving an Extend cell. + + - Now the handshake finishes. Charlie receives the onionskin + and sends Guillaume "CREATED g^y,KH". Guillaume sends Bob + "E(KG_r, EXTENDED g^y KH)". (Charlie and Guillaume are still + running as regular Tor nodes do today). + + - With this extend cell, and with all future relay cells + received on this circuit, Bob first decrypts the cell with + KG_r, then re-encrypts it with KB_r, then passes it to Alice. + When Alice receives the cell, it will be just as she would + have received if Bob had extended to Charlie directly. + + - With all future outgoing cells that he receives from Alice, + Bob first decrypts the cell with KA_f, and if the cell does + not have Bob as its destination, Bob encrypts it with KG_f + before passing it to Guillaume. + + Note that this design does not require that our stream cipher + operations be transitive, even though they are. + + Note also that this design requires no change in behavior from any + node other than Bob the bridge. + + Finally, observe that even though the circuit is one hop longer + than it would be otherwise, no relay's count of permissible + RELAY_EARLY cells falls lower than it otherwise would. This is + because the extra hop that Bob adds is done with a CREATE_FAST + cell, and so he does not need to send any RELAY_EARLY cells not + originated by Alice. + +4. Other ideas and alternative designs + + In addition to the design above, there are more ways to try to + prevent enumeration. + +4.1. Make it harder to tell clients from bridges + + Right now, there are multiple ways for the node after a bridge to + distinguish a circuit extended through the bridge from one + originating at the bridge. (This lets the node after the bridge + tell that a bridge is talking to it.) + + One of the giveaways here is that the first hop in a circuit is + created with CREATE_FAST cells, but all subsequent hops are created + with CREATE cells. In the above design, it's no longer quite so + simple to tell, since all of the circuits that extend through a + bridge now reach its guards through CREATE_FAST cells, whether the + bridge originated them or not. + + (If we adopt a faster circuit extension algorithm -- for example, + Goldberg, Stebila, and Ustaoglu's design instantiated over + curve25519 -- we could also solve this issue by eliminating + CREATE_FAST/CREATED_FAST entirely, which would also help our + security margin a little.) + + The CREATE/CREATE_FAST distinction is not the only way for a + bridge's guard to tell bridges from orginary clients, however. + Most importantly, a busy bridge will open far more circuits than a + client would. More subtly, the timing on response from the client + will be higher and more highly variable that it would be with an + ordinary client. I don't think we can make bridges behave wholly + indistinguishably from clients: that's why we should go with guard + nodes for bridges. + +4.2. Client-enforced bridge guards + + What if Tor didn't have loose source routing? We could have + bridges tell clients what guards to use by advertising those guard + in their descriptors, and then refusing to extend circuits to any + other nodes. This change would require all clients to upgrade in + order to be able to use the newer bridges, and would quite possibly + cause a fair amount of pain along the way. + + Fortunately, we don't need to go down this path. So let's not! + +4.3. Separate bridge-guards and client-guards + + In the design above, I specify that bridges should use the same + guard nodes for extending client circuits as they use for their own + circuits. It's not immediately clear whether this is a good idea + or not. Having separate sets would seem to make the two kinds of + circuits more easily distinguishable (even though we already assume + they are distinguishable). Having different sets of guards would + also seem like a way to keep the nodes who guard our own traffic + from learning that we're a bridge... but another set of nodes will + learn that anyway, so it's not clear what we'd gain. + +5. Other considerations + + What fraction of our traffic is bridge traffic? Will this alter + our circuit selection weights? + + Are the current guard selection/evaluation/replacement mechanisms + adequate for bridge guards, or do bridges need to get more + sophisticated?

1 0

[pytorctl/master] Bug #4097: Clear old last_exit before requesting a new one
by mikeperry＠torproject.org 20 Oct '11

20 Oct '11

commit e15ed99df8e8e04cadd0f3792e42a621df6fbe02 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Wed Oct 19 16:32:34 2011 -0700 Bug #4097: Clear old last_exit before requesting a new one Should eliminate the keyerror in the test's node_map, which seemed to be due to really stale last_exits laying around from previous tests on a different consensus. --- ScanSupport.py | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/ScanSupport.py b/ScanSupport.py index 8985fd7..e6752c5 100644 --- a/ScanSupport.py +++ b/ScanSupport.py @@ -164,6 +164,8 @@ class ScanHandler(PathSupport.PathBuilder): def notlambda(sm): plog("DEBUG", "Job for setexit: "+exit_name) cond.acquire() + # Clear last successful exit, we're running a new test + self.last_exit = None sm.set_exit(exit_name) cond.notify() cond.release()

1 0

[translation/vidalia] Update translations for vidalia
by translation＠torproject.org 20 Oct '11

20 Oct '11

commit 05d030f94786388d53f9a92b5a7bed7eeea78bf6 Author: Translation commit bot <translation(a)torproject.org> Date: Wed Oct 19 23:28:45 2011 +0000 Update translations for vidalia --- sr/vidalia_sr.po | 52 ++++++++++++++++++++++++++-------------------------- 1 files changed, 26 insertions(+), 26 deletions(-) diff --git a/sr/vidalia_sr.po b/sr/vidalia_sr.po index c90558f..51c5065 100644 --- a/sr/vidalia_sr.po +++ b/sr/vidalia_sr.po @@ -8,7 +8,7 @@ msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: https://trac.torproject.org/projects/tor\n" "POT-Creation-Date: 2011-09-07 14:40+0000\n" -"PO-Revision-Date: 2011-10-19 22:52+0000\n" +"PO-Revision-Date: 2011-10-19 23:09+0000\n" "Last-Translator: sdpuls <sdpuls(a)gmail.com>\n" "Language-Team: translations(a)vidalia-project.net\n" "MIME-Version: 1.0\n" @@ -1565,11 +1565,11 @@ msgstr "Лиценца" msgctxt "LicenseDialog" msgid "Credits" -msgstr "" +msgstr "Кредити" msgctxt "LogEvent" msgid "Debug" -msgstr "" +msgstr "Oтклањање грешке" msgctxt "LogEvent" msgid "Info" @@ -1577,7 +1577,7 @@ msgstr "Инфо" msgctxt "LogEvent" msgid "Notice" -msgstr "" +msgstr "Напомена" msgctxt "LogEvent" msgid "Warning" @@ -1625,15 +1625,15 @@ msgstr "Излаз" msgctxt "MainWindow" msgid "Bandwidth Graph" -msgstr "" +msgstr "Графикон протока" msgctxt "MainWindow" msgid "Message Log" -msgstr "" +msgstr "Дневник порука" msgctxt "MainWindow" msgid "Network Map" -msgstr "" +msgstr "Карта мреже" msgctxt "MainWindow" msgid "Control Panel" @@ -1645,7 +1645,7 @@ msgstr "Подешавања" msgctxt "MainWindow" msgid "About" -msgstr "" +msgstr "О нама" msgctxt "MainWindow" msgid "Help" @@ -1697,55 +1697,55 @@ msgstr "Видалиа Помоћ" msgctxt "MainWindow" msgid "Error starting web browser" -msgstr "" +msgstr "Грешка покретања веб претраживача" msgctxt "MainWindow" msgid "Vidalia was unable to start the configured web browser" -msgstr "" +msgstr "Видалиа није могао да почне конфигурисање веб претраживача" msgctxt "MainWindow" msgid "Error starting IM client" -msgstr "" +msgstr "Грешка покретање ИМ клијента" msgctxt "MainWindow" msgid "Vidalia was unable to start the configured IM client" -msgstr "" +msgstr "Видалиа није могао да почне конфигурисање клијента за ћаскање" msgctxt "MainWindow" msgid "Error starting proxy server" -msgstr "" +msgstr "Грешка покретање прокси сервера" msgctxt "MainWindow" msgid "Vidalia was unable to start the configured proxy server" -msgstr "" +msgstr "Видалиа није могао да почне конфигурисање прокси сервера" msgctxt "MainWindow" msgid "Connecting to a relay directory" -msgstr "" +msgstr "Повезивање са релеј директоријумом" msgctxt "MainWindow" msgid "Establishing an encrypted directory connection" -msgstr "" +msgstr "Успостављање шифроване везе директоријума" msgctxt "MainWindow" msgid "Retrieving network status" -msgstr "" +msgstr "Преузимање мрежног статуса" msgctxt "MainWindow" msgid "Loading network status" -msgstr "" +msgstr "Учитавање мрежног статуса" msgctxt "MainWindow" msgid "Loading authority certificates" -msgstr "" +msgstr "Преузимање сертификата ауторитета" msgctxt "MainWindow" msgid "Requesting relay information" -msgstr "" +msgstr "Захтев за пренос информације" msgctxt "MainWindow" msgid "Loading relay information" -msgstr "" +msgstr "Учитавање преноса информације" msgctxt "MainWindow" msgid "Connecting to the Tor network" @@ -1753,7 +1753,7 @@ msgstr "Повезивање на Тор мрежу" msgctxt "MainWindow" msgid "Establishing a Tor circuit" -msgstr "" +msgstr "Успостављање Тор круга" msgctxt "MainWindow" msgid "Connected to the Tor network!" @@ -1761,19 +1761,19 @@ msgstr "Повезан са Тор мрежом!" msgctxt "MainWindow" msgid "Unrecognized startup status" -msgstr "" +msgstr "Непризнат статус покретања" msgctxt "MainWindow" msgid "miscellaneous" -msgstr "" +msgstr "разно" msgctxt "MainWindow" msgid "identity mismatch" -msgstr "" +msgstr "идентитет неусклађен" msgctxt "MainWindow" msgid "done" -msgstr "" +msgstr "ради" msgctxt "MainWindow" msgid "connection refused"

1 0

[translation/vidalia] Update translations for vidalia
by translation＠torproject.org 20 Oct '11

20 Oct '11

commit f9b90d63aef1bc8c12f6067d7125183aeb373c5c Author: Translation commit bot <translation(a)torproject.org> Date: Wed Oct 19 22:54:41 2011 +0000 Update translations for vidalia --- sr/vidalia_sr.po | 53 +++++++++++++++++++++++++++++------------------------ 1 files changed, 29 insertions(+), 24 deletions(-) diff --git a/sr/vidalia_sr.po b/sr/vidalia_sr.po index 98cb628..c90558f 100644 --- a/sr/vidalia_sr.po +++ b/sr/vidalia_sr.po @@ -8,7 +8,7 @@ msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: https://trac.torproject.org/projects/tor\n" "POT-Creation-Date: 2011-09-07 14:40+0000\n" -"PO-Revision-Date: 2011-10-19 21:53+0000\n" +"PO-Revision-Date: 2011-10-19 22:52+0000\n" "Last-Translator: sdpuls <sdpuls(a)gmail.com>\n" "Language-Team: translations(a)vidalia-project.net\n" "MIME-Version: 1.0\n" @@ -1327,11 +1327,11 @@ msgstr "Изабери Извршни прокси" msgctxt "GeneralPage" msgid "You must specify the name of your Tor executable." -msgstr "" +msgstr "Морате навести име Тор извршне датотеке." msgctxt "GeneralPage" msgid "Start Vidalia when my system starts" -msgstr "" +msgstr "Почетак Видалиа када мој систем почне" msgctxt "GeneralPage" msgid "Browse" @@ -1355,39 +1355,39 @@ msgstr "Покрени прокси апликацију када се покр msgctxt "GeneralPage" msgid "Proxy Application Arguments:" -msgstr "" +msgstr "Аргументи прокси апликације:" msgctxt "GeneralPage" msgid "Software Updates" -msgstr "" +msgstr "Ажурирање софтвера" msgctxt "GeneralPage" msgid "Check for new software updates automatically" -msgstr "" +msgstr "Проверите да ли је нови софтвер доступан" msgctxt "GeneralPage" msgid "Check Now" -msgstr "" +msgstr "Провери одмах" msgctxt "GraphFrame" msgid "%1 KB/s" -msgstr "" +msgstr "%1 КБ/с" msgctxt "GraphFrame" msgid "%1 KB" -msgstr "" +msgstr "%1 КБ" msgctxt "GraphFrame" msgid "%1 MB" -msgstr "" +msgstr "%1 МБ" msgctxt "GraphFrame" msgid "%1 GB" -msgstr "" +msgstr "%1 ГБ" msgctxt "GraphFrame" msgid "Recv:" -msgstr "" +msgstr "Преузето:" msgctxt "GraphFrame" msgid "Sent:" @@ -1395,15 +1395,15 @@ msgstr "Послато:" msgctxt "HelpBrowser" msgid "Supplied XML file is not a valid Contents document." -msgstr "" +msgstr "Испоручен XML фајл није валидан садржај документа." msgctxt "HelpBrowser" msgid "Search reached end of document" -msgstr "" +msgstr "Тражилац достигао крај документа" msgctxt "HelpBrowser" msgid "Search reached start of document" -msgstr "" +msgstr "Тражилац достигао почетак документа" msgctxt "HelpBrowser" msgid "Text not found in document" @@ -1411,7 +1411,7 @@ msgstr "Текст није пронађен у документу" msgctxt "HelpBrowser" msgid "Found %1 results" -msgstr "" +msgstr "Пронађено %1 резултата" msgctxt "HelpBrowser" msgid "Vidalia Help" @@ -1431,7 +1431,7 @@ msgstr "Backspace " msgctxt "HelpBrowser" msgid "Forward" -msgstr "" +msgstr "Напред" msgctxt "HelpBrowser" msgid "Move to next page (Shift+Backspace)" @@ -1463,7 +1463,7 @@ msgstr "Тражи реч или фразу на тренутној страни msgctxt "HelpBrowser" msgid "Ctrl+F" -msgstr "" +msgstr "ЦТРЛ + Ф" msgctxt "HelpBrowser" msgid "Close" @@ -1491,7 +1491,7 @@ msgstr "Пронађи Следеће" msgctxt "HelpBrowser" msgid "Case sensitive" -msgstr "" +msgstr "Велика и мала слова" msgctxt "HelpBrowser" msgid "Whole words only" @@ -1499,7 +1499,7 @@ msgstr "Само целе речи" msgctxt "HelpBrowser" msgid "Help Topics" -msgstr "" +msgstr "Помоћ Теме" msgctxt "HelpBrowser" msgid "Contents" @@ -1519,11 +1519,11 @@ msgstr "Пронађени Документи" msgctxt "HelpBrowser" msgid "Error Loading Help Contents:" -msgstr "" +msgstr "Грешка при учитавању Помоћног Садржаја:" msgctxt "HelpTextBrowser" msgid "Opening External Link" -msgstr "" +msgstr "Отварање Спољног линка" msgctxt "HelpTextBrowser" msgid "" @@ -1531,10 +1531,13 @@ msgid "" "browser is not currently configured to use Tor then the request will not be " "anonymous." msgstr "" +"Видалиа неможе да отворим линк који сте одабрали у Вашем подразумеваном Веб " +"читачу. Уколико ваш прегледач тренутно није конфигурисан да користи Тор онда" +" захтев неће бити анонимна." msgctxt "HelpTextBrowser" msgid "Do you want Vidalia to open the link in your Web browser?" -msgstr "" +msgstr "Да ли желите да Видалиа отворили линк у вашем веб читачу?" msgctxt "HelpTextBrowser" msgid "Unable to Open Link" @@ -1545,10 +1548,12 @@ msgid "" "Vidalia was unable to open the selected link in your Web browser. You can " "still copy the URL and paste it into your browser." msgstr "" +"Видалиа није могао да отвори изабрану везу у Веб прегледачу. Још увек можете" +" да копирате УРЛ адресу и налепите га у свом прегледачу." msgctxt "HelpTextBrowser" msgid "Error opening help file:" -msgstr "" +msgstr "Грешка при отварању фајла за помоћ:" msgctxt "LicenseDialog" msgid "License Information"

1 0

[translation/vidalia] Update translations for vidalia
by translation＠torproject.org 20 Oct '11

20 Oct '11

commit 916fe46645032ae68ec56fa990d8ce6f86fee99e Author: Translation commit bot <translation(a)torproject.org> Date: Wed Oct 19 22:25:27 2011 +0000 Update translations for vidalia --- sr/vidalia_sr.po | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sr/vidalia_sr.po b/sr/vidalia_sr.po index 7b1acf7..98cb628 100644 --- a/sr/vidalia_sr.po +++ b/sr/vidalia_sr.po @@ -8,7 +8,7 @@ msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: https://trac.torproject.org/projects/tor\n" "POT-Creation-Date: 2011-09-07 14:40+0000\n" -"PO-Revision-Date: 2011-10-19 21:48+0000\n" +"PO-Revision-Date: 2011-10-19 21:53+0000\n" "Last-Translator: sdpuls <sdpuls(a)gmail.com>\n" "Language-Team: translations(a)vidalia-project.net\n" "MIME-Version: 1.0\n" @@ -1315,15 +1315,15 @@ msgstr "" msgctxt "GeneralPage" msgid "Executables (*.exe)" -msgstr "" +msgstr "Извршне (*. exe)" msgctxt "GeneralPage" msgid "Select Path to Tor" -msgstr "" +msgstr "Одаберите Путању за Тор" msgctxt "GeneralPage" msgid "Select Proxy Executable" -msgstr "" +msgstr "Изабери Извршни прокси" msgctxt "GeneralPage" msgid "You must specify the name of your Tor executable."

1 0

[translation/vidalia] Update translations for vidalia
by translation＠torproject.org 20 Oct '11

20 Oct '11

commit 8ef27373c922c245e5fd07237ac652ced5c21171 Author: Translation commit bot <translation(a)torproject.org> Date: Wed Oct 19 21:54:24 2011 +0000 Update translations for vidalia --- sr/vidalia_sr.po | 50 +++++++++++++++++++++++++------------------------- 1 files changed, 25 insertions(+), 25 deletions(-) diff --git a/sr/vidalia_sr.po b/sr/vidalia_sr.po index 379a413..7b1acf7 100644 --- a/sr/vidalia_sr.po +++ b/sr/vidalia_sr.po @@ -8,7 +8,7 @@ msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: https://trac.torproject.org/projects/tor\n" "POT-Creation-Date: 2011-09-07 14:40+0000\n" -"PO-Revision-Date: 2011-10-19 20:39+0000\n" +"PO-Revision-Date: 2011-10-19 21:48+0000\n" "Last-Translator: sdpuls <sdpuls(a)gmail.com>\n" "Language-Team: translations(a)vidalia-project.net\n" "MIME-Version: 1.0\n" @@ -117,11 +117,11 @@ msgstr "Тор конфигурациона датотека" msgctxt "AdvancedPage" msgid "Start the Tor software with the specified configuration file (torrc)" -msgstr "Покрени Тор софтвер са наведеним конфигурационим фајлом" +msgstr "Покрени Тор са наведеним конфигурационим фајлом (torrc)" msgctxt "AdvancedPage" msgid "Select path to your configuration file" -msgstr "" +msgstr "Изабери путању конфигурационог фајла" msgctxt "AdvancedPage" msgid "Browse" @@ -137,7 +137,7 @@ msgstr "Ускладишти податке за Tor програм у след msgctxt "AdvancedPage" msgid "Select the directory used to store data for the Tor software" -msgstr "" +msgstr "Изаберите директоријум који се користи за складиштење података за Тор" msgctxt "AdvancedPage" msgid "Tor Control" @@ -222,7 +222,7 @@ msgstr "Стил" msgctxt "AppearancePage" msgid "Choose Vidalia's interface style" -msgstr "" +msgstr "Изабери Видалиа окружење интерфејса" msgctxt "AppearancePage" msgid "Vidalia was unable to load the selected language translation." @@ -242,7 +242,7 @@ msgstr "Прикажи Подешавања" msgctxt "BandwidthGraph" msgid "Tor Bandwidth Usage" -msgstr "" +msgstr "Тор пропусни опсег" msgctxt "BandwidthGraph" msgid "Reset" @@ -266,7 +266,7 @@ msgstr "Стил" msgctxt "BandwidthGraph" msgid "Changes the transparency of the Bandwidth Graph" -msgstr "" +msgstr "Промене транспарентност графике протока" msgctxt "BandwidthGraph" msgid "100" @@ -274,7 +274,7 @@ msgstr "100" msgctxt "BandwidthGraph" msgid "% Opaque" -msgstr "" +msgstr "% Непрозиран" msgctxt "BandwidthGraph" msgid "Save" @@ -306,11 +306,11 @@ msgstr "Преузимање Мостова" msgctxt "BridgeDownloaderProgressDialog" msgid "Unable to download bridges: %1" -msgstr "" +msgstr "Није могуће преузети мостове:%1" msgctxt "BridgeDownloaderProgressDialog" msgid "Retrying bridge request..." -msgstr "" +msgstr "Поновни покушај захтева за мост ..." msgctxt "BridgeUsageDialog" msgid "Country" @@ -322,15 +322,15 @@ msgstr "# Клијенти" msgctxt "BridgeUsageDialog" msgid "Clients from the following countries have used your relay since %1" -msgstr "" +msgstr "Клијенти из следећих земаља су користили релеј од%1" msgctxt "BridgeUsageDialog" msgid "Bridge Usage Summary" -msgstr "" +msgstr "Преглед употребе Моста" msgctxt "BridgeUsageDialog" msgid "Client Summary" -msgstr "" +msgstr "Преглед Клијената" msgctxt "Circuit" msgid "New" @@ -342,7 +342,7 @@ msgstr "Отворено" msgctxt "Circuit" msgid "Building" -msgstr "" +msgstr "Изгради" msgctxt "Circuit" msgid "Failed" @@ -370,11 +370,11 @@ msgstr "Статус" msgctxt "CircuitListWidget" msgid "Zoom to Circuit" -msgstr "" +msgstr "Зумирање у кругу" msgctxt "CircuitListWidget" msgid "Close Circuit (Del)" -msgstr "" +msgstr "Затвори круг (ДЕЛ)" msgctxt "CircuitListWidget" msgid "Close Stream (Del)" @@ -402,7 +402,7 @@ msgstr "Изглед" msgctxt "ConfigDialog" msgid "Advanced" -msgstr "" +msgstr "Напредан" msgctxt "ConfigDialog" msgid "Help" @@ -410,19 +410,19 @@ msgstr "Помоћ" msgctxt "ConfigDialog" msgid "Error Saving Settings" -msgstr "" +msgstr "Грешка чувања подешавања" msgctxt "ConfigDialog" msgid "Vidalia was unable to save your %1 settings." -msgstr "" +msgstr "Видалиа није био у могућности да сачува%1 поставке." msgctxt "ConfigDialog" msgid "Error Applying Settings" -msgstr "" +msgstr "Грешка Примене подешавања" msgctxt "ConfigDialog" msgid "Vidalia was unable to apply your %1 settings to Tor." -msgstr "" +msgstr "Видалиа није био у могућности да примени%1 подешавање на Тор." msgctxt "ConfigDialog" msgid "Settings" @@ -434,7 +434,7 @@ msgstr "Vidalia није могао да се повеже са Tor. (%1)" msgctxt "ControlConnection" msgid "Control socket is not connected." -msgstr "" +msgstr "Контролна утичница није повезана." msgctxt "ControlPasswordInputDialog" msgid "Password Required" @@ -454,7 +454,7 @@ msgstr "" msgctxt "ControlSocket" msgid "Control socket is not connected." -msgstr "" +msgstr "Контролна утичница није повезан." msgctxt "ControlSocket" msgid "Error sending control command. [%1]" @@ -462,11 +462,11 @@ msgstr "Грешка при слању контролне команде. [%1]" msgctxt "ControlSocket" msgid "Socket disconnected while attempting to read a line of data." -msgstr "" +msgstr "Утичница прекинута док је покушавала да прочита линију података." msgctxt "ControlSocket" msgid "Invalid control reply. [%1]" -msgstr "" +msgstr "Неважећи контролни одговор. [%1]" msgctxt "CountryInfo" msgid "Afghanistan"

1 0

[translation/vidalia] Update translations for vidalia
by translation＠torproject.org 20 Oct '11

20 Oct '11

commit 38d8d4b91327930a7ed44a765601ebd30243e990 Author: Translation commit bot <translation(a)torproject.org> Date: Wed Oct 19 20:55:13 2011 +0000 Update translations for vidalia --- sr/vidalia_sr.po | 21 +++++++++++---------- 1 files changed, 11 insertions(+), 10 deletions(-) diff --git a/sr/vidalia_sr.po b/sr/vidalia_sr.po index 4953707..379a413 100644 --- a/sr/vidalia_sr.po +++ b/sr/vidalia_sr.po @@ -1,14 +1,15 @@ # # Translators: # runasand <runa.sandvik(a)gmail.com>, 2011. +# <sdpuls(a)gmail.com>, 2011. # Vanja <medjutim(a)yahoo.com>, 2011. msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: https://trac.torproject.org/projects/tor\n" "POT-Creation-Date: 2011-09-07 14:40+0000\n" -"PO-Revision-Date: 2011-09-08 00:47+0000\n" -"Last-Translator: runasand <runa.sandvik(a)gmail.com>\n" +"PO-Revision-Date: 2011-10-19 20:39+0000\n" +"Last-Translator: sdpuls <sdpuls(a)gmail.com>\n" "Language-Team: translations(a)vidalia-project.net\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -44,11 +45,11 @@ msgstr "„%1“ није исправна IP адреса." msgctxt "AdvancedPage" msgid "" "You selected 'Password' authentication, but did not specify a password." -msgstr "" +msgstr "Изабрали сте проверу 'Лозинком', али нисте изабрали лозинку." msgctxt "AdvancedPage" msgid "Select Tor Configuration File" -msgstr "" +msgstr "Изаберите Тор Конфигурациону датотеку" msgctxt "AdvancedPage" msgid "File Not Found" @@ -56,7 +57,7 @@ msgstr "Датотека није пронађена" msgctxt "AdvancedPage" msgid "%1 does not exist. Would you like to create it?" -msgstr "" +msgstr "%1 не постоји. Да ли желите да креирате." msgctxt "AdvancedPage" msgid "Failed to Create File" @@ -64,15 +65,15 @@ msgstr "Није успео да креира датотеку" msgctxt "AdvancedPage" msgid "Unable to create %1 [%2]" -msgstr "" +msgstr "Није могуће креирати %1 [%2]" msgctxt "AdvancedPage" msgid "Select a Directory to Use for Tor Data" -msgstr "" +msgstr "Изабери директоријум који ћете користити за Тор податке" msgctxt "AdvancedPage" msgid "Unable to remove Tor Service" -msgstr "" +msgstr "Немогуће је уклонити Тор сервис" msgctxt "AdvancedPage" msgid "Unable to install Tor Service" @@ -112,11 +113,11 @@ msgstr ": " msgctxt "AdvancedPage" msgid "Tor Configuration File" -msgstr "" +msgstr "Тор конфигурациона датотека" msgctxt "AdvancedPage" msgid "Start the Tor software with the specified configuration file (torrc)" -msgstr "" +msgstr "Покрени Тор софтвер са наведеним конфигурационим фајлом" msgctxt "AdvancedPage" msgid "Select path to your configuration file"

1 0