- tor-dev - lists.torproject.org

Summary of meek's costs, June 2015
by David Fifield 06 Jul '15

06 Jul '15

Here's the summary of meek's CDN fees for June 2015. App Engine + Amazon + Azure = total by month February 2014 $0.09 + -- + -- = $0.09 March 2014 $0.00 + -- + -- = $0.00 April 2014 $0.73 + -- + -- = $0.73 May 2014 $0.69 + -- + -- = $0.69 June 2014 $0.65 + -- + -- = $0.65 July 2014 $0.56 + $0.00 + -- = $0.56 August 2014 $1.56 + $3.10 + -- = $4.66 September 2014 $4.02 + $4.59 + $0.00 = $8.61 October 2014 $40.85 + $130.29 + $0.00 = $171.14 November 2014 $224.67 + $362.60 + $0.00 = $587.27 December 2014 $326.81 + $417.31 + $0.00 = $744.12 January 2015 $464.37 + $669.02 + $0.00 = $1133.39 February 2015 $650.53 + $604.83 + $0.00 = $1255.36 March 2015 $690.29 + $815.68 + $0.00 = $1505.97 April 2015 $886.43 + $785.37 + $0.00 = $1671.80 May 2015 $871.64 + $896.39 + $0.00 = $1768.03 June 2015 $601.83 + $820.00 + $0.00 = $1421.83 -- total by CDN $4765.72 + $5509.18 + $0.00 = $10274.90 grand total The rate limiting of meek-google and meek-amazon has been partially effective in bringing costs down. The bill this month is the lowest it has been since February. I aimed to get the meek-google bill down to $500, the amount of the monthly grant we're getting from Google, and it came in a little above that. meek-amazon, on the other hand, did not decrease much at all. I think it may be because of Amazon's per-request billing. The number of users was pretty stable, staying mostly in the range 3000–4500. https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… If you want to set up your own bridge and CDN instance without rate limiting, I can help you do it. Here are some docs to look at: https://trac.torproject.org/projects/tor/wiki/doc/meek#Howtorunameek-server… https://trac.torproject.org/projects/tor/wiki/doc/meek#GoogleAppEngine https://trac.torproject.org/projects/tor/wiki/doc/meek#AmazonCloudFront https://trac.torproject.org/projects/tor/wiki/doc/meek#MicrosoftAzure == App Engine a.k.a. meek-google == Rate limiting brought down bandwidth usage almost 50%. Despite that, instance hours went up. The rate limiting happens at the bridge, so it's possible that requests are taking longer to process at the App Engine level, requiring more instance hours. Here is how the Google costs broke down: 2807 GB $336.87 5299 instance hours $264.96 Compared to the previous month: 5359 GB $643.07 4571 instance hours $228.57 https://globe.torproject.org/#/bridge/88F745840F47CE0C6A4FE61D827950B06F9E4… == Amazon a.k.a. meek-amazon == Bandwidth use was down about 16% compared to the previous month. The number of requests stayed about the same. As you can see, the major contributor to the Amazon bill is not bandwidth but the number of requests. I hope this ticket will help reduce the number of requests we make: "Use streaming downloads" https://trac.torproject.org/projects/tor/ticket/12857 Asia Pacific (Singapore) 114M requests $136.84 831 GB $111.35 Asia Pacific (Sydney) 845K requests $1.06 2 GB $0.40 Asia Pacific (Tokyo) 57M requests $68.43 336 GB $43.11 EU (Ireland) 184M requests $221.41 1454 GB $108.52 South America (Sao Paulo) 8M requests $18.87 53 GB $12.54 US East (Northern Virginia) 64M requests $64.23 422 GB $33.25 -- total 429M requests $510.84 3101 GB $309.17 https://globe.torproject.org/#/bridge/3FD131B74D9A96190B1EE5D31E91757FADA1A… == Azure a.k.a. meek-azure == meek-azure bandwidth use continues to increase, up 17% compared to the previous month. Keep in mind that our grant expires in October, so you should not count it continuing to work after that. Speaking of the grant, they switched me over to a new kind of sponsored account that will enable me to see the exact bandwidth use and what its cost would be. That should be available starting next month. Until now, we have had to estimate bandwidth usage by measuring at the bridge. https://onionoo.torproject.org/bandwidth?fingerprint=AA033EEB61601B2B7312D8… Estimated bandwidth use this month: 2015-06 3038 GB Compared to last month: 2015-05 2592 GB https://globe.torproject.org/#/bridge/AA033EEB61601B2B7312D89B62AAA23DC3ED8… Earlier reports in this series: https://lists.torproject.org/pipermail/tor-dev/2014-August/007429.html https://lists.torproject.org/pipermail/tor-dev/2014-October/007576.html https://lists.torproject.org/pipermail/tor-dev/2014-November/007716.html https://lists.torproject.org/pipermail/tor-dev/2014-December/007916.html https://lists.torproject.org/pipermail/tor-dev/2015-January/008082.html https://lists.torproject.org/pipermail/tor-dev/2015-February/008235.html https://lists.torproject.org/pipermail/tor-dev/2015-March/008427.html https://lists.torproject.org/pipermail/tor-dev/2015-April/008596.html https://lists.torproject.org/pipermail/tor-dev/2015-May/008767.html https://lists.torproject.org/pipermail/tor-dev/2015-June/008932.html

1 0

Chutney (was Re: Performance testing using chutney)
by Cory Pruce 06 Jul '15

