January 2015 - tor-commits - lists.torproject.org

[torspec/master] Merge remote-tracking branch 'asn/hs_stats'
by nickm＠torproject.org 06 Jan '15

06 Jan '15

commit 8cd926c3a5d2c6270a5225946e46f274321b8ff6 Merge: 7976eb1 caff520 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Jan 6 12:53:39 2015 -0500 Merge remote-tracking branch 'asn/hs_stats' proposals/238-hs-relay-stats.txt | 293 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 293 insertions(+)

1 0

[torspec/master] Improve 238-hs-relay-stats.txt.
by nickm＠torproject.org 06 Jan '15

06 Jan '15

commit 7185dc92578b76e60a1a9b2df19e4dddd00abfea Author: George Kadianakis <desnacked(a)riseup.net> Date: Mon Dec 8 18:39:51 2014 +0000 Improve 238-hs-relay-stats.txt. Add more information about obfuscation, and better format for extra-info. --- proposals/238-hs-relay-stats.txt | 166 +++++++++++++++++++++++--------------- 1 file changed, 101 insertions(+), 65 deletions(-) diff --git a/proposals/238-hs-relay-stats.txt b/proposals/238-hs-relay-stats.txt index bcadd52..e7bf184 100644 --- a/proposals/238-hs-relay-stats.txt +++ b/proposals/238-hs-relay-stats.txt @@ -23,7 +23,7 @@ Status: Draft network traffic or 90% of the Tor network traffic. This info can also help us during load balancing, for example if we change the path building of hidden services to mitigate guard discovery - attacks [0]. + attacks [GUARD-DISCOVERY]. Also, learning the number of hidden services, can give us an understanding of how widespread hidden services are. It will also @@ -31,9 +31,10 @@ Status: Draft network by hidden service logistics, like introduction point circuits etc. + 1. Design - Tor relays will add some fields related to hidden service + Tor relays shall add some fields related to hidden service statistics in their extra-info descriptors. Tor relays collect these statistics by keeping track of their @@ -42,6 +43,7 @@ Status: Draft authorities. Extra-info descriptors are posted to directory authorities every 24 hours. + 2. Implementation 2.1. Hidden service statistics interval @@ -66,59 +68,106 @@ Status: Draft 2.2. Hidden service traffic statistics - We want to learn how much of the total Tor network traffic is caused by - hidden service usage. There are three phases in the rendezvous - protocol where traffic is generated: (1) when hidden services make - themselves available in the network, (2) when clients open connections - to hidden services, and (3) when clients exchange application data with - hidden services. We expect (3) to consume most bytes here, so we're - focusing on this only. More precisely, we measure hidden service - traffic by counting RELAY cells seen on a rendezvous point after - receiving a RENDEZVOUS1 cell. These RELAY cells include commands to - open or close application streams, and they include application data. + We want to learn how much of the total Tor network traffic is + caused by hidden service usage. More precisely, we measure hidden + service traffic by counting RELAY cells seen on a rendezvous point + after receiving a RENDEZVOUS1 cell. These RELAY cells include + commands to open or close application streams, and they include + application data. Tor relays will add the following line to their extra-info descriptor: - "hidserv-rend-relayed-cells" SP num NL + "hidserv-rend-relayed-cells" SP num SP key=val SP key=val ... NL [At most once.] - Approximate number of RELAY cells seen in either direction on - a circuit after receiving and successfully processing a - RENDEZVOUS1 cell. The actual number observed by the directory - is multiplied with a random number in [0.9, 1.1] and then gets - floored before being reported. + Where 'num' is the number of RELAY cells seen in either + direction on a circuit after receiving and successfully + processing a RENDEZVOUS1 cell. + + The actual number is obfuscated as detailed in section + "2.4. Statistics obfuscation". The parameters of the + obfuscation are included in the key=val part of the line. - The keyword indicates that this line is part of hidden-service - statistics ("hidserv") and contains aggregate data from the relay - acting as rendezvous point ("rend"). + The obfuscatory parameters for this statistic are: + * delta_f = 2048 + * epsilon = 0.3 + * bin_size = 1024 + + So, an example line could be: + hidserv-rend-relayed-cells 19456 delta_f=2048 epsilon=0.30 binsize=1024 2.3. HSDir hidden service counting - We also want to learn how many hidden services exist in the network. - The best place to learn this is at hidden service directories where - hidden services publish their descriptors. + We also want to learn how many hidden services exist in the + network. The best place to learn this is at hidden service + directories where hidden services publish their descriptors. Tor relays will add the following line to their extra-info descriptor: - "hidserv-dir-published-ids" SP num NL + "hidserv-dir-onions-seen" SP num SP key=val SP key=val ... NL [At most once.] Approximate number of unique hidden-service identities seen in descriptors published to and accepted by this hidden-service - directory. The actual number observed by the directory is - multiplied with a random number in [0.9, 1.1] and then gets - floored before being reported. - - This statistic requires keeping a separate data structure with unique - identities seen during the current statistics interval. We could, in - theory, have relays iterate over their descriptor caches when producing - the daily hidden-service statistics blurb. But it's unclear how - caching would affect results from such an approach, because descriptors - published at the start of the current statistics interval could already - have been removed, and descriptors published in the last statistics - interval could still be present. Keeping a separate data structure, - possibly even a probabilistic one, seems like the more accurate - approach. + directory. + + The actual number number is obfuscated as detailed in section + "2.4. Statistics obfuscation". The parameters of the + obfuscation are included in the key=val part of the line. + + The obfuscatory parameters for these statistics are: + * delta_f = 1 + * epsilon = 0.3 + * bin_size = 8 + + So, an example line could be: + hidserv-dir-onions-seen 112 delta_f=1 epsilon=0.30 binsize=8 + +2.4. Statistics obfuscation + + We believe that publishing the actual measurement values in such a + system might have unpredictable effects, so we obfuscate these + statistics before publishing: + + +--------------+ +--------------------+ + actual value -> |additive noise| -> |round-up obfuscation| -> public statistic + +--------------+ +--------------------+ + + We are using two obfuscation methods to better hide the actual + numbers even if they remain the same over multiple measurement + periods. + + Specifically, given the actual measurement value, we first deploy + additive noise in a fashion similar to basic differential + privacy. Then, we round up this obfuscated result to the nearest + multiple of an integer (which is a security parameter), to derive a + final result which can be published safely. + + More information about the obfuscation methods follows: + +2.4.1. Additive noise + + We apply additive noise to the actual measurement by adding to it a + random value sampled from a Laplace distribution . Following the + differential privacy methodology [DIFF-PRIVACY], our obfuscatory + Laplace distribution has \mu = 0 and b = (delta_f / epsilon). + + The precise values of delta_f and epsilon are different for each + statistic and are defined on the respective statistics sections. + +2.4.2. Round-up obfuscation + + To further hide any patterns, before publishing statistics, we round + up the result to the nearest multiple of 'bin_size'. 'bin_size' is + an integer security parameter and can be found on the respective + statistics sections. + + This is similar to how Tor keeps bridge user statistics. As an + example, if the measurement value is 9 and bin_size is 8, then the + final value will be rounded up to 16. This also works for negative + values, so for example, if the measurement value is -9 and bin_size + is 8, the value will be rounded up to -8. + 3. Security @@ -144,14 +193,17 @@ Status: Draft reported RP traffic to determine about how many fewer HS users there are when that HS is down. + 4. Discussion 4.1. Why count only RP cells? Why not also count IP cells? - As discussed on IRC, counting only RP cells should be fine for now. - Everything else is protocol overhead, which includes HSDir traffic, - introduction point traffic, or rendezvous point traffic before the - first RELAY cell, etc. + There are three phases in the rendezvous protocol where traffic is + generated: (1) when hidden services make themselves available in + the network, (2) when clients open connections to hidden services, + and (3) when clients exchange application data with hidden + services. We expect (3), that is the RP cells, to consume most + bytes here, so we're focusing on this only. Furthermore, introduction points correspond to specific HSes, so publishing IP cell stats could reveal the popularity of specific @@ -207,25 +259,9 @@ Status: Draft consider the part of the statistics interval following the valid-after time of that consensus. -4.3. Multiplicative or additive noise? - - A possible alternative to multiplying the number of cells with a random - factor is to introduce additive noise. Let's suppose that we would - like to obscure any individual connection that contains C cells or - fewer (obscuring extremely and unusually large connections seems - hopeless but unnecessary). That is, we don't want the (distribution - of) the cell count from any relay to change by much whether or not C - cells are removed. The standard differential privacy approach would be - to *add* noise from the Laplace distribution Lap(\epsilon/C), where - \epsilon controls how much the statistics *distribution* can - multiplicatively differ. This is not to say that we need to add noise - exactly from that distribution (maybe we weaken the guarantee slightly - to get better accuracy), but the same idea applies. This would apply - the same to both large and small relays. We *want* to learn roughly - how much hidden-service traffic each relay has - we just want to - obscure the exact number within some tolerance. We'll probably want to - include the algorithm and parameters used for adding noise in the - "hidserv-rend-relayed-cells" line, as in, "lap=x" with x being - \epsilon/C. - -[0]: guard discovery: https://lists.torproject.org/pipermail/tor-dev/2014-September/007474.html + +5. References + +[GUARD-DISCOVERY]: https://lists.torproject.org/pipermail/tor-dev/2014-September/007474.html + +[DIFF-PRIVACY]: http://research.microsoft.com/en-us/projects/databaseprivacy/dwork.pdf

