- tor-dev - lists.torproject.org

fteproxy v0.2.1
by Kevin P Dyer 11 Dec '13

11 Dec '13

Hi dcf1/asn, Yesterday I tagged release v0.2.1 of fteproxy. In this release I focused on breaking away from heavyweight dependencies: OpenFST and boost. Cross-platform PTTBB binaries are available on the fteproxy website: https://fteproxy.org/download. asn - Please have a look at the code and confirm that you're happy. I had to make a few changes to the Python modules written in C++, as I can no longer rely upon boost::python. I've also added additional information to the function-level descriptions, which should help explain the significance of the language theoretical algorithms. It is also worth noting that the pseudocode is available in Appendix A of the full version of our paper [0]. dcf1 - I finally have the gitian build process producing vanilla binaries. However, I don't see anything specific to pluggable transports in [1] or [2]. Is there a fork of this code that has logic for building the pluggable transports? Or is that still an open task? -Kevin [0] http://eprint.iacr.org/2012/494 [1] https://gitweb.torproject.org/builders/tor-browser-bundle.git [2] https://gitweb.torproject.org/builders/gitian-builder.git

2 1

txtorcon 0.8.2
by meejah 10 Dec '13

10 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 First, sorry this announcement is a little late, this was in my drafts :( There was a bug in txtorcon 0.8.1 where the TCP4HiddenServiceEndpoint wasn't ensuring that only 127.0.0.1 was being listened on. GitHub's master and the tag v0.8.2 fix this issue, and (thanks to Lunar) the Debian packages are also updated. PyPI packages are also updated (via Twine this time, which is really nice). If you don't use TCP4HiddenServiceEndpoint, there is no need to upgrade. If you *do* use it, you should upgrade. Thanks, meejah -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSp03QAAoJEJ0UOBRRgEVQWPcIAMV0aupijakh3GUBqF2s0zEp TxPr658w0KDZuWH9cON9h/Apkss0BQnW2LuoPKP4spAXh8qOlUd6sBzj+fat2RwE 09qkJPKuyt6kGZyxD5jRL3pRNEBU8qs0C6AIcdysfpfWRGOx53ZOjJgBoanzzmRA JmdFQBtAVBCW0IzImFpf8rCIQpx/8SXtA898RqQODANdtxucwqRVqC/Y5uX+7a29 xdtgFpr7NcqW2KC0WMInubQ6lo6KfPgCfnrSU2FBcafwdXlh97cmdovzUX0/raSM bHJvgruPyF1hJBDuTHXzKbnb41Xb0Vk6MMALw3ad3t505jFDhZT1g8kBw0mo1Qk= =PM/Z -----END PGP SIGNATURE-----

1 0

Apple App Store Redux
by Griffin Boyce 10 Dec '13

10 Dec '13

It's been a while since there's been a discussion on-list about getting the TBB into Apple's app store [1]. Interest hasn't really gone away in the intervening 13 months, so I just want to open up discussion about it. Here are the issues as I see them: - Apple has traditionally been at odds with GPL-licensed stuff [3], though of late it seems to have relaxed a bit with dual-licensed material [2]. - If the TBB is added to the app store by Tor, it requires review of and agreement to Apple's terms and also agreeing not to reveal DRM sekrits [4]. - It requires time and energy to keep the app store listing maintained. Here are some possible solutions: - Submit Apple agreements to Wendy for review and rejection/acceptance. The last mention of this was a year ago on #6540. Status? - A volunteer who doesn't work for Tor maintaining the app store version of TBB. This would also free Tor as an organization from having to sign agreements. (Though this may contravene Apple's terms). - Actively decide to continue without being blessed by Apple, but focusing instead on educating Mac users about their application security options. Thoughts? ~Griffin [1] https://trac.torproject.org/projects/tor/ticket/6540 [2] https://www.opensource.apple.com/license/gpl-with-exception/ [3] http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/ [4] https://www.eff.org/deeplinks/2012/05/apples-crystal-prison-and-future-open… -- Be kind, for everyone you meet is fighting a hard battle. PGP: 0xD9D4CADEE3B67E7AB2C05717E331FD29AE792C97 OTR: saint(a)jabber.ccc.de

12 16

Damian's Status Report - November 2013
by Damian Johnson 09 Dec '13

09 Dec '13

Hi all. Work and life is conspiring to keep me busier than usual. What time was left this November mostly went toward non-development activities. I miss coding... ====================================================================== Tor Ecosystem Presentation ====================================================================== On 11/18 I gave a presentation at Seattle's TA3M overviewing projects in the Tor ecosystem, with an eye toward getting more developers involved... Presentation: https://archive.org/download/t3am-seattle-nov2013/damian_johnson.mp4 Slides: https://www.atagar.com/transfer/tor_ecosystem/ Preparing for this gobbled up a surprising amount of time (I don't do much public speaking), but I'm really happy with how it turned out. I'll likely give this presentation again at other local venues, such as LinuxFest Northwest in the spring. ====================================================================== Email List Management ====================================================================== Much of this last month went toward managing our lists and leading a discussion about what we'd like to do with our non-public lists. Work on this is ongoing, but at the very least we'll finally get a public, documented process for adding folks... https://trac.torproject.org/projects/tor/wiki/doc/internalLists I also sunk several hours into a frustrating GMail issue where it bounces Mailman's moderator queue as spam... https://productforums.google.com/forum/#!category-topic/gmail/ask-a-how-to-… At one point this seems to have been responsible for unsubscribing everyone using GMail from tor-assistants@. I've changed Mailman's configuration so this hopefully won't happen again, but I'm out of ideas for the GMail bounces. ====================================================================== Other news this month includes... * Fixed an important Stem ImportError under Windows. This resulted in a hotfix release of Stem (version 1.1.1). [1] * Added Stem support for the new event types from proposal 218. [2] * Code reviewed Philipp's ExitMap project. [3] * Read over tbbscraper and added to Stem's examples page. [4] * Helped provide stats for the impact of changing tor's default exit policy. [5] Cheers! -Damian [1] https://trac.torproject.org/10072 [2] https://gitweb.torproject.org/stem.git/commitdiff/e8c916b?hp=ae6d978 [3] https://lists.torproject.org/pipermail/tor-dev/2013-December/005889.html [4] https://github.com/zackw/tbbscraper/blob/master/controller/controller.py [5] https://trac.torproject.org/10067#comment:6

2 4

Statistics on fraction of connections used uni-/bidirectionally
by Karsten Loesing 09 Dec '13

09 Dec '13

Björn, Florian, a few years back (in 2010, to be precise) we added statistics to little-t-tor reporting what fraction of connections is used uni-/bidirectionally. Quoting dir-spec.txt: "conn-bi-direct" YYYY-MM-DD HH:MM:SS (NSEC s) BELOW,READ,WRITE,BOTH NL [At most once] Number of connections, split into 10-second intervals, that are used uni-directionally or bi-directionally as observed in the NSEC seconds (usually 86400 seconds) before YYYY-MM-DD HH:MM:SS. Every 10 seconds, we determine for every connection whether we read and wrote less than a threshold of 20 KiB (BELOW), read at least 10 times more than we wrote (READ), wrote at least 10 times more than we read (WRITE), or read and wrote more than the threshold, but not 10 times more in either direction (BOTH). After classifying a connection, read and write counters are reset for the next 10-second interval. These statistics are disabled by default, but when they are enabled, relays publish them in their extra-info descriptors. And quite a few relays do that. Here's a (bad) visualization (that used to be slightly less bad when fewer relays published these statistics): https://metrics.torproject.org/performance.html#connbidirect Here's the question: Is there still value in having these statistics? I recall that they were useful in 2010, but will that still be the case in 2013? If the answer is "yes", never mind. If the answer is "no", I'd create a ticket and submit a patch to remove code parts from little-t-tor, and I'd remove the not-really-useful graph from the metrics website. Cc'ing Rob, Aaron, and Roger as the people who typically have an interest in these kinds of statistics. If other tor-dev@ people have an opinion on this, please raise your voice! All the best, Karsten

1 0

Merge of Gitian PT build with 3.0-rc-1; next steps
by David Fifield 08 Dec '13

08 Dec '13

I recently merged the Gitian-based pluggable transports bundle build with tag tbb-3.0rc1-build1, with suprisingly little difficulty. I'd like you to take a look at what the pt branch is doing and help me decide what to do next. Some background: The ticket for building the PT bundles is https://trac.torproject.org/projects/tor/ticket/9444 The pt branch is at https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/shortlog/refs… To see what's different in the pt branch with respect to master, in an existing tor-browser-bundle.git checkout, do this: git remote add dcf https://git.torproject.org/user/dcf/tor-browser-bundle.git git fetch dcf Then, for example, git diff master...dcf/pt --stat git diff master...dcf/pt gitk master dcf/pt A recent build of 00789049873753d931fec3803c9ccae75a5c5267 is here, also containing the full complement of usual build outputs. https://people.torproject.org/~dcf/pt-bundle/3.0-rc-1-pt20131207-1/ These bundles are up to date and seem to be working well. I would be comfortable shipping them to users. I'd like your advice on how to make the pluggable transports browser part of the usual build. The diff between descriptors gitian-bundle.yml and gitian-ptbundle.yml is small; in fact I can paste it here: --- descriptors/linux/gitian-bundle.yml 2013-12-06 19:38:40.000000000 -0800 +++ descriptors/linux/gitian-ptbundle.yml 2013-12-06 19:38:40.000000000 -0800 @@ -1,3 +1,3 @@ --- -name: "bundle-linux" +name: "ptbundle-linux" suites: @@ -29,2 +29,4 @@ - "tor-linux64-gbuilt.zip" +- "pluggable-transports-linux32-gbuilt.zip" +- "pluggable-transports-linux64-gbuilt.zip" - "relativelink-src.zip" @@ -39,2 +41,4 @@ - "tbb-docs.zip" +- "pttbb-docs.zip" +- "linux-pt-torrc" script: | @@ -98,4 +102,8 @@ unzip ~/build/tor-linux$GBUILD_BITS-gbuilt.zip + unzip ~/build/pluggable-transports-linux$GBUILD_BITS-gbuilt.zip unzip ~/build/linux-skeleton.zip unzip ~/build/tbb-docs.zip + mkdir -p Docs/PluggableTransports + unzip -d Docs/PluggableTransports ~/build/pttbb-docs.zip + cat ~/build/linux-pt-torrc >> Data/Tor/torrc-defaults chmod 700 Data/Browser @@ -122,3 +130,3 @@ #mv tor-browser.exe $OUTDIR/tor-browser-linux${GBUILD_BITS}_en-US.7z-selfextract - ~/build/dtar.sh $OUTDIR/tor-browser-linux${GBUILD_BITS}-${TORBROWSER_VERSION}_en-US.tar.xz tor-browser_en-US + ~/build/dtar.sh $OUTDIR/tor-pluggable-transports-browser-linux${GBUILD_BITS}-${TORBROWSER_VERSION}_en-US.tar.xz tor-browser_en-US rm -rf tor-browser_en-US @@ -149,3 +157,3 @@ #mv tor-browser.exe $OUTDIR/tor-browser-linux${GBUILD_BITS}_$LANG.7z-selfextract - ~/build/dtar.sh $OUTDIR/tor-browser-linux${GBUILD_BITS}-${TORBROWSER_VERSION}_$LANG.tar.xz tor-browser_$LANG + ~/build/dtar.sh $OUTDIR/tor-pluggable-transports-browser-linux${GBUILD_BITS}-${TORBROWSER_VERSION}_$LANG.tar.xz tor-browser_$LANG I see a couple of options for getting rid of gitian-ptbundle.yml: 1. Add a conditional variable, something like the '[ ${TORBROWSER_VERSION::3} != "3.0" ]' in linux/gitian-firefox.yml, that controls whether a vanilla or a PT build is underway. When the variable is set, it would just do the few small changes in the diff above. 2. Build the pluggable transports bundles unconditionally, and just do all the dtars in gitian-bundle.yml twice: once for tor-browser and once for tor-pluggable-transports-browser. Either option, I think, puts us in a good place to step to a unified bundle in the future. What do you think? David Fifield

1 0

Torbirdy - IMAP issue
by arkmd 07 Dec '13

07 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Accessing an email server via IMAP may leak data by saving a draft on the remote server. Using Thunderbird+Enigmail+Torbirdy. While writing a message on Thunderbird, it is automatically saved as a draft, which by default is sent to the IMAP server. So the server will be able to read that message. That's a big problem when the message should be encrypted before sent. So the email provider will be able to read sensitive data on those drafts in cleartext and the user probably won't notice. To solve this the user need to manually set the account drafts settings (in Copies & Folders) to keep drafts on Local Folders. I think Torbirdy should do it by default. This info should be added to known issues on Torbirdy wiki. I know Torbirdy developers recommend POP over IMAP, but as a mailtor.net user I don't have any other option. - -- arkmd DeepBlog | A verdade nua crua e distorcida http://xzzpowtjlobho6kd.onion/ OpenPGP Public Key: http://xzzpowtjlobho6kd.onion/arkmd.asc 4096R: 0461 DF2C B6B7 6059 7529 77E0 04CD FE83 766B 8DA6 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJSoUwEAAoJEATN/oN2a42mW/AQAI7IITFPTZEe4X2UBNS3kovK UHJIe9j/K9FA63ubGxu8TotdkIK5TvnkPP/DGDg6NrnILIx/KeK6XAWTDhv6vfgY hIBA+v+9mjAW64fQ31tTSXEVKUofKUyazN984QnVcb/Qyj297GujgrI0vdDFU0c9 KIS7z15Lk3QRx+Qtb+VboXH3ES59oRPuutTSQ+z0RyLToMmFs41BDei01WtLfy/i aLcIYTWUZb+yVmspkOuOKAe9enlGNTXeFGaR6uspA8ImedsCUYq5iySBhm5CVs0B 0sF6Mq18rXTVDF4jwoNLYqkgyANSI9IzgDbxlzgBaJwJjnN9OAeF8vJI+qkZUElS 56pVIzayyEMJXhvsqotuBYH+X+aRt2+Hw2prIxuUcRDFP3iOrupElARpqvDqYa4U IrQ/8lUl5jEnPNNJFklBwTjzHOVtxmCymEDh+zSXlIzL4WQJwYPDj1+uqwOenwO4 FCy1ADFXyMDQso3bXwPqD3VSGdYGqmMc+34vIVA28vTSFYyxiBwjHZLF16Us+uD/ sMbMGEOg+za8MSrgLVwcBAkbRG14fE50litW+bnSWl3QltGOt0rV9INKLKSGvEy4 DMCL2mc9aU9Rago1j/FJlXAOCctuFlTOS9MkCzF+iSJIoa3IxwUmnrvWwOuEuFxa zrSdjkyzMJKgnd+b+Vm4 =oF2B -----END PGP SIGNATURE-----

5 6

InjectSOCKS
by tor＠herr-der-mails.de 06 Dec '13

06 Dec '13

1 0

Pluggable transports meeting tomorrow (Friday 6th of December 2013)
by George Kadianakis 05 Dec '13

05 Dec '13

Greetings humans, this is an email to remind you that the regular biweekly pluggable transports meeting is going to happen tomorrow. Place is the #tor-dev IRC channel in OFTC. Time is 17:00 UTC. Cheers!

1 0

Re: [tor-dev] (Draft) Proposal 224: Next-Generation Hidden Services in Tor
by Kang 05 Dec '13

05 Dec '13

Hello. I gave it a quick once over and these are my thoughts. I very much appreciate the ``Participants'' and ``In more detail: A menagerie of keys'' sections. I've had trouble in the past where I've been reading Tor specs and a new (or inconsistently named) key or actor is mentioned in passing. Likewise I appreciate that | was explicitly defined as concatenation, since in the current rend-spec it's left ambiguous. A few times you mention ``consensus parameters''. I assume these are values that go in the params field of the consensus, although it wasn't particularly clear (for me) until I looked it up in dir-spec. I like the ``Offline operation'' idea; that would certainly be more secure than distributing the same private key to several servers. In the hsdir_index(node) formula what exactly is ``node_identity_digest''?

2 1