06 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Well, you could test my latest branches for #14175: > > https://trac.torproject.org/projects/tor/ticket/14175#comment:8 > > There's a branch which modifies src/test/test-network.sh in tor, > and another with the performance measurement code in chutney. > > The command-line arguments/environmental variables are in the ticket, > and I've modified the chutney README to include performance testing. Cool! I'll check it out tonight and keep you posted :-) > > Maybe look at these for a start. It's something that's on my TODO > list, but I wouldn't complain if someone else happens to do it before I > do, and it would help HS scalability considerably[0]. > > https://trac.torproject.org/projects/tor/ticket/13737 > https://trac.torproject.org/projects/tor/ticket/13738 > > (If you happen to be more interested in making non-HS use cases faster, > then look elsewhere. :P) > > Regards, > Haha I'm interested in helping the performance/scalability of both HS and non-HS. I read the descriptions but they are pretty short and high level. Could you give any pointers to start? Does worker imply changes to cpuworker.*? - - Cory -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVmqHwAAoJEB7DuCIJauCgdtMP/02Ztn3IoikLU1s+MdiJRyNY /X9pTU667Lu6VAd2yhbMpYSQlgoPkR6bFElGhOWucihFN84zTxSBbNxaPwW36mAE rBNHgw41cGEBSva6chHNLJJGx/wpThbLDGYTqPvoQrDGWqgKNB1hK4IRRRFaRiC0 H+nBKR0xiH/sBY4PzIIfiX3BBVrA0ogV+kOzEIwDSjmnw4x24OMjD/Fx2VOK2tai dwpHw0QTW6Ao+WEVtXWPvzhKZTnvKcPKDkvLwo7fzdSmVTS9IUqQJCh8KdYUnt/5 uO4HR0WEdPOT7anA1TvrKzhRTe/8KHzTcPrCHJo7Dbt/rvc7RW0v4GSClTEtBlIU EcHRCvmG/SaCaw+H2IcCK9k5T/rt7azsADcKIhqDWMvttJkVmsHo9FbVldpzNB/z hwHfVYKsuOPWanpPrucn4opf5Td8LcQ+v6IAtwqQbslpe6myf6aX2GrulLZLi74R PT/lo0wqGh4V59HeAS5rG6mUVeI7vADmqlrzzFnsDxNMYP2OLsLquKl2noAFSbFk kD2xcQmy3kygS6SiLrDX95c1CefB0W56CcJBdkHrvyuhSltFngpXpcDyVSvyZnN8 giXWxWuZC9unIAvgWvlKnEnUQgGxVWT3ItCzxohXUFM0qturow9ii3D9iWsO4zkL K5EB0TLP8Fc3OstFcpt1 =tGow -----END PGP SIGNATURE-----

1 0

Re: [tor-dev] Roster introduction (Philipp Winter) (Sean Saito)
by saitosean＠ymail.com 06 Jul '15

06 Jul '15

Hi Philipp, > - I searched for my relay family by fingerprint and the resulting page's > URL didn't contain my family, so I couldn't send the URL to somebody > else. Could you give me some more details about this? Currently the search bar supports all running relays. The URL will contain the fingerprint you put into the search bar. > - The colour coding for relay flags is hard to read because of the low > contrast. Perhaps use green for assigned flags and grey for missing > flags? > - I would put the exit policy in a fixed-size box. Otherwise, there's a > lot of scrolling for large exit policies. Certainly possible. Thanks a lot for the suggestions. Sean

2 1

Hi, all!
by Nick Mathewson 05 Jul '15

05 Jul '15

I'm about to go on vacation, but before I started, Isabela asked me for coverage information on Tor, to help people decide where more tests should be written. I've re-run coverage, and uploaded the gcov output here: https://people.torproject.org/~nickm/volatile/coverage-65a1e27.tar.bz2 That archive includes coverage on current master from * make check * make test-network (uses chutney) * make test-stem (uses stem) * all of the above, combined I'm also attaching a script that I wrote long long ago, and use to summarize coverage file-by-file. Example use: gcov-lines.py ./coverage-65a1e27/cov-all/* yrs, -- Nick

2 1

Re: [tor-dev] Roster introduction (nusenu) (Sean Saito)
by saitosean＠ymail.com 05 Jul '15

05 Jul '15

Hi nusenu, > A few comments: > > - - the page seems to be AS name centric > - first column of the table is AS name > - only clickable column in the table is AS name > > - - the AS column suggests that all relays in a family run in one AS only > > - - the family page of a specific family shows the AS name as title, > this is a bit confusing as one might think that the page shows all > families/relays in the selected AS after clicking an as name on the > start page Agreed, this was just a placeholder. Will put contact info instead for now. In the future I would like families to have ids/nicknames as well. > Family identifier > > - - by looking at your page I assume your family identifier is the > fingerprint of the oldest relay in the family, does that mean that an > operator has to start over at 0 with collecting "points" once he kills > his oldest relay? That is not the case. Thanks for the comments! Sean

1 0

Bi-directional families in Onionoo and consensus weight as measure of relayed bandwidth
by Karsten Loesing 02 Jul '15

02 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moving this discussion here from another list with Virgil's permission. On 02/07/15 08:42, Virgil Griffith wrote: > Big issues right now are: * Bugs (?) in Onionoo --- Onionoo doesn't > sanitize its data. For example, there's a lack of bidirectionality > between relays of many families. > https://drive.google.com/file/d/0Bwjagz1RgJOnSkx0YTlhMHdfMFU/view?usp=shari… > > There are currently about 665 pairs of family relays without > bidirectionality. This is caused by the .torrc of some relays not > pointing to its family members. > > I am considering doing a service on top of Onionoo that sanitizes > the raw Tor consensus to ensure things like bidirectional families. > It's unclear how much other data needs sanitization. I'd rather want to fix/change Onionoo than have you write another service that processes Tor descriptors. There's even a ticket for this, we're just somewhat stuck by arguing about the best fix. Maybe I should just fix it somehow and, if necessary, fix it more later. https://trac.torproject.org/projects/tor/ticket/16276 Would that solve your problem? What other problems would there be with Onionoo's data? Can you make a wish list? > * A semi-reliable measure for the magnitude of traffic a relay has > routed. We have confirmed instances of relays forging their > observed bandwidth, ergo we can't use that. And thus far > Consensus Weight is the best we've found, but it's unclear whether > we can use that as a proxy of magnitude of relayed traffic. --- > https://docs.google.com/document/d/1v1rutylD6RkBei9rEmSvsgmvQXhrIHXOr85NL3I… > > Right now the lack of a reliable measure of how much bandwidth is > relayed is the largest sticking point. Actually, consensus weight (fraction) is a fine measure, and I like how you're calling it "bandwidth points" in your prototype which doesn't imply a bits per second or related unit. I'd say assign 10,000 bandwidth points to all relays per day, depending on what fraction of total consensus weight a relay had. To me, it's fine that this doesn't translate to bits or bytes. How does that sound? All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVlPKJAAoJEJD5dJfVqbCrZWQH/0lHSdgy4PF7nQ8RMZryKpnf o3Fvw8VkcIwZgJgp0MOLIVu0fZhcD8hhvSWd9yYTSpQwGwBayUJuPE0ao4MbfZYf mwz5hkngzq1Z7654K65m/fYLu7EIbXI86vT4/Cwwh8cnGl/ezaliFVvVMOmKTyOb UtV7T+Lgk5IgsGJOxQbpNHCTxyAokbAygqZ9Eq/6ZWqjZFBZb1P2XjV+IaziGyJl yuxrD66cJe4ZmcpPe9g7mTa9JyQ5kmUOWogXhKTFWDFCcPslc0M49iiYohDmiNxC 5RGKp1dMuYkL6th9b3Uuc3W4TdCMaDHV96BDUD3qdlqCWBU0fD617f31+Hsb6Bg= =0KdX -----END PGP SIGNATURE-----