1 0

[torspec/master] Further improvements to 238-hs-relay-stats.txt.
by nickm＠torproject.org 06 Jan '15

06 Jan '15

commit ae59ee1e346ef31208572c3accd3ed9ae513da81 Author: George Kadianakis <desnacked(a)riseup.net> Date: Sun Dec 14 16:42:47 2014 +0200 Further improvements to 238-hs-relay-stats.txt. - Inverse the order of the obfuscation methods as discussed in the mailing list. - Change delta_f of the HSDir stats to be 8 instead of 1. - Add links to pfm's graphs. --- proposals/238-hs-relay-stats.txt | 94 ++++++++++++++++++++++++-------------- 1 file changed, 60 insertions(+), 34 deletions(-) diff --git a/proposals/238-hs-relay-stats.txt b/proposals/238-hs-relay-stats.txt index e7bf184..d46e35d 100644 --- a/proposals/238-hs-relay-stats.txt +++ b/proposals/238-hs-relay-stats.txt @@ -84,14 +84,15 @@ Status: Draft direction on a circuit after receiving and successfully processing a RENDEZVOUS1 cell. - The actual number is obfuscated as detailed in section - "2.4. Statistics obfuscation". The parameters of the - obfuscation are included in the key=val part of the line. + The actual number is obfuscated as detailed in + [STAT-OBFUSCATION]. The parameters of the obfuscation are + included in the key=val part of the line. The obfuscatory parameters for this statistic are: * delta_f = 2048 * epsilon = 0.3 * bin_size = 1024 + (Also see [CELL-LAPLACE-GRAPH] for a graph of the Laplace distribution.) So, an example line could be: hidserv-rend-relayed-cells 19456 delta_f=2048 epsilon=0.30 binsize=1024 @@ -111,55 +112,45 @@ Status: Draft descriptors published to and accepted by this hidden-service directory. - The actual number number is obfuscated as detailed in section - "2.4. Statistics obfuscation". The parameters of the - obfuscation are included in the key=val part of the line. + The actual number number is obfuscated as detailed in + [STAT-OBFUSCATION]. The parameters of the obfuscation are + included in the key=val part of the line. - The obfuscatory parameters for these statistics are: - * delta_f = 1 + The obfuscatory parameters for this statistic are: + * delta_f = 8 * epsilon = 0.3 * bin_size = 8 + (Also see [ONIONS-LAPLACE-GRAPH] for a graph of the Laplace distribution.) So, an example line could be: hidserv-dir-onions-seen 112 delta_f=1 epsilon=0.30 binsize=8 -2.4. Statistics obfuscation +2.4. Statistics obfuscation [STAT-OBFUSCATION] We believe that publishing the actual measurement values in such a system might have unpredictable effects, so we obfuscate these statistics before publishing: - +--------------+ +--------------------+ - actual value -> |additive noise| -> |round-up obfuscation| -> public statistic - +--------------+ +--------------------+ + +-----------+ +--------------+ + actual value -> | binning | -> |additive noise| -> public statistic + +-----------+ +--------------+ We are using two obfuscation methods to better hide the actual numbers even if they remain the same over multiple measurement periods. - Specifically, given the actual measurement value, we first deploy - additive noise in a fashion similar to basic differential - privacy. Then, we round up this obfuscated result to the nearest - multiple of an integer (which is a security parameter), to derive a - final result which can be published safely. + Specifically, given the actual measurement value, we first apply + data binning to it (basically we round it up to the nearest multiple + of an integer, see [DATA-BINNING]). And then we apply additive noise + to the binned value in a fashion similar to differential privacy. More information about the obfuscation methods follows: -2.4.1. Additive noise - - We apply additive noise to the actual measurement by adding to it a - random value sampled from a Laplace distribution . Following the - differential privacy methodology [DIFF-PRIVACY], our obfuscatory - Laplace distribution has \mu = 0 and b = (delta_f / epsilon). - - The precise values of delta_f and epsilon are different for each - statistic and are defined on the respective statistics sections. +2.4.1. Data binning -2.4.2. Round-up obfuscation - - To further hide any patterns, before publishing statistics, we round - up the result to the nearest multiple of 'bin_size'. 'bin_size' is - an integer security parameter and can be found on the respective + The first thing we do to the original measurement value, is to round + it up to the nearest multiple of 'bin_size'. 'bin_size' is an + integer security parameter and can be found on the respective statistics sections. This is similar to how Tor keeps bridge user statistics. As an @@ -168,6 +159,17 @@ Status: Draft values, so for example, if the measurement value is -9 and bin_size is 8, the value will be rounded up to -8. +2.4.2. Additive noise + + Then, before publishing the statistics, we apply additive noise to + the binned value by adding to it a random value sampled from a + Laplace distribution . Following the differential privacy + methodology [DIFF-PRIVACY], our obfuscatory Laplace distribution has + mu = 0 and b = (delta_f / epsilon). + + The precise values of delta_f and epsilon are different for each + statistic and are defined on the respective statistics sections. + 3. Security @@ -196,7 +198,7 @@ Status: Draft 4. Discussion -4.1. Why count only RP cells? Why not also count IP cells? +4.1. Why count only RP cells? Why not count IP cells too? There are three phases in the rendezvous protocol where traffic is generated: (1) when hidden services make themselves available in @@ -211,7 +213,7 @@ Status: Draft 4.2. How to use these stats? - 4.2.1. How to use RP Cell statistics + 4.2.1. How to use rendezvous cell statistics We plan to extrapolate reported values to network totals by dividing values by the probability of clients picking relays as rendezvous @@ -259,9 +261,33 @@ Status: Draft consider the part of the statistics interval following the valid-after time of that consensus. +4.3. Why does the obfuscation work? + + By applying data binning, we smudge the original value making it + harder for attackers to guess it. Specifically, an attacker who + knows the bin, can only guess the underlying value with probability + 1/bin_size. + + By applying additive noise, we make it harder for the adversary to + find out the current bin, which makes it even harder to get the + original value. If additive noise was not applied, an adversary + could try to detect changes in the original value by checking when + we switch bins. + +5. Acknowledgements -5. References + Thanks go to 'pfm' for the helpful Laplace graphs. + +6. References [GUARD-DISCOVERY]: https://lists.torproject.org/pipermail/tor-dev/2014-September/007474.html [DIFF-PRIVACY]: http://research.microsoft.com/en-us/projects/databaseprivacy/dwork.pdf + +[DATA-BINNING]: https://en.wikipedia.org/wiki/Data_binning + +[CELL-LAPLACE-GRAPH]: https://raw.githubusercontent.com/corcra/pioton/master/vis/laplacePDF_mu0_b… + https://raw.githubusercontent.com/corcra/pioton/master/vis/laplaceCDF_mu0_b… + +[ONIONS-LAPLACE-GRAPH]: https://raw.githubusercontent.com/corcra/pioton/master/vis/laplacePDF_mu0_b… + https://raw.githubusercontent.com/corcra/pioton/master/vis/laplaceCDF_mu0_b…

