December 2019 - tor-commits - lists.torproject.org

[community/master] one sentence per line, needed for localization
by emmapeel＠torproject.org 02 Dec '19

02 Dec '19

commit 4ef2beae3f6cb2c48f7026082f770b5a016224ef Author: emma peel <emma.peel(a)riseup.net> Date: Mon Dec 2 19:14:10 2019 +0100 one sentence per line, needed for localization --- .../bridge/debian-ubuntu/contents.lr | 13 +++---- .../technical-setup/bridge/docker/contents.lr | 45 ++++++++-------------- 2 files changed, 22 insertions(+), 36 deletions(-) diff --git a/content/relay-operations/technical-setup/bridge/debian-ubuntu/contents.lr b/content/relay-operations/technical-setup/bridge/debian-ubuntu/contents.lr index 7f302c6..b6c57cd 100644 --- a/content/relay-operations/technical-setup/bridge/debian-ubuntu/contents.lr +++ b/content/relay-operations/technical-setup/bridge/debian-ubuntu/contents.lr @@ -25,17 +25,16 @@ If not, you can [build it from source](https://gitlab.com/yawning/obfs4#installa ``` BridgeRelay 1 -# Replace "TODO1" with a Tor port of your choice. This port must be externally -# reachable. Avoid port 9001 because it's commonly associated with Tor and -# censors may be scanning the Internet for this port. +# Replace "TODO1" with a Tor port of your choice. +# This port must be externally reachable. +# Avoid port 9001 because it's commonly associated with Tor and censors may be scanning the Internet for this port. ORPort TODO1 ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy -# Replace "TODO2" with an obfs4 port of your choice. This port must be -# externally reachable and must be different from the one specified for ORPort. -# Avoid port 9001 because it's commonly associated with -# Tor and censors may be scanning the Internet for this port. +# Replace "TODO2" with an obfs4 port of your choice. +# This port must be externally reachable and must be different from the one specified for ORPort. +# Avoid port 9001 because it's commonly associated with Tor and censors may be scanning the Internet for this port. ServerTransportListenAddr obfs4 0.0.0.0:TODO2 # Local communication port between Tor and obfs4. Always set this to "auto". diff --git a/content/relay-operations/technical-setup/bridge/docker/contents.lr b/content/relay-operations/technical-setup/bridge/docker/contents.lr index 272afcf..4f88a69 100644 --- a/content/relay-operations/technical-setup/bridge/docker/contents.lr +++ b/content/relay-operations/technical-setup/bridge/docker/contents.lr @@ -8,8 +8,8 @@ body: ### 1. Pull the image -We are maintaining a docker image that runs an obfs4 bridge. First, -download the image: +We are maintaining a docker image that runs an obfs4 bridge. +First, download the image: ``` docker pull phwinter/obfs4-bridge:latest @@ -17,10 +17,9 @@ docker pull phwinter/obfs4-bridge:latest ### 2. Deploy a container -We provide a Makefile that helps you deploy the container. First, -[download the Makefile](https://dip.torproject.org/torproject/anti-censorship/docker-obfs…, -and then write your bridge configuration to a new file, bridge.sh. Here's a -template: +We provide a Makefile that helps you deploy the container. +First, [download the Makefile](https://dip.torproject.org/torproject/anti-censorship/docker-obfs…, and then write your bridge configuration to a new file, bridge.sh. +Here's a template: ``` # Your bridge's Tor port. @@ -31,9 +30,7 @@ export PT_PORT=Y export EMAIL=Z ``` -Replace `X` with your desired OR port, `Y` with your obfs4 port (make sure that -**both** ports are forwarded in your firewall), and `Z` with your email address, -which allows us to get in touch with you if there are problems with your bridge. +Replace `X` with your desired OR port, `Y` with your obfs4 port (make sure that **both** ports are forwarded in your firewall), and `Z` with your email address, which allows us to get in touch with you if there are problems with your bridge. With your bridge configuration in place, you can now deploy the container: ``` @@ -47,12 +44,9 @@ You should now see output similar to the following: Make sure that port X and Y are forwarded in your firewall. ``` -That's it! Your container (identified by the first line of output) is now -bootstrapping your new obfs4 bridge. +That's it! Your container (identified by the first line of output) is now bootstrapping your new obfs4 bridge. -If you want to run multiple bridges on your machine, you need to create more -bridge configuration files with different sets of ports, and run `make deploy` -again, like so: +If you want to run multiple bridges on your machine, you need to create more bridge configuration files with different sets of ports, and run `make deploy` again, like so: ``` source bridge-1.sh && make deploy @@ -62,8 +56,7 @@ source bridge-2.sh && make deploy ### 3. Upgrade your container -To upgrade to the latest version of our image, you need to stop your existing -container, delete it, pull the latest image, and finally deploy it again: +To upgrade to the latest version of our image, you need to stop your existing container, delete it, pull the latest image, and finally deploy it again: ``` docker stop CONTAINER_ID @@ -72,13 +65,9 @@ docker pull phwinter/obfs4-bridge:latest source bridge.sh && make deploy ``` -Note that your bridge's data directory (which includes its key material) is -stored in a docker volume, so you won't lose your bridge's identity when -upgrading to the latest docker image. If you are running multiple bridges on -your computer, you need to repeat this step for each bridge. We will announce -new image versions on the -[tor-dev](https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev) mailing -list. +Note that your bridge's data directory (which includes its key material) is stored in a docker volume, so you won't lose your bridge's identity when upgrading to the latest docker image. +If you are running multiple bridges on your computer, you need to repeat this step for each bridge. +We will announce new image versions on the [tor-dev](https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev) mailing list. ### 4. Monitor your logs @@ -88,8 +77,8 @@ You can inspect your bridge's logs by running: docker logs CONTAINER_ID ``` -To use your new bridge in Tor Browser, you need its "bridge line". Here's how -you can get your bridge line: +To use your new bridge in Tor Browser, you need its "bridge line". +Here's how you can get your bridge line: ``` docker exec CONTAINER_ID get-bridge-line @@ -101,10 +90,8 @@ This will return a string similar to the following: obfs4 1.2.3.4:1234 B0E566C9031657EA7ED3FC9D248E8AC4F37635A4 cert=OYWq67L7MDApdJCctUAF7rX8LHvMxvIBPHOoAp0+YXzlQdsxhw6EapaMNwbbGICkpY8CPQ iat-mode=0 ``` -Make sure to check out the [post-install -notes](https://community.torproject.org/relay/setup/bridge/post-install/). If -you are having troubles setting up your bridge, have a look at [our help -section](https://community.torproject.org/relay/getting-help/). +Make sure to check out the [post-install notes](https://community.torproject.org/relay/setup/bridge/post-install/). +If you are having troubles setting up your bridge, have a look at [our help section](https://community.torproject.org/relay/getting-help/). --- html: two-columns-page.html

1 0

[translation/tails-iuk] https://gitweb.torproject.org/translation.git/commit/?h=tails-iuk
by translation＠torproject.org 02 Dec '19

02 Dec '19

commit 1ce52d402d9aed6b1b53fee386f5ab56749d1f75 Author: Translation commit bot <translation(a)torproject.org> Date: Mon Dec 2 17:48:41 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=tails-iuk --- pt_BR.po | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/pt_BR.po b/pt_BR.po index 5112bc2c7e..15982d6880 100644 --- a/pt_BR.po +++ b/pt_BR.po @@ -7,6 +7,7 @@ # carlo giusepe tadei valente sasaki <carlo.gt.valente(a)gmail.com>, 2014 # Chacal E., 2019 # drebs <drebs(a)riseup.net>, 2014 +# Eduardo Addad de Oliveira <eduardoaddad(a)hotmail.com>, 2019 # Eduardo Bonsi, 2013 # Glauco Machado, 2014 # Isabel Ferreira, 2014 @@ -15,8 +16,8 @@ msgstr "" "Project-Id-Version: Tor Project\n" "Report-Msgid-Bugs-To: Tails developers <tails(a)boum.org>\n" "POT-Creation-Date: 2019-11-28 16:51+0100\n" -"PO-Revision-Date: 2019-11-29 03:10+0000\n" -"Last-Translator: carolyn <carolyn(a)anhalt.org>\n" +"PO-Revision-Date: 2019-12-02 17:42+0000\n" +"Last-Translator: Eduardo Addad de Oliveira <eduardoaddad(a)hotmail.com>\n" "Language-Team: Portuguese (Brazil) (http://www.transifex.com/otf/torproject/language/pt_BR/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -50,7 +51,7 @@ msgstr "No nosso website, nenhuma atualização automática para essa versão es #: ../lib/Tails/IUK/Frontend.pm:242 msgid "your device was not created using a USB image or Tails Installer" -msgstr "" +msgstr "seu dispositivo não foi criado usando uma imagem USB ou o Tails Installer" #: ../lib/Tails/IUK/Frontend.pm:247 msgid "Tails was started from a DVD or a read-only device"

1 0

[translation/support-portal] https://gitweb.torproject.org/translation.git/commit/?h=support-portal
by translation＠torproject.org 02 Dec '19

02 Dec '19

commit 6d29173f4608b830d03f9faf048a9661623b8412 Author: Translation commit bot <translation(a)torproject.org> Date: Mon Dec 2 16:53:27 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=support-portal --- contents+it.po | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/contents+it.po b/contents+it.po index 84b4aa36ae..e4312f64ba 100644 --- a/contents+it.po +++ b/contents+it.po @@ -9,12 +9,12 @@ # mattia_b89 <mattia.b89(a)gmail.com>, 2019 # erinm, 2019 # Giuseppe Curto <giuseppe.curto(a)gmail.com>, 2019 -# Davide Sant <spuuu(a)outlook.it>, 2019 # SebastianoPistore <SebastianoPistore.info(a)protonmail.ch>, 2019 # Giandomenico Lombardi <transifex.com(a)l1t.it>, 2019 # fabio carletti <fabiocarlettiryuw(a)gmail.com>, 2019 # Luke <94lukecatellani(a)gmail.com>, 2019 # Emma Peel, 2019 +# Davide Sant <spuuu(a)outlook.it>, 2019 # msgid "" msgstr "" @@ -22,7 +22,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2019-11-14 16:04+CET\n" "PO-Revision-Date: 2018-10-02 22:41+0000\n" -"Last-Translator: Emma Peel, 2019\n" +"Last-Translator: Davide Sant <spuuu(a)outlook.it>, 2019\n" "Language-Team: Italian (https://www.transifex.com/otf/teams/1519/it/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -9685,12 +9685,12 @@ msgstr "" #: https//support.torproject.org/get-in-touch/irc-help/ #: (content/get-in-touch/irc-help/contents+en.lrquestion.description) msgid "You should also consider to use an IRC client." -msgstr "" +msgstr "Dovresti considerare anche l'utilizzo di un client IRC." #: https//support.torproject.org/get-in-touch/why-i-cant-join-tor-channels/ #: (content/get-in-touch/why-i-cant-join-tor-channels/contents+en.lrquestion.title) msgid "Why I can't join Tor-dev and other channels?" -msgstr "" +msgstr "Perché non posso connettermi a Tor-dev e agli altri canali?" #: https//support.torproject.org/get-in-touch/why-i-cant-join-tor-channels/ #: (content/get-in-touch/why-i-cant-join-tor-channels/contents+en.lrquestion.description)

1 0

[translation/tbmanual-contentspot] https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot
by translation＠torproject.org 02 Dec '19

02 Dec '19

commit cb21bf532083a98d3bb2550a3ca6aee2049b49e6 Author: Translation commit bot <translation(a)torproject.org> Date: Mon Dec 2 16:49:58 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot --- contents+it.po | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/contents+it.po b/contents+it.po index dc544d327c..ddf52316c5 100644 --- a/contents+it.po +++ b/contents+it.po @@ -1,6 +1,5 @@ # Translators: # Lorenzo Mazza <lor.mazza81(a)outlook.com>, 2019 -# Davide Sant <spuuu(a)outlook.it>, 2019 # Gabriele <gabboxl0(a)gmail.com>, 2019 # mattia_b89 <mattia.b89(a)gmail.com>, 2019 # Hiro 7 <hiro(a)torproject.org>, 2019 @@ -13,6 +12,7 @@ # fabio carletti <fabiocarlettiryuw(a)gmail.com>, 2019 # Random_R, 2019 # Emma Peel, 2019 +# Davide Sant <spuuu(a)outlook.it>, 2019 # msgid "" msgstr "" @@ -20,7 +20,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2019-11-29 10:58+CET\n" "PO-Revision-Date: 2018-11-14 12:31+0000\n" -"Last-Translator: Emma Peel, 2019\n" +"Last-Translator: Davide Sant <spuuu(a)outlook.it>, 2019\n" "Language-Team: Italian (https://www.transifex.com/otf/teams/1519/it/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -95,7 +95,7 @@ msgstr "Avviare il browser Tor per la prima volta" #: https//tb-manual.torproject.org/menu/ #: (content/menu/contents+en.lrtopic.body) msgid "Pluggable transports" -msgstr "Pluggable transport" +msgstr "Pluggable transports" #: https//tb-manual.torproject.org/menu/ #: (content/menu/contents+en.lrtopic.body) @@ -135,7 +135,7 @@ msgstr "Aggiorna" #: https//tb-manual.torproject.org/menu/ #: (content/menu/contents+en.lrtopic.body) msgid "Plugins" -msgstr "Plugin" +msgstr "Plugins" #: https//tb-manual.torproject.org/menu/ #: (content/menu/contents+en.lrtopic.body)

1 0

[tor/master] Topic documentation on our publish-subscribe architecture.
by nickm＠torproject.org 02 Dec '19

02 Dec '19

commit d700dc7801a9e23ddda0d482eeb2b64ced3ca756 Author: Nick Mathewson <nickm(a)torproject.org> Date: Sat Nov 16 14:31:49 2019 -0500 Topic documentation on our publish-subscribe architecture. --- src/core/mainloop/mainloop_pubsub.h | 32 ++++++++ src/lib/pubsub/publish_subscribe.md | 141 ++++++++++++++++++++++++++++++++++++ src/mainpage.md | 3 +- 3 files changed, 175 insertions(+), 1 deletion(-) diff --git a/src/core/mainloop/mainloop_pubsub.h b/src/core/mainloop/mainloop_pubsub.h index bd57c0c17..c02127401 100644 --- a/src/core/mainloop/mainloop_pubsub.h +++ b/src/core/mainloop/mainloop_pubsub.h @@ -14,9 +14,41 @@ struct pubsub_builder_t; +/** + * Describe when and how messages are delivered on message channel. + * + * Every message channel must be associated with one of these strategies. + **/ typedef enum { + /** + * Never deliver messages automatically. + * + * If a message channel uses this strategy, then no matter now many + * messages are published on it, they are not delivered until something + * manually calls dispatch_flush() for that channel + **/ DELIV_NEVER=0, + /** + * Deliver messages promptly, via the event loop. + * + * If a message channel uses this strategy, then publishing a messages + * that channel activates an event that causes messages to be handled + * later in the mainloop. The messages will be processed at some point + * very soon, delaying only for pending IO events and the like. + * + * Generally this is the best choice for a delivery strategy, since + * it avoids stack explosion. + **/ DELIV_PROMPT, + /** + * Deliver messages immediately, skipping the event loop. + * + * Every event on this channel is flushed immediately after it is queued, + * using the stack. + * + * This delivery type should be used with caution, since it can cause + * unexpected call chains, resource starvation, and the like. + **/ DELIV_IMMEDIATE, } deliv_strategy_t; diff --git a/src/lib/pubsub/publish_subscribe.md b/src/lib/pubsub/publish_subscribe.md new file mode 100644 index 000000000..019591bc1 --- /dev/null +++ b/src/lib/pubsub/publish_subscribe.md @@ -0,0 +1,141 @@ + +@page publish_subscribe Publish-subscribe message passing in Tor + +@tableofcontents + +## Introduction + +Tor has introduced a generic publish-subscribe mechanism for delivering +messages internally. It is meant to help us improve the modularity of +our code, by avoiding direct coupling between modules that don't +actually need to invoke one another. + +This publish-subscribe mechanism is *not* meant for handing +multithreading or multiprocess issues, thought we hope that eventually +it might be extended and adapted for that purpose. Instead, we use +publish-subscribe today to decouple modules that shouldn't be calling +each other directly. + +For example, there are numerous parts of our code that might need to +take action when a circuit is completed: a controller might need to be +informed, an onion service negotiation might need to be attached, a +guard might need to be marked as working, or a client connection might +need to be attached. But many of those actions occur at a higher layer +than circuit completion: calling them directly is a layering violation, +and makes our code harder to understand and analyze. + +But with message-passing, we can invert this layering violation: circuit +completion can become a "message" that the circuit code publishes, and +to which higher-level layers subscribe. This means that circuit +handling can be decoupled from higher-level modules, and stay nice and +simple. (@ref pubsub_notyet "1") + +> @anchor pubsub_notyet 1. Unfortunately, like most of our code, circuit +> handling is _not_ yet refactored to use publish-subscribe throughout. +> Instead, layer violations of the type described here are pretty common +> in Tor today. To see a small part of what happens when a circuit is +> completed today, have a look at circuit_build_no_more_hops() and its +> associated code. + +## Channels and delivery policies + +To work with messages, especially when refactoring existing code, you'll +need to understand "channels" and "delivery policies". + +Every message is delivered on a "message channel". Each channel +(conceptually) a queue-like structure that can support an arbitrarily +number of message types. Where channels vary is their delivery +mechanisms, and their guarantees about when messages are processed. + +Currently, three delivery policies are possible: + + - `DELIV_PROMPT` -- causes messages to be processed via a callback in + Tor's event loop. This is generally the best choice, since it + avoids unexpected growth of the stack. + + - `DELIV_IMMEDIATE` -- causes messages to be processed immediately + on the call stack when they are published. This choice grows the + stack, and can lead to unexpected complexity in the call graph. + We should only use it when necessary. + + - `DELIV_NEVER` -- causes messages not to be delivered by the message + dispatch system at all. Instead, some other part of the code must + call dispatch_flush() to get the messages delivered. + +## Layers: Dispatch vs publish-subsubscribe vs mainloop. + +At the lowest level, messages are sent via the "dispatcher" module in +@refdir{lib/dispatch}. For performance, this dispatcher works with a +untyped messages. Publishers, subscribers, channels, and messages are +distinguished by short integers. Associated data is handled as +dynamically-typed data pointers, and its types are also stored as short +integers. + +Naturally, this results in a type-unsafe C API, so most other modules +shouldn't invoke @refdir{lib/dispatch} directly. At a higher level, +@refdir{lib/pubsub} defines a set of functions and macros that make +messages named and type-safe. This is the one that other modules should +use when they want to send or receive a message. + +The two modules above do not handle message delivery. Instead, the +dispatch module takes a callback that it can invoke when a channel +becomes nonempty, and defines a dispatch_flush() function to deliver all +the messages queued in a channel. The work of actually making sure that +dispatch_flush() is called when appropriate falls to the main loop, +which needs to integrate the message dispatcher with the rest of our +events and callbacks. This work happens in mainloop_pubsub.c. + + +## How to publish and subscribe + +This section gives an overview of how to make new messages and how to +use them. For full details, see pubsub_macros.h. + +Before anybody can publish or subscribe to a message, the message must +be declared, typically in a header. This uses DECLARE_MESSAGE() or +DECLARE_MESSAGE_INT(). + +Only subsystems can publish or subscribe messages. For more information +about the subsystems architecture, see @ref initialization. + +To publish a message, you must: + - Include the header that declares the message. + - Declare a set of helper functions via DECLARE_PUBLISH(). These + must be visible wherever you call PUBLISH(). + - Call PUBLISH() to actually send a message. + - Connect your subsystem to the dispatcher by calling + DISPATCH_ADD_PUB() from your subsystem's subsys_fns_t.add_pubsub + callback. + +To subscribe to a message, you must: + - Include the header that declares the message. + - Declare a callback function to be invoked when the message is delivered. + - Use DISPATCH_SUBSCRIBE at file scope to define a set of wrapper + functions to call your callback function with the appropriate type. + - Connect your subsystem to the dispatcher by calling + DISPATCH_ADD_SUB() from your subsystem's subsys_fns_t.add_pubsub + callback. + +Again, the file-level documentation for pubsub_macros.h describes how to +declare a message, how to publish it, and how to subscribe to it. + +## Designing good messages + +**Frequency**: +The publish-subscribe system uses a few function calls +and allocations for each message sent. This makes it unsuitable for +very-high-bandwidth events, like "receiving a single data cell" or "a +socket has become writable." It's fine, however, for events that +ordinarily happen a bit less frequently than that, like a circuit +getting finished, a new connection getting opened, or so on. + +**Semantics**: +A message should declare that something has happened or is happening, +not that something in particular should be done. + +For example, suppose you want to set up a message so that onion services +clean up their replay caches whenever we're low on memory. The event +should be something like `memory_low`, not `clean_up_replay_caches`. +The latter name would imply that the publisher knew who was subscribing +to the message and what they intended to do about it, which would be a +layering violation. diff --git a/src/mainpage.md b/src/mainpage.md index a2c5ec630..63a5b0a3f 100644 --- a/src/mainpage.md +++ b/src/mainpage.md @@ -41,6 +41,8 @@ Tor repository. @subpage time_periodic +@subpage publish_subscribe + @page intro A high-level overview @@ -140,4 +142,3 @@ more connection types. A 'Node' (node_t) is a view of a Tor instance's current knowledge and opinions about a Tor relay or bridge. -

1 0

[tor/master] Merge branch 'ticket32207'
by nickm＠torproject.org 02 Dec '19

02 Dec '19

commit f63cf2158b22b891a596a1274d1076faf3b69a27 Merge: 53bdd2117 af7416bfa Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Dec 2 11:41:40 2019 -0500 Merge branch 'ticket32207' src/core/mainloop/mainloop_pubsub.h | 32 ++++++++ src/lib/pubsub/publish_subscribe.md | 144 ++++++++++++++++++++++++++++++++++++ src/mainpage.md | 1 + 3 files changed, 177 insertions(+) diff --cc src/mainpage.md index c5cb1af23,63a5b0a3f..3901e7955 --- a/src/mainpage.md +++ b/src/mainpage.md @@@ -41,8 -41,8 +41,9 @@@ Tor repository @subpage time_periodic -@subpage publish_subscribe +@subpage configuration ++@subpage publish_subscribe @page intro A high-level overview

1 0

[tor/master] Link to mainloop_pubsub.[ch] when describing delivery policies
by nickm＠torproject.org 02 Dec '19

02 Dec '19

commit af7416bfad1107a43cafef978674f051f2f5584f Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Dec 2 11:41:16 2019 -0500 Link to mainloop_pubsub.[ch] when describing delivery policies --- src/lib/pubsub/publish_subscribe.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/lib/pubsub/publish_subscribe.md b/src/lib/pubsub/publish_subscribe.md index 019591bc1..bb05b100b 100644 --- a/src/lib/pubsub/publish_subscribe.md +++ b/src/lib/pubsub/publish_subscribe.md @@ -62,6 +62,9 @@ Currently, three delivery policies are possible: dispatch system at all. Instead, some other part of the code must call dispatch_flush() to get the messages delivered. +See mainloop_pubsub.c and mainloop_pubsub.h for more information and +implementation details. + ## Layers: Dispatch vs publish-subsubscribe vs mainloop. At the lowest level, messages are sent via the "dispatcher" module in

1 0

[translation/tbmanual-contentspot] https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot
by translation＠torproject.org 02 Dec '19

02 Dec '19

commit 03a383c9231ddc34a37e819185e5911ea4ef3573 Author: Translation commit bot <translation(a)torproject.org> Date: Mon Dec 2 16:20:11 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot --- contents+lt.po | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/contents+lt.po b/contents+lt.po index 9d2c163273..3bcfec9df1 100644 --- a/contents+lt.po +++ b/contents+lt.po @@ -959,7 +959,8 @@ msgstr "" #: (content/bridges/contents+en.lrtopic.body) msgid "* Email bridges(a)torproject.org from a Gmail, or Riseup email address" msgstr "" -"* Parašyti laišką į bridges(a)torproject.org iš Gmail arba Riseup pašto adresų" +"* Parašyti el. laišką, adresu bridges(a)torproject.org iš Gmail arba Riseup " +"el. pašto adreso" #: https//tb-manual.torproject.org/bridges/ #: (content/bridges/contents+en.lrtopic.body)

1 0

[translation/tbmanual-contentspot] https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot
by translation＠torproject.org 02 Dec '19

02 Dec '19

commit 75e5cb8ce35f80f25e21320d9ccff2782a6103d8 Author: Translation commit bot <translation(a)torproject.org> Date: Mon Dec 2 15:50:05 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot --- contents+lt.po | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/contents+lt.po b/contents+lt.po index 35dd3ec758..9d2c163273 100644 --- a/contents+lt.po +++ b/contents+lt.po @@ -834,8 +834,8 @@ msgid "" "Once you've selected the pluggable transport you'd like to use, click " "'Connect' to save your settings." msgstr "" -"Kai pasirinkote prijungiamąjį transportą, kurį norėsite naudoti, spauskite " -"'Prisijungti' išsaugoti nustatymams." +"Pasirinkę norimą naudoti keičiamąjį perdavimą, spustelėkite \"Prisijungti\"," +" kad įrašytumėte nustatymus." #: https//tb-manual.torproject.org/circumvention/ #: (content/circumvention/contents+en.lrtopic.body) @@ -857,8 +857,8 @@ msgid "" "If you are trying to circumvent a blocked connection for the first time, you" " should try the different transports: obfs4, snowflake, and meek-azure." msgstr "" -"Jeigu bandote apeiti blokuojamą ryšį pirmą kartą, išbandykite skirtingus " -"transportus: obfs4, snowflake ir meek-azure." +"Jeigu pirmą kartą bandote apeiti blokuojamą ryšį, išbandykite skirtingus " +"perdavimus: obfs4, snowflake ir meek-azure." #: https//tb-manual.torproject.org/circumvention/ #: (content/circumvention/contents+en.lrtopic.body) @@ -866,15 +866,17 @@ msgid "" "If you try all of these options, and none of them gets you online, you will " "need to enter bridge addresses manually." msgstr "" -"Jei išbandėte visus variantus, bet interneto pasiekti vis tiek negalite, " -"turėsite tinklo tilto adresus įvesti ranka." +"Jei išbandėte visus šiuos variantus, bet vis tiek negalite prisijungti prie " +"interneto, tuomet turėsite rankiniu būdu įvesti tinklų tiltų adresus." #: https//tb-manual.torproject.org/circumvention/ #: (content/circumvention/contents+en.lrtopic.body) msgid "" "Read the [Bridges](/en-US/bridges/) section to learn what bridges are and " "how to obtain them." -msgstr "Paskaitykite [Tinklų Tiltai](/lt/bridges/)" +msgstr "" +"Norėdami sužinoti kas yra tinklų tiltai ir kaip juos gauti, skaitykite " +"skyrių [Tinklų tiltai](/lt/bridges/)." #: https//tb-manual.torproject.org/bridges/ #: (content/bridges/contents+en.lrtopic.title) @@ -887,8 +889,8 @@ msgid "" "Most Pluggable Transports, such as obfs4, rely on the use of “bridge” " "relays." msgstr "" -"Dauguma prijungiamųjų transportų, kaip obfs4 veikia naudodami \"tinklų " -"tiltų\" retransliacijas." +"Dauguma keičiamųjų perdavimų, kaip, pavyzdžiui, obfs4, veikia remdamiesi " +"\"tinklų tilto\" retransliavimo naudojimu." #: https//tb-manual.torproject.org/bridges/ #: (content/bridges/contents+en.lrtopic.body) @@ -896,8 +898,8 @@ msgid "" "Most [Pluggable Transports](/circumvention), such as obfs4, rely on the use " "of “bridge” relays." msgstr "" -"Dauguma [Prijungiamųjų transportų](/lt/circumvention), kaip obfs4 veikia " -"naudodami \"tinklų tiltų\" retransliacijas." +"Dauguma [keičiamųjų perdavimų](/lt/circumvention), kaip, pavyzdžiui, obfs4, " +"veikia remdamiesi \"tinklų tilto\" retransliavimo naudojimu." #: https//tb-manual.torproject.org/bridges/ #: (content/bridges/contents+en.lrtopic.body)

1 0

[metrics-web/master] Improve runtime performance of hidserv module.
by karsten＠torproject.org 02 Dec '19

02 Dec '19

commit 4448f5fc0de60763d42e724036bda8388435af91 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Fri Nov 22 09:47:20 2019 +0100 Improve runtime performance of hidserv module. Fixes #25924. --- CHANGELOG.md | 5 ++ .../metrics/stats/hidserv/Extrapolator.java | 82 ++++++++++------------ 2 files changed, 43 insertions(+), 44 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index fe74cf5..797d54b 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,10 @@ # Changes in version 1.?.? - 2019-1?-?? + * Medium changes + - Improve runtime performance of the hidserv module by storing + extrapolated statistics even if computed network fractions are + zero, to avoid re-processing these statistics over and over. + # Changes in version 1.3.0 - 2019-11-09 diff --git a/src/main/java/org/torproject/metrics/stats/hidserv/Extrapolator.java b/src/main/java/org/torproject/metrics/stats/hidserv/Extrapolator.java index 0dcc638..7a44425 100644 --- a/src/main/java/org/torproject/metrics/stats/hidserv/Extrapolator.java +++ b/src/main/java/org/torproject/metrics/stats/hidserv/Extrapolator.java @@ -197,52 +197,46 @@ public class Extrapolator { } } - /* If we don't know a single consensus with valid-after time in - * the statistics interval, skip this stat. */ - if (consensuses == 0) { - continue; + /* Compute means of network fractions, or assume 0.0 if we don't + * know a single consensus with valid-after time in the statistics + * interval. */ + double fractionRendRelayedCells = consensuses == 0 ? 0.0 + : sumFractionRendRelayedCells / consensuses; + double fractionDirOnionsSeen = consensuses == 0 ? 0.0 + : sumFractionDirOnionsSeen / consensuses; + + /* Extrapolate network totals. If we don't know a single + * consensus, store an empty statistic anyway to avoid processing + * these reported statistics over and over. */ + ExtrapolatedHidServStats extrapolated = + new ExtrapolatedHidServStats( + statsDateMillis, fingerprint); + if (fractionRendRelayedCells > 0.0) { + extrapolated.setFractionRendRelayedCells( + fractionRendRelayedCells); + /* Extrapolating cells on rendezvous circuits is as easy as + * dividing the reported number by the computed network + * fraction. */ + double extrapolatedRendRelayedCells = + stats.getRendRelayedCells() / fractionRendRelayedCells; + extrapolated.setExtrapolatedRendRelayedCells( + extrapolatedRendRelayedCells); } - - /* Compute means of network fractions. */ - double fractionRendRelayedCells = - sumFractionRendRelayedCells / consensuses; - double fractionDirOnionsSeen = - sumFractionDirOnionsSeen / consensuses; - - /* If at least one fraction is positive, extrapolate network - * totals. */ - if (fractionRendRelayedCells > 0.0 - || fractionDirOnionsSeen > 0.0) { - ExtrapolatedHidServStats extrapolated = - new ExtrapolatedHidServStats( - statsDateMillis, fingerprint); - if (fractionRendRelayedCells > 0.0) { - extrapolated.setFractionRendRelayedCells( - fractionRendRelayedCells); - /* Extrapolating cells on rendezvous circuits is as easy as - * dividing the reported number by the computed network - * fraction. */ - double extrapolatedRendRelayedCells = - stats.getRendRelayedCells() / fractionRendRelayedCells; - extrapolated.setExtrapolatedRendRelayedCells( - extrapolatedRendRelayedCells); - } - if (fractionDirOnionsSeen > 0.0) { - extrapolated.setFractionDirOnionsSeen( - fractionDirOnionsSeen); - /* Extrapolating reported unique .onion addresses to the - * total number in the network is more difficult. In short, - * each descriptor is stored to 12 (likely) different - * directories, so we'll have to divide the reported number by - * 12 and then by the computed network fraction of this - * directory. */ - double extrapolatedDirOnionsSeen = - stats.getDirOnionsSeen() / (12.0 * fractionDirOnionsSeen); - extrapolated.setExtrapolatedDirOnionsSeen( - extrapolatedDirOnionsSeen); - } - extrapolatedStats.add(extrapolated); + if (fractionDirOnionsSeen > 0.0) { + extrapolated.setFractionDirOnionsSeen( + fractionDirOnionsSeen); + /* Extrapolating reported unique .onion addresses to the + * total number in the network is more difficult. In short, + * each descriptor is stored to 12 (likely) different + * directories, so we'll have to divide the reported number by + * 12 and then by the computed network fraction of this + * directory. */ + double extrapolatedDirOnionsSeen = + stats.getDirOnionsSeen() / (12.0 * fractionDirOnionsSeen); + extrapolated.setExtrapolatedDirOnionsSeen( + extrapolatedDirOnionsSeen); } + extrapolatedStats.add(extrapolated); } }

1 0