4 7

Tor Messenger Third Alpha
by Sukhbir Singh 01 Jul '15

01 Jul '15

Hi, Tor Messenger is an instant messaging client currently under development. It is designed to make connections using the Tor network and will therefore be a valuable piece in the privacy-enhancing software toolkit (web: Tor Browser, email: Thunderbird + TorBirdy, chat: Tor Messenger.) Based on the Instantbird IM client, Tor Messenger: - sends all traffic over Tor, - enforces Off-the-Record Messaging (OTR) for one-on-one conversations by default, - can be used with a wide variety of chat networks, - has an easy-to-use graphical user interface localized into multiple languages. * Current Status Today we are releasing the third alpha version with which we hope to gain both usability and security related feedback. There have been two previous alpha releases to the mailling lists that have already helped smooth out some of the rougher edges. * What's New in Tor Messenger 0.0.6 - Support for Windows and OS X builds (in addition to Linux) - Improved privacy and security with network and application-related enhancements - Improved usability of the Instantbird OTR extension - Private key and known fingerprint management - XMPP in-band account registration support - Build localization support (currently Arabic; Chinese, Spanish, Farsi, and other languages coming soon) * Bundles Linux (32-bit): https://people.torproject.org/~sukhbir/tor-messenger-0.0.6/tor-messenger-0.… Linux (64-bit): https://people.torproject.org/~sukhbir/tor-messenger-0.0.6/tor-messenger-0.… Windows: https://people.torproject.org/~sukhbir/tor-messenger-0.0.6/tor-messenger-0.… OS X: https://people.torproject.org/~sukhbir/tor-messenger-0.0.6/tor-messenger-0.… sha256sum: https://people.torproject.org/~sukhbir/tor-messenger-0.0.6/sha256sums.txt https://people.torproject.org/~sukhbir/tor-messenger-0.0.6/sha256sums.txt.a… The bundles are signed with the key 0xB297B391. * Instructions - On Linux, extract the bundle and then run: ./start-tor-messenger. - On OS X, copy the Tor Messenger application from the disk image to your local disk before running it. On all platforms, Tor Messenger sets the profile folder to the installation directory. * Code We are doing automated builds of Tor Messenger for all platforms using rbm (Reproducible Build Manager): https://gitweb.torproject.org/tor-messenger-build.git * Arabic Language Pack https://people.torproject.org/~sukhbir/tor-messenger-0.0.6/tor-messenger-ar… Install the language pack as an add-on and then set "general.useragent.locale" to "ar". (Thanks to Sherief Alaa for the translation.) * Feedback This is an early release and there may be serious privacy leaks and other issues -- please DO NOT recommend Tor Messenger to end users; this release is only for developers and advanced users who would like to help us with testing but understand the risks involved with using alpha software. With this release, we invite feedback not limited to anonymity leaks, usability issues, feature requests and suggestions for improvement. Please submit your feedback using the bug tracker (bugs.torproject.org; select the "Tor Messenger" component). You can also talk to us on this mailing list or on IRC. Thanks, Arlo Breault, Nicolas Vigier, Sukhbir Singh

3 4

Stormy update
by Griffin Boyce 01 Jul '15

01 Jul '15

Hey all, It seems like time to give the tor-dev list an update on Stormy's development. Right now, the scripts are undergoing third-party testing to identify any obvious bugs before sending them to security auditors. Testing should be finished imminently, any bugs found will be fixed this week, and then sent to auditors (along with the GUI). The security audit may take about two to three weeks [1]. Currently, Stormy's functions include installing typical onion service dependencies (webserver+tor), setting up a Ghost-based content management system, creating a personal cloud server to handle files/rss feeds/calendars/tasks, installing an XMPP/jabber server for private communications, and installing an IRC server for group communications. Shortcomings and future work: Like all software projects, Stormy has some shortcomings. Users can't configure multiple onion services on the same machine as Stormy doesn't account for virtual hosts. For users to run more than one onion service, they must be on separate physical or virtual machines. Stormy also doesn't detect the currently-running clearnet service, so users who seek to make their existing service also an onion service may need to adjust their configuration manually. Currently, Stormy lives on my github page [2], though once it passes a security audit, the goal is for it to live within Tor's git repositories. best, Griffin [1] Cupcake's audit took about two weeks, so that's really my only real data point for audit timing. [2] https://github.com/glamrock/stormy -- “Sometimes the questions are complicated and the answers are simple.” ― Dr. Seuss

2 1

Re: [tor-dev] Discussions
by Cory Pruce 01 Jul '15

01 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yep, you got it! People find it easiest to read mailing list posts if the subjects match. And the threading works better that way, too. Any time you reply to and quote a previous email, cut out the extra stuff the mailing list adds in. And cutting out people's long signatures helps, too. Imagine you've googled a problem, and you're reading each email by itself - what do people need to know to follow the conversation? > I see now about top-posting though :D > Thanks, we all do that from time to time - most mail clients automatically top-post. > I kept the mailing list in the > loop for the readpassphrase.h but it's your call where you want to go > through the environment. I'm cool either way :-) > Stick as much as you like on the mailing list. People will tell you if it's too much. In fact, I'll stick my reply to your question about testing on tor-dev, as it's relevant. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 - --------------------------------------------------------------------------------------------- Awesome thanks Tim! I'm going to set up chutney later. Could you please send me the next steps you think would be good for a Tor testing environment? Thanks for your help! Cory -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVksKGAAoJEB7DuCIJauCgM7MP/1ZbuSuo53Mz/8YBzA8FZPX1 yATAWJudqPaPH0m1nQS72x2Bzarz5UhCCGq2YpAhocoo1rEam+wIqcSJ7KUVso1H 1ViuKRjUWjgevAB33zdCWkZZtaKhg/r8zFpqMD8VL6N2ae3ypiY+nnw0vyEJZNZf YnUjoH+YNab/ftRv16/d72bmzHeylVRBcJX6OmSzSlCuCWROlptez3hG+xl52NHv q1obXuyWn36ba8agIeo3OFIX7sQ9Ok3Hvyr/Sve9QEt+FnB24yswS5X3izl8MtZZ Rs9Kz/RZsrH8AGAWmz+h6IIdGK/cmycsLk7bQyDzWHjzuDuIOtvXe5B4xizmoNEW in0Qxg5LfSklc8nN2531AbMExMoQsOW7ciNbQK7lQQlm8ZRb5U/ghWhjKc6PqZ8Z bWGv/vQQyzOQofsgaOm9Tul8vOPGk/e7a5mWRLj167ZuFRY/9d8I4K2mdjm45OQT Lz/gloDCV61IcMzEmmj3Ga8U2oWDicmKbJeNk7RnD9nPNr3JR9yKLEDRUD59Fp43 i4ZplSV0eIFDzozx0aZnVE/ctqyK9wDWWBVaTbsJfXcdV5h+DfGbtzPIdq2CA/cl 1Id94kqqGL00MlYuzw0eHcH5ssUIpVRGg96njolcCFgE/ipfWrFCTW+dxpuXD+p2 0unsHjaY0Am+T+NMPmCr =v2h0 -----END PGP SIGNATURE-----