1 0

[webwml/master] Update the sponsor list for 2014
by andrew＠torproject.org 06 Jan '15

06 Jan '15

commit 684578da5e9d09f60ef87aea0f81a3190d60c6bb Author: Andrew Lewman <andrew(a)torproject.is> Date: Tue Jan 6 11:47:16 2015 -0500 Update the sponsor list for 2014 --- about/en/sponsors.wml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/about/en/sponsors.wml b/about/en/sponsors.wml index 16da57a..576d5a2 100644 --- a/about/en/sponsors.wml +++ b/about/en/sponsors.wml @@ -39,6 +39,7 @@ <p>We greatly appreciate the support provided by our past sponsors in keeping the Tor Project progressing through our ambitious goals:</p> <ul> + <li><a href="https://freedom.press/">Freedom of the Press Foundation</a> (2014)</li> <li><a href="http://www.knightfoundation.org/">The Knight Foundation</a> (2012-2013)</li> <li><a href="http://www.sida.se/English/">Sida - Swedish International Development Cooperation Agency</a> (2010-2013)</li> <li>An anonymous North American NGO (2008-2013)</li> @@ -49,7 +50,7 @@ <li><a href="http://www.hrw.org/">Human Rights Watch</a> (2007)</li> <li><a href="http://www.torfox.org/">Torfox</a> (2009)</li> <li><a href="http://www.shinjiru.com/">Shinjiru Technology</a> (2009-2011)</li> - <li><a href="http://www.nationalchristian.com/">National Christian Foundation</a> (2010-2012)</li> + <li><a href="http://www.nationalchristian.com/">National Christian Foundation</a> (2010-2012, 2014)</li> <li><a href="http://www.nlnet.nl/">NLnet Foundation</a> (2008-2009)</li> <li><a href="http://www.nrl.navy.mil/">Naval Research Laboratory</a> (2006-2010)</li> <li>Internews Europe (2006-2008)</li>

1 0

[webwml/master] Merge branch 'master' of ssh://git-rw.torproject.org/project/web/webwml
by andrew＠torproject.org 06 Jan '15

06 Jan '15

commit fc6478c74d0f541797c4d592c4e5095799e2ce92 Merge: 684578d a1ae777 Author: Andrew Lewman <andrew(a)torproject.is> Date: Tue Jan 6 11:47:35 2015 -0500 Merge branch 'master' of ssh://git-rw.torproject.org/project/web/webwml about/en/gsoc.wml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

1 0

[translation/tails-iuk] Update translations for tails-iuk
by translation＠torproject.org 06 Jan '15

06 Jan '15

commit 51997da88fa654d9dbebbaeac1ec65463876da0f Author: Translation commit bot <translation(a)torproject.org> Date: Tue Jan 6 16:45:47 2015 +0000 Update translations for tails-iuk --- ms_MY.po | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/ms_MY.po b/ms_MY.po index f94a3df..4bbbf13 100644 --- a/ms_MY.po +++ b/ms_MY.po @@ -3,15 +3,16 @@ # This file is distributed under the same license as the PACKAGE package. # # Translators: +# Celine Yap Suet Ling <celine.sodawine(a)gmail.com>, 2015 # kz_gtr <kz_gtr(a)yahoo.com>, 2014 # Mohd Rukhairy Abdul Rahman <rukhairy(a)gmail.com>, 2014 msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: Tails developers <tails(a)boum.org>\n" -"POT-Creation-Date: 2014-10-08 21:09+0200\n" -"PO-Revision-Date: 2014-11-05 02:31+0000\n" -"Last-Translator: Mohd Rukhairy Abdul Rahman <rukhairy(a)gmail.com>\n" +"POT-Creation-Date: 2014-12-02 09:42+0100\n" +"PO-Revision-Date: 2015-01-06 16:41+0000\n" +"Last-Translator: Celine Yap Suet Ling <celine.sodawine(a)gmail.com>\n" "Language-Team: Malay (Malaysia) (http://www.transifex.com/projects/p/torproject/language/ms_MY/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -39,11 +40,11 @@ msgstr "" #: ../lib/Tails/IUK/Frontend.pm:234 msgid "no automatic upgrade is available from our website for this version" -msgstr "" +msgstr "tiada penaikan taraf automatik boleh didapati daripada laman web kami untuk versi ini" #: ../lib/Tails/IUK/Frontend.pm:240 msgid "your device was not created using Tails Installer" -msgstr "" +msgstr "peranti anda bukan dicipta menggunakan Tails Installer" #: ../lib/Tails/IUK/Frontend.pm:245 msgid "Tails was started from a DVD or a read-only device" @@ -55,12 +56,12 @@ msgstr "" #: ../lib/Tails/IUK/Frontend.pm:255 msgid "not enough memory is available on this system" -msgstr "" +msgstr "memori tidak mencukupi dalam sistem ini" #: ../lib/Tails/IUK/Frontend.pm:261 #, perl-brace-format msgid "No explanation available for reason '%{reason}s'." -msgstr "" +msgstr "Tiada penjelasan tersedia untuk sebab '%{sebab}'." #: ../lib/Tails/IUK/Frontend.pm:281 msgid "The system is up-to-date" @@ -68,7 +69,7 @@ msgstr "Sistem sudah dikemaskini" #: ../lib/Tails/IUK/Frontend.pm:286 msgid "This version of Tails is outdated, and may have security issues." -msgstr "" +msgstr "Versi Tails ini ketinggalan zaman dan mungkin terdapat masalah keselamatan." #: ../lib/Tails/IUK/Frontend.pm:318 #, perl-brace-format @@ -92,7 +93,7 @@ msgstr "" #: ../lib/Tails/IUK/Frontend.pm:360 msgid "Error while detecting available upgrades" -msgstr "" +msgstr "Terdapat masalah bila mengesan penaik tarafan." #: ../lib/Tails/IUK/Frontend.pm:370 #, perl-brace-format @@ -112,7 +113,7 @@ msgstr "" #: ../lib/Tails/IUK/Frontend.pm:385 msgid "Upgrade available" -msgstr "" +msgstr "Terdapat naiktaraf" #: ../lib/Tails/IUK/Frontend.pm:386 msgid "Upgrade now" @@ -120,7 +121,7 @@ msgstr "Naiktaraf sekarang" #: ../lib/Tails/IUK/Frontend.pm:387 msgid "Upgrade later" -msgstr "" +msgstr "Naiktaraf kemudian" #: ../lib/Tails/IUK/Frontend.pm:395 #, perl-brace-format @@ -140,7 +141,7 @@ msgstr "Ada versi terbaru" #: ../lib/Tails/IUK/Frontend.pm:468 msgid "Downloading upgrade" -msgstr "" +msgstr "Sedang memuat turun naiktaraf" #: ../lib/Tails/IUK/Frontend.pm:471 #, perl-brace-format