2 2

Re: [tor-dev] Discussions
by teor 30 Jun '15

30 Jun '15

> On 1 Jul 2015, at 01:29 , Cory Pruce <corypruce(a)gmail.com> wrote: > > I've been able to do a > make install and am ready to continue setting up the test environment. I > see chutney on your github. I'll get that set up when I get home. Do you > have any advice for testing Tor? Also, feel free to move this to the > mailing list whenever you feel it's appropriate. > Hi Cory, I'm moving this to tor-dev as it's relevant to other developers. Chutney Please use the official chutney repository at git.torproject.org <http://git.torproject.org/> My chutney repository a little messy at the moment, and I've merged draft throughput-testing code into my master branch. You're welcome to test the draft code by merging https://github.com/teor2345/chutney/tree/bug14175-bandwidth <https://github.com/teor2345/chutney/tree/bug14175-bandwidth> The throughput-testing functionality works, but it needs to be tidied up, and have the hard-coded constants turned into command-line options. So it's not ready for release, but it is ready for an early review to check for functionality gaps and bugs. You might find throughput metrics useful to confirm that any multithreading changes are actually improving performance. Testing Once tor is built, you can test it using: # basic tests make test # extended tests make check # benchmarks /src/test/bench # verify tor connectivity using a local test network - requires chutney make test-network # verify that the core functionality of tor works, requires chutney and IPv6 on localhost src/test/test-network.sh --flavour bridges+ipv6+hs # verify that the core functionality of tor works, using chutney, but without IPv6 src/test/test-network.sh --flavour bridges src/test/test-network.sh --flavour hs There's also various other testing tools: shadow Tor network simulator static analysers, such as coverity and clang-scan dynamic sanitizers: Undefined Behaviour (UBSan), Address (ASAN), … fuzzing (I'm working on some tor-specific harnesses for fuzzing, but they're not ready) and I'm sure there are others which I've missed. Generally, I'm happy with code once I know it: * compiles with no warnings, * passes the extended unit tests (make check), including any tests written for new functionality, and * passes all the connectivity tests in a comprehensive test network (bridges+ipv6+hs). For bonus points, you can compile tor using UBSan and ASAN. If you're using clang, you'll find that tor/contrib/clang helps with setting this up. It lists known undefined behaviour in the Tor codebase, so it may be useful if you want to do something similar with gcc. (However, getting sanitizers to work can be incredibly fiddly and a total time-suck, too. So if it's just not working, skip it.) I'll also occasionally run code through a static analyser, to find subtle bugs which haven't been uncovered using UBSan/ASAN. Again, this isn't something everyone needs to do. Others may have advice on testing multithreading code in particular. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

Damian's Status Report - June 2015
by Damian Johnson 29 Jun '15

29 Jun '15

Guten morgen lovely people of the Internet. This June my grandpa passed away so spent quite a bit of time with family. Tor stuff didn't get much attention, but I did revise a couple small parts of Nyx. -------------------------------------------------------------------------------- Nyx Installer and Descriptor Dialog Rewrite -------------------------------------------------------------------------------- This month I rewrote the installer of Nyx and its descriptor dialog. As usual this was mostly about cleaning and stabilizing the codebase. Only functional changes were... * Our setup.py now supports --man-page and --sample-path arguments for customizing resource locations. * Test coverage for installation. * Installing and our tests are now python3 compatible. Sadly no, this doesn't mean Nyx runs under python3 just yet but it's a step in that direction. * The descriptor dialog now shows microdescriptors (this part of the codebase predated them). Cheers! -Damian

1 0

Re: [tor-dev] tor-dev Digest, Vol 53, Issue 27
by Cory Pruce 29 Jun '15

29 Jun '15