1 0

[webwml/master] Fixed broken link of revamp gettor for gsoc
by atagar＠torproject.org 06 Jan '15

06 Jan '15

commit a1ae77725a1dc6e01b646be593ac582ba9a39dc8 Author: ileiva <ileiva(a)users.noreply.github.com> Date: Mon Jan 5 16:55:46 2015 -0300 Fixed broken link of revamp gettor for gsoc --- about/en/gsoc.wml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/about/en/gsoc.wml b/about/en/gsoc.wml index 3e5fdcb..2009eed 100644 --- a/about/en/gsoc.wml +++ b/about/en/gsoc.wml @@ -216,7 +216,7 @@ <ul> <li><h4><a href="https://ahmia.fi/gsoc/">Ahmia.fi - Search Engine for Hidden Services</a> by Juha Nurmi</h4></li> <li><h4><a href="http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/amoghbl1…">Orbot & Orfox</a> by Amogh Pradeep</h4></li> - <li><h4><a href="http://ileiva.github.io/gettor_proposal.html">Revamp GetTor</a> by Israel Leiva</h4></li> + <li><h4><a href="http://ilv.github.io/gettor_proposal.html">Revamp GetTor</a> by Israel Leiva</h4></li> <li><h4><a href="https://sites.google.com/site/sreenathadev/gsoc-2014-weather-rewrite">Weather Rewrite</a> by Sreenatha Bhatlapenumarthi</h4></li> <li><h4><a href="http://kostas.mkj.lt/gsoc2014/gsoc2014.html">BridgeDB Distributor</a> by Kostas Jakeliunas</h4></li> <li><h4><a href="http://kostas.mkj.lt/gsoc2013/gsoc2013.html">Searchable Tor descriptor archive</a> by Kostas Jakeliunas</h4></li>