Thanks teor, that'd be awesome! I've been able to resolve most of the dependencies easily until the file "readpassphrase.h" (and thus .o) was shown to be missing during make. Are you still using the git branch? I'll definitely take a look into the throughput tool once I get set up :D - Cory On Mon, Jun 29, 2015 at 5:00 AM, <tor-dev-request(a)lists.torproject.org> wrote: > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. List of projects (Cory Pruce) > 2. Re: List of projects (Nick Mathewson) > 3. Re: List of projects (Cory Pruce) > 4. Re: Multithreaded crypto on Tor (teor) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 28 Jun 2015 11:12:45 -0700 > From: Cory Pruce <corypruce(a)gmail.com> > To: dgoulet(a)torproject.org, nickm(a)torproject.org, > meejah(a)torproject.org, atagar(a)torproject.org, > tor-dev(a)lists.torproject.org > Subject: [tor-dev] List of projects > Message-ID: <5590391D.6020900(a)gmail.com> > Content-Type: text/plain; charset=utf-8 > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey, > > I see now that the multithreading on the crypto operations is at least > partly resolved (#9682) but there still exists more to be done. I could > help on the condition variables and possibly more with that project or > another one from the project ideas on the Tor volunteer page. For > example, I've worked with the Stem library before doing primarily > traffic analysis in a class at Carnegie Mellon. If no one has worked on > the first option, I could do that as well. Please let me know if any of > you are willing to discuss these with me! I'd like to hear back knowing > that I'm talking to other human beings :-) Sorry if this isn't the way I > should be contacting. If so, let me know! > > - - Cory > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBAgAGBQJVkDkdAAoJEB7DuCIJauCg7q0P/0KNxwoLPo1ZlsO7X5/p+yC5 > qHDHrAuVworNkER/t35xEQPJmGy9hTp7XaxHm2JWwbKpkWtS9dbTVA5LPD5esRsz > z5dhJOwKOXh9BIQ3qjBk22OPg1YbUJ8ykwTiwUY5BM/Tilk6UZqmjZDCOlpp5ufv > F4w9tUL9ug+K6VRnM/XksZhYjx1Wnhei5PesfZoTBiggj4T0q/16amduIhyALilm > HY5hHVCxo9mvmBBwzUwkRhi+kQ39eeLCggRbBqQv+WsYH8FNesoUcxFjy/AGzTGT > 4Ul4M8E41oHudtvmFIqzEgMmV5TjZaSR5X52aW+7mQAXRAH6IzxX8E+ji5CJIWLo > pE2zPV3dX+AsYx1lkU/x0hZvX2537wt8pNWka0ORTn7HKLnb/6NoaC7gYHr8ZftR > gcbSru49xyWNmzjfXSok7Unfih37MQY8Y1nGNqauHo8lZ38qmAnsdaGzAB409RgP > R30G82hg2QRFBA1486IqP/LtSxhk1UdEyWWvVlXWOYRvVF68l3g1mHVswIxT3k4G > z3a+0EmwF52xxvzgmMwTlxeWfa1/3uQA3w2el9e92/Xtc5lw66nE/k+kX7Mpg7GM > kDFZ0UkBgxXATy0kuCdU7enZjzpn6M1vDwhfmovpGAMDVaaMZzzII17KEJyVv8Sp > G7Wxg+lZjr9SOvRIOxf1 > =Ebps > -----END PGP SIGNATURE----- > > > > > ------------------------------ > > Message: 2 > Date: Sun, 28 Jun 2015 17:35:47 -0400 > From: Nick Mathewson <nickm(a)torproject.org> > To: Cory Pruce <corypruce(a)gmail.com> > Cc: Damian Johnson <atagar(a)torproject.org>, meejah(a)torproject.org, > tor-dev(a)lists.torproject.org, David Goulet <dgoulet(a)torproject.org > > > Subject: Re: [tor-dev] List of projects > Message-ID: > <CAKDKvuzxLDGjokxZK26_X=_ > H9-J_wMdOYrOakyGv2cs6kdPSig(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Sun, Jun 28, 2015 at 2:12 PM, Cory Pruce <corypruce(a)gmail.com> wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hey, > > > > I see now that the multithreading on the crypto operations is at least > > partly resolved (#9682) but there still exists more to be done. I could > > help on the condition variables and possibly more with that project or > > another one from the project ideas on the Tor volunteer page. For > > example, I've worked with the Stem library before doing primarily > > traffic analysis in a class at Carnegie Mellon. If no one has worked on > > the first option, I could do that as well. Please let me know if any of > > you are willing to discuss these with me! I'd like to hear back knowing > > that I'm talking to other human beings :-) Sorry if this isn't the way I > > should be contacting. If so, let me know! > > Hi, Cory, and sorry about the delay! I saw your earlier two messages, > and I just thought I'd send you a quick note today to say, "Yup, we > got them!" I'm going to be a little more slow responding than I would > like, since I'm preparing for a trip to PETS > (https://petsymposium.org/2015/) but I'll try to write back some > actual useful info as soon as I can. > > cheers, > -- > Nick > > > ------------------------------ > > Message: 3 > Date: Sun, 28 Jun 2015 14:37:07 -0700 > From: Cory Pruce <corypruce(a)gmail.com> > To: Nick Mathewson <nickm(a)torproject.org> > Cc: atagar(a)torproject.org, meejah(a)torproject.org, David Goulet > <dgoulet(a)torproject.org>, tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] List of projects > Message-ID: > < > CANOqyr7fzF2ADbmYof+Pufd3DGgFwVNqmLkZzvVSKecz_7QywQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Awesome, no worries. Thanks! > On Jun 28, 2015 2:35 PM, "Nick Mathewson" <nickm(a)torproject.org> wrote: > > > On Sun, Jun 28, 2015 at 2:12 PM, Cory Pruce <corypruce(a)gmail.com> wrote: > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Hey, > > > > > > I see now that the multithreading on the crypto operations is at least > > > partly resolved (#9682) but there still exists more to be done. I could > > > help on the condition variables and possibly more with that project or > > > another one from the project ideas on the Tor volunteer page. For > > > example, I've worked with the Stem library before doing primarily > > > traffic analysis in a class at Carnegie Mellon. If no one has worked on > > > the first option, I could do that as well. Please let me know if any of > > > you are willing to discuss these with me! I'd like to hear back knowing > > > that I'm talking to other human beings :-) Sorry if this isn't the way > I > > > should be contacting. If so, let me know! > > > > Hi, Cory, and sorry about the delay! I saw your earlier two messages, > > and I just thought I'd send you a quick note today to say, "Yup, we > > got them!" I'm going to be a little more slow responding than I would > > like, since I'm preparing for a trip to PETS > > (https://petsymposium.org/2015/) but I'll try to write back some > > actual useful info as soon as I can. > > > > cheers, > > -- > > Nick > > >

1 1

Re: [tor-dev] Multithreaded crypto on Tor
by teor 29 Jun '15

29 Jun '15

> Date: Sat, 27 Jun 2015 20:44:02 -0700 > From: Cory Pruce <corypruce(a)gmail.com> > To: tor-dev(a)lists.torproject.org > Subject: [tor-dev] Multithreaded crypto on Tor > Message-ID: <558F6D82.2010400(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi! > > Let me start by introducing myself. My name is Cory Pruce, am an > Information Technology - Information Security Master's student at > Carnegie Mellon, and would like to get more involved in Tor! I have done > a bit of programming in C and have a pretty substantial crypto > background. I'm not in the Google summer of code but would really like > to complete this project :D (see screenshot) Please let me know if > anyone is currently working on this and if Nick, David, or anyone would > like to give me some advice and be someone I can bounce ideas off of :-) > > Thanks and I hope to hear back soon! > > - Cory > > P.S. I have cloned the repo and have been looking through relay.* and > cpuworker.* files. I just would like to speak with someone before I jump > in :p Hi Cory, Multithreaded crypto is a *very* popular request on the tor-relays mailing list, as many relays have multiple cores, and significant network bandwidth. Tor limits the number of relays per IPv4 address to 2 to mitigate sybil attacks, so the best way for relay operators to increase their throughput is multithreaded crypto. I'm not familiar with the specifics of tor's multithreading implementation, but please contact me if you need assistance setting up a local test network. I've made some recent changes to the chutney test tool which allow throughput to be measured. These changes work on Linux and OS X, but they're still under review, and the git branch isn't as organised as I would like. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

List of projects
by Cory Pruce 28 Jun '15

28 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey, I see now that the multithreading on the crypto operations is at least partly resolved (#9682) but there still exists more to be done. I could help on the condition variables and possibly more with that project or another one from the project ideas on the Tor volunteer page. For example, I've worked with the Stem library before doing primarily traffic analysis in a class at Carnegie Mellon. If no one has worked on the first option, I could do that as well. Please let me know if any of you are willing to discuss these with me! I'd like to hear back knowing that I'm talking to other human beings :-) Sorry if this isn't the way I should be contacting. If so, let me know! - - Cory -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVkDkdAAoJEB7DuCIJauCg7q0P/0KNxwoLPo1ZlsO7X5/p+yC5 qHDHrAuVworNkER/t35xEQPJmGy9hTp7XaxHm2JWwbKpkWtS9dbTVA5LPD5esRsz z5dhJOwKOXh9BIQ3qjBk22OPg1YbUJ8ykwTiwUY5BM/Tilk6UZqmjZDCOlpp5ufv F4w9tUL9ug+K6VRnM/XksZhYjx1Wnhei5PesfZoTBiggj4T0q/16amduIhyALilm HY5hHVCxo9mvmBBwzUwkRhi+kQ39eeLCggRbBqQv+WsYH8FNesoUcxFjy/AGzTGT 4Ul4M8E41oHudtvmFIqzEgMmV5TjZaSR5X52aW+7mQAXRAH6IzxX8E+ji5CJIWLo pE2zPV3dX+AsYx1lkU/x0hZvX2537wt8pNWka0ORTn7HKLnb/6NoaC7gYHr8ZftR gcbSru49xyWNmzjfXSok7Unfih37MQY8Y1nGNqauHo8lZ38qmAnsdaGzAB409RgP R30G82hg2QRFBA1486IqP/LtSxhk1UdEyWWvVlXWOYRvVF68l3g1mHVswIxT3k4G z3a+0EmwF52xxvzgmMwTlxeWfa1/3uQA3w2el9e92/Xtc5lw66nE/k+kX7Mpg7GM kDFZ0UkBgxXATy0kuCdU7enZjzpn6M1vDwhfmovpGAMDVaaMZzzII17KEJyVv8Sp G7Wxg+lZjr9SOvRIOxf1 =Ebps -----END PGP SIGNATURE-----

2 2

Multithreaded crypto on Tor
by Cory Pruce 28 Jun '15

28 Jun '15

Hi! Let me start by introducing myself. My name is Cory Pruce, am an Information Technology - Information Security Master's student at Carnegie Mellon, and would like to get more involved in Tor! I have done a bit of programming in C and have a pretty substantial crypto background. I'm not in the Google summer of code but would really like to complete this project :D (see screenshot) Please let me know if anyone is currently working on this and if Nick, David, or anyone would like to give me some advice and be someone I can bounce ideas off of :-) Thanks and I hope to hear back soon! - Cory P.S. I have cloned the repo and have been looking through relay.* and cpuworker.* files. I just would like to speak with someone before I jump in :p project

1 0

Tor dev meetings schedule changes for July
by Nick Mathewson 27 Jun '15

27 Jun '15

Hello, all! Usually the Tor development team has our weekly online[1] Tor developers meetings at Wednesday 1330 UTC (==0930 EDT), and our weekly online patch workshop time at 1800 UTC (==1400 EDT). (This is for the program 'tor', not for all the other software that happens in the Tor universe) But for the first week of July, a lot of people will be in PETS[2]. And for the second week, I'll be on vacation. So here's the revised schedule. Tuesday, June 30: Patch workshop goes on as scheduled. Nick and a few others will probably be absent. Wednesday, July 1: No weekly dev meeting! Tuesday, July 7: Patch workshop goes on as scheduled. Nick will be absent; others will be back. Wednesday, July 8: Dev meeting goes on as scheduled. Nick will probably be absent, but will send in an update somehow. For the rest of the month, we'll be on a regular schedule. [1] #tor-dev on OFTC [2] https://petsymposium.org/2015/ best wishes, -- Nick

1 0

Fwd: Orbot v15.0.1 beta 3 and NetCipher update
by Nathan Freitas 26 Jun '15

26 Jun '15

----- Original message ----- From: Nathan of Guardian <nathan(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: Orbot v15.0.1 beta 3 and NetCipher update Date: Fri, 26 Jun 2015 10:19:49 -0400 *** Orbot v15.0.1 beta 3 released *** From: https://dev.guardianproject.info/news/233 See our previous news update (https://dev.guardianproject.info/news/231) for the more data or review the changelog here: https://gitweb.torproject.org/orbot.git/tree/CHANGELOG?id=e00f830ecadbca1b0… We've pushed the release to our Google Play beta channel (https://play.google.com/apps/testing/org.torproject.android) and our /release folder here. APK: https://guardianproject.info/releases/Orbot-v15.0.1-beta-3.apk PGP Sig: https://guardianproject.info/releases/Orbot-v15.0.1-beta-3.apk.asc You can also use FDroid to subscribe to our nightlies repo here (please uninstall any other version of Orbot first): https://dev.guardianproject.info/debug/org.torproject.android/fdroid/repo *** NetCipher library updated (v1.2) *** We've also updated our NetCipher library to support the update Intent API in Orbot that supports background starting, improved status messages via broadcasts and more. NetCipher also includes clearer code for support HttpUrlConnection proxying, TLS socket hardening, and has been re-organized a bit for clarity. https://github.com/guardianproject/NetCipher The sample app shows how to use these classes: https://github.com/guardianproject/NetCipher/tree/master/sample -- Nathan of Guardian nathan(a)guardianproject.info

1 0

update obfs4proxy in deb.torproject.org
by s7r 24 Jun '15

24 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, An update is needed in http:// deb.torproject.org/torproject.org obfs4proxy main to version 0.0.5 (we currently have 0.0.4). armel and amrhf packages for obfs4proxy would be nice too, for mobiles/tablets/raspberrys etc. Also, why do we have tor-experimental-0.2.6.x-$dist_codename and tor-nightly-0.2.6.x-$dist_codename - any difference between them? I know 'nightly master' is for latest alpha dev release, but what's the experimental used for? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJVhzu8AAoJEIN/pSyBJlsRIXgH/1v01c0oArU6E/xyzfi4DLN6 6bLK9emfzTAimtwgIQfH1POL+GR3xqpLl5TURN0wGEdI1Sm1vBK6wg0/mnsjNJAD +yulRlfJlbjLn+H2TJ1XFsKNQudIRpstdjQ0hyrA4SmOV3V42rk6taQSdM/b+zwG 2v54+P05Th/bbq63UDKoLjbzal/sMUe+2l1lYxO1BbxiXL9JkGU5qCTnG8uM+yXK IEXCdDlZpEdmov6ueP3PdiCrhS9v5HsZ7TIGKqVuuie6Kf1yrxIgBP5rlKsdJgqI V1bnHyhs1zvME+Klw+DF8Axqb1PqPY/dV5WoIo+s++H3+phA1TSmG46ebj5WG6E= =R2Kk -----END PGP SIGNATURE-----

2 1

Re: [tor-dev] The future of GetTor
by Adam Pritchard 23 Jun '15

23 Jun '15

> > I'm currently the maintainer of GetTor [1], and together with Nima and > Sukhbir we have been talking about the future of it. If this conversation moves elsewhere, I would really like to be kept in the loop. I'm the primary maintainer of Psiphon's email auto-responder, which was initially modeled on Tor's approach. Psiphon is, obviously, also extremely interested in robust ways of making our tools available in censoring regions. (So, Satori, etc., are also interesting.) Relatedly... When doing Logjam, etc., testing on our responder I found testssl.sh[1] to be a handy tool. Used like so: ./testssl.sh --mx torproject.org CheckTLS[2] is also good for actually doing email send and receive tests. We're currently struggling a bit with just how hardcore we can be in securing our server communications. Right now Postfix is configured[3] to only connect out using TLS and only accept incoming TLS connections from servers with a verifiable cert. That seems reasonable, except... we're getting complaints that Chinese mail services don't meet those criteria, and Chinese users can't/won't/don't use Gmail/Hotmail/Yahoo. ...As an example of the sort of shared hurdles we might encounter. [1]: https://testssl.sh/ [2]: https://www.checktls.com/ [3]: https://bitbucket.org/psiphon/psiphon-circumvention-system/src/2d052db9597d… -- Adam Pritchard Psiphon Inc.

2 4

small patch to allow gcc -fno-common for better ASAN coverage
by starlight.2015q2＠binnacle.cx 23 Jun '15

23 Jun '15

Per https://code.google.com/p/address-sanitizer/wiki/Flags one benefits from compiling with -fno-common when -fsanitize=address is active The attached patch converts the single common variable to a global/extern variable. Seems a good idea to me. Have run this with no issues, but more ASAN coverage is better than less.

1 0

How bad is not having 'enable-ec_nistp_64_gcc_128' really? (OpenBSD)
by nusenu 23 Jun '15

23 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, since enable-ec_nistp_64_gcc_128 is disabled by default on OpenBSD due to compiler bugs [1] I wanted to ask how bad is it (in relay context) to ignore the usual tor log entry: > We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, > but with a version of OpenSSL that apparently lacks accelerated > support for the NIST P-224 and P-256 groups. Building openssl with > such support (using the enable-ec_nistp_64_gcc_128 option when > configuring it) would make ECDH much faster. Tor's changelog "highly recommends" it [2]. Can this be "translated" to something like "the relay's bandwidth usage and usefulness will be reduced" "latency will be higher" "security will be degraded due to fallback to DH-1024" ? thanks, nusenu [1] http://article.gmane.org/gmane.os.openbsd.misc/218944 [2] https://gitweb.torproject.org/tor.git/plain/ReleaseNotes?id=tor-0.2.5.10 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJViDmDAAoJEFv7XvVCELh0Fi0QAKF0/7eVWgL5gExyGcCugz66 9CJOaNGVdeqb8LDxH/KEW4xC+MLhqMQ/+dL7iVOZIOtCM6i4vTpD3u4ZVnFhcGfx luyX78TqXDW3riV3izBWYScYxQdeHGv3XFXQlbGi7WQYfRt0AdorchmP2xuxD7Cg zGZFk4Bggj3qnW1sd/G3JvJL0bUi7iBKrQwPTDlnK3YSGbTYpU6lS3dQqbHqNYin yrwtlNSCi9DFjbQm5g4yjvaawnmOuxf8dlm54Ltjdn2cIHsXaPqQ6kXICiukrJhE ZLfTnPBd3yngyoq9xe7bW9P4mNVkTNmAU3VqGgEq1gSUJQObXkzOKAz63z9WAqQl GBvZFtwkbdBM4pjfWaG5FjDRc+awXxP/8K/d2vF2r6KAwkbh9Fw2uhjC6yu5c6hB KtQaovd+we+Ag4vDdE6lbQPLiCbPBiFdB6qYjkWbVflYcrsYQPoCgwjaodbV7I/Y 8Kb3Lx2C8+HFLtktEh19tOk34iKVliQk7FjE2FoiKkWryRYtY5KUAfFS8hOCfBqr 2XYtWGqQ9eh14RqvBu7CuN1cKCc0EQLcr6BF9uvd6EYtKZsa5rQC+y9Bbbd65MwB qU7lLckEkG+qwzgvuyOBvGwN8JmMmTBQASsdalAUscQFbPq7wySp9tz21pu8mOje NRRdnL1/3X9KcCMLMCVk =Oa2Z -----END PGP SIGNATURE-----

4 4

Re: [tor-dev] The future of GetTor
by teor 22 Jun '15

22 Jun '15

> Date: Thu, 18 Jun 2015 19:37:07 -0300 > From: ilv <ilv(a)riseup.net> > To: tor-dev(a)lists.torproject.org > > > … > >> Is it possible to submit an app to the app stores (I am thinking Apple's restrictions, here) that would bootstrap a Tor Browser download over the Tor network? >> >> For example: >> 1. Download app >> 2. The app has various CDN links (or a way of getting them) and a some predefined bridges >> 3. The app tries the CDN links and bridges in order of reliability / expense >> 4. If the links or bridges fail, the user gets advice on how to find new, uncensored links or bridges and input them. >> 5. App downloads and verifies Tor Browser using the CDN or the Tor network >> >> In most cases, the user experience would be one-click: >> 1. Open the app >> 2. See a recommended option highlighted out of a list of working options >> 3. click download >> 4. see a progress bar >> 5. Get a verified Tor Browser >> > > Yes, the use experience that you mention is what we're looking for. > About using the Tor network... I'm not sure about it. It's like using > Tor to download Tor? Still, I'll write it down as an option. People can use the Tor network to download Tor Browser, with the aid of a bootstrapping program. (Which can be much simpler than Tor Browser itself - see below.) If people can't use the Tor network to download a file, then it's unlikely that Tor Browser will work for them. My reasoning went something like this: 1. If we can put Tor Browser in an App Store, people won't need to use an app that downloads Tor Browser 2. If an App Store doesn't allow Tor Browser, then people need an app that will download Tor Browser 3. Perhaps the App Store will allow an app that can download Tor Browser over the Tor network (this could be as simple as tor, torify, and wget executables, and a GUI frontend) teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

2 1

The future of GetTor
by ilv 22 Jun '15

22 Jun '15

Hi people, I'm currently the maintainer of GetTor [1], and together with Nima and Sukhbir we have been talking about the future of it. First, let me present you what is (roughly) the current status of GetTor: * We send links to download Tor Browser, along with its signature file. These files are stored on Dropbox. I will be working on integrate new cloud/hosting services during Summer of Privacy. * We send these links via email. I will be working on new modules to send links via chat (XMPP) and Twitter (DM) during Summer of Privacy. * We send links to download the English (US) package of Tor Browser. I will be working on support for more locales during Summer of Privacy. That is what we have now. Is not much, but it works (more info in [1]). So, what about it? Software evolves, and we think it might be the time of GetTor to go beyond its current design. Moreover, we have received valid concerns that emails could be tampered and users could get malicious versions of Tor Browser (although we have no evidence that this is happening). Right now, when you get the Tor Browser via this method is up to you to verify its integrity. With this in mind, we have been discussing about the idea of having a signed and verified distributor app (desktop), available on official channels (OSX app store, Google Chrome store, etc), which could ease the process of downloading and verifying the integrity of Tor Browser. In other words, a user should be able to download and make sure it has the right file with just a few clicks. However, we have different thoughts on how this should work: * Option 1: GetTor should work as a backend and have an API. The distributor (and even other apps) would send queries to this API asking for links. The problem with this is that if Tor Project's website is blocked, is quite possible that the API would be blocked too (e.g. gettor.torproject.org) * Option 2: The distributor is in charge of presenting various alternatives to the user and getting the files directly from the cloud/hosting services. So, the purpose of this email is to get feedback from the community, and my specific questions to you people are the following: 1) What do you think of the distributor idea? It is something you or others would want? 2) In case we develop the distributor, should the email autoresponder remain? 3) If you agree on developing the distributor, what option you think would fit better? (please suggest better options) I would really love to hear your comments about this idea, my work at Summer of Privacy might change depending on this discussion, so please feel free to express your feelings about it :) Thanks for your time! [1] https://www.torproject.org/projects/gettor.html.en [2] https://trac.torproject.org/projects/tor/wiki/org/roadmaps/GetTor --ilv

4 6

draft-grothoff-iesg-special-use-p2p-exit-00.xml
by Christian Grothoff 22 Jun '15

22 Jun '15

Dear all, Following https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/ and the separation of .onion in https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01 to satisfy the IETF's desire to have lots of documents, I've now split off ".exit" as well to create draft-grothoff-iesg-special-use-p2p-exit-00 I've attached the current draft to this e-mail and would appreciate any feedback you may have. Also, if you feel that this is the wrong move entirely (i.e. because you don't want to reserve .exit), please do let me know ASAP and then I won't submit the draft. Happy hacking! Christian

1 0

2nd status report for OnioNS
by OnioNS Dev 21 Jun '15

21 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello everyone, Work on the Onion Name System (OnioNS) continues. As stated in the previous status report, my primary focus now is separating the server components. In the last release, a single name server handled everything, making it a centralized system. I have made significant progress in seperating roles such that one machine acts as an authority while another machine returns Records and digital signatures to clients. This reduces the loads and responsibilities and is the key step towards creating a true distributed system. During implementation, I decided the scrap the Snapshot data structure and its protocol. A Snapshot is basically a server-side short-term cache of Records that is then flushed out periodically. The issue is that in the event that two HSs claim the same name within a short time period of each other and transmit their Records to two different Quorum nodes, when the Snapshots are flushed out it's non-trivial to decide which one took precedence. Snapshots were originally intended to save networking costs and reduce the risk of timing attacks, but in the end I realized that it didn't actually reduce networking costs, and timing attacks are an acceptable risk given Tor's design and threat model. So instead, servers can now subscribe to other servers for network events. If server B is subscribed to server A, when a Record is transmitted from a HS through a Tor circuit to server A, it sends the Record to B immediately. Thus all Quorum nodes will subscribe to all other Quorum nodes, and Mirrors can subscribe to one or more Quorum nodes, and Mirrors can subscribe to other Mirrors. This allows new information to propagate across the network immediately. This simplifies some of the protocols and fixes a significant problem. I have also made significant progress on logging events to file, rather than to std::cout. I am also planning on loading networking information from a file, simulating a Quorum, maintaining a debug package, and launching the software with the Tor Browser. I have made progress on all of these and have listed them in a milestone, scheduled to be included in the next major release: https://github.com/Jesse-V/OnioNS/issues?q=is%3Aopen+is%3Aissue+milestone%3… See you at PETS! - - Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVhhTEAAoJEK2XNk/CC+yAIdMH/AlUiqCFsQCESe1I6tUzYfHO 4DLTZGVInSC1AMjhdO4RBLuO/MZuZgGAzsitI65KEOkYBAFd7TGOu8DMDbfU9tdt d9yRVshqP/LSd9b9/WmmVZTq0zazkZDOBYELcrXBw3ic4tu+HdJ5E3yl/Fm2bE5C eu0gVbBipvbj332cypqf6J2xpP5gQN5pdSLh+AHRqgMN1K9huTw/yq2/Kgu2ZmhX 8AoMerNmkQ9Wj+tUcyW+Ab9+SFUrkeYUxPp60WVXXciD311uUhKTKknGjRDgBNZw YSI/2RrHkW2342XfvaiI7qbgfnSKQx5yko9KxV2ab1JSpzgocgutWRjwSZFIt/M= =rqna -----END PGP SIGNATURE-----

1 0