1 0

[webwml/master] Updated mirror.
by andrew＠torproject.org 06 Jan '15

06 Jan '15

commit 71e7d8e4d2084711c02a0ff89dc783b5b603bc1b Author: Andrew Lewman <andrew(a)torproject.is> Date: Tue Jan 6 09:38:49 2015 -0500 Updated mirror. --- include/tor-mirrors.csv | 1 + 1 file changed, 1 insertion(+) diff --git a/include/tor-mirrors.csv b/include/tor-mirrors.csv index ca8ebe0..ca7a470 100644 --- a/include/tor-mirrors.csv +++ b/include/tor-mirrors.csv @@ -104,3 +104,4 @@ hostmaster(a)lucidnetworks.net, Lucid Networks, US, United States, US, TRUE, FALSE hostmaster(a)vieth-server.de, mirror-server.de, DE, Germany, DE, TRUE, TRUE, No, http://tor.mirror-server.de/, , , , http://tor.mirror-server.de/dist/, , , , Thu Jan 1 15:14:41 2015 mirror ntzk de, Netzkonstrukt Berlin, DE, Germany, Europe, TRUE, FALSE, No, http://mirror.ntzk.de/torproject.org/, https://mirror.ntzk.de/torproject.org/, , , http://mirror.ntzk.de/torproject.org/dist/, https://mirror.ntzk.de/torproject.org/dist/, , , Wed Dec 31 18:27:22 2014 mirror(a)xfree.com.ar, Xfree.com.ar, AR, Argentina, South America, TRUE, FALSE, No, http://tor.xfree.com.ar/, , , , http://tor.xfree.com.ar/dist/, , , , Wed Dec 31 18:27:22 2014 +tor AT eprci NET, EPRCI, US, NH, US, TRUE, FALSE, No, http://tor.eprci.net/, https:/www.eprci.com/tor/, , , http://tor.eprci.net/dist/, https://www.eprci.com/tor/dist/, , , \ No newline at end of file

1 0

[tor/master] have 'make {clean, reset_gcov}' remove gcov files in subdirectories
by nickm＠torproject.org 06 Jan '15

06 Jan '15

commit 839076ab00e8b67bc627847aef3ee9b5ab8c66f6 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Jan 6 09:01:59 2015 -0500 have 'make {clean,reset_gcov}' remove gcov files in subdirectories --- Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile.am b/Makefile.am index f6a1bcf..f105464 100644 --- a/Makefile.am +++ b/Makefile.am @@ -80,7 +80,7 @@ test-stem: $(TESTING_TOR_BINARY) reset-gcov: - rm -f src/*/*.gcda + rm -f src/*/*.gcda src/*/*/*.gcda HTML_COVER_DIR=./coverage_html coverage-html: all @@ -118,4 +118,4 @@ version: fi mostlyclean-local: - rm -f src/*/*.gc{da,no} + rm -f src/*/*.gc{da,no} src/*/*/*.gc{da,no}

1 0

[tor/master] make "make test-stem" run stem tests on tor
by nickm＠torproject.org 06 Jan '15

06 Jan '15

commit d74f0cff92322174e19c5cbd98462bd25e14fc3c Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Jan 5 11:52:36 2015 -0500 make "make test-stem" run stem tests on tor Closes ticket 14107. --- Makefile.am | 9 +++++++++ changes/ticket14107 | 6 ++++++ src/or/include.am | 3 +++ 3 files changed, 18 insertions(+) diff --git a/Makefile.am b/Makefile.am index 3de7f7a..f6a1bcf 100644 --- a/Makefile.am +++ b/Makefile.am @@ -70,6 +70,15 @@ test: all test-network: all ./src/test/test-network.sh +test-stem: $(TESTING_TOR_BINARY) + @if test -d "$$STEM_SOURCE_DIR"; then \ + "$$STEM_SOURCE_DIR"/run_tests.py --tor $(TESTING_TOR_BINARY) --all --log notice --target RUN_ALL; \ + else \ + echo '$$STEM_SOURCE_DIR was not set.'; echo; \ + echo "To run these tests, git clone https://git.torproject.org/stem.git/ ; export STEM_SOURCE_DIR=\`pwd\`/stem"; \ + fi + + reset-gcov: rm -f src/*/*.gcda diff --git a/changes/ticket14107 b/changes/ticket14107 new file mode 100644 index 0000000..e4ba6be --- /dev/null +++ b/changes/ticket14107 @@ -0,0 +1,6 @@ + o Testing: + + - New "make test-stem" target to run stem integration tests. + Requires that the "STEM_SOURCE_DIR" environment variable be set. + Closes ticket 14107. + diff --git a/src/or/include.am b/src/or/include.am index fb1581c..b44e109 100644 --- a/src/or/include.am +++ b/src/or/include.am @@ -123,6 +123,9 @@ src_or_tor_cov_LDADD = src/or/libtor-testing.a src/common/libor-testing.a \ src/common/libor-event-testing.a \ @TOR_ZLIB_LIBS@ @TOR_LIB_MATH@ @TOR_LIBEVENT_LIBS@ @TOR_OPENSSL_LIBS@ \ @TOR_LIB_WS32@ @TOR_LIB_GDI@ @CURVE25519_LIBS@ @TOR_SYSTEMD_LIBS@ +TESTING_TOR_BINARY = ./src/or/tor-cov +else +TESTING_TOR_BINARY = ./src/or/tor endif ORHEADERS = \

1 0