[tor-dev] Update on Roadmaps for Core Tor, Hidden Services and Tor Obfuscation
Hello everyone. In Valencia dev meeting we did an exercise to help create a roadmap (1yr) for the different Tor projects and organizational work. I've collected those roadmaps and published them here: https://trac.torproject.org/projects/tor/wiki/org/roadmaps (I will be sending a similar email to the other dev and org teams as well. ) What I would like to ask from the folks in this list, and who collaborate with*Core Tor, Hidden Services and Tor Obfuscation (PT, BridgeDB etc), *is to look at the tables for March and April and fill up the empty cells for: * sponsor - is the task related to a sponsor? (or could be) * who - person(s) who the task should be assigned to * tickets - ticket(s) related to the task (please create them if appropriate) * date - estimation dates are always good :) nickm has already created tickets for Core Tor tasks (Thanks Nick!) Let me know if you have questions. Here are the tables I am talking about: * March and April for Core Tor: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor * March and April for Hidden Services: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/HS * March and April for Tor Obfuscation: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/TorObfuscation thanks everyone, Isabela signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Preliminary Debian packages for meek
On Thu, Mar 05, 2015 at 12:53:52AM +0100, Ximin Luo wrote: Source package: https://mentors.debian.net/package/meek Binary packages: https://people.torproject.org/~infinity0/bin/ From the binaries, one should install both meek-client and xul-ext-meek-http-helper; the latter depends on xfvb and xauth. meek-client has been modified slightly to run meek-http-helper in a headless firefox using Xfvb(1), so that it works even when run as a system service. Example torrc: UseBridges 1 Bridge meek 0.0.2.0:1 url=https://meek-reflect.appspot.com/ front=www.google.com ClientTransportPlugin meek exec /usr/bin/meek-client-wrapper --log /var/log/tor/meek-client-wrapper.log --helper /usr/bin/meek-browser-helper -- /usr/bin/meek-client --log /var/log/tor/meek-client.log This is great. Thanks a log. The xfvb idea is really clever. Someone asked this question on Tor Stack Exchange: https://tor.stackexchange.com/questions/3620/how-to-install-tor-with-meek-support-on-ubuntu-debian Seems like this package will soon be the answer? I'll suggest the meek-client-wrapper program from #12716 to the maintainer of the FreeBSD port. David Fifield ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Suggestions for Hidden Services Statistics Project
Gautham Nekkanti gauthamn...@gmail.com writes: Hi, I have already shared my project idea on a Simple analytics tool for Hidden service providers. I am looking for suggestions and input from users who have had experience in hosting hidden services. Obviously, there would all useful traffic related statistics. I'm looking for suggestions on what tor-specific statistics do you think would be helpful? As meejah suggested, we are thinking on including a few tor-specific statistics like 'How many times their onion descriptor was requested', 'No of bytes transferred through circuits', e.t.c. Thanks I think a panel for hidden service operators would be very useful. Some ideas on information that could be displayed: - User Analytics: -- How many clients have appeared during last hour/day/month (including a graph that shows visits at different times of day). -- How much traffic was received and pushed. - Security panel: -- How many guards have been used over the past day/week/month. -- Graph with the number of rendezvous point establishments that have been performed (to detect sloppy guard discovery attacks). This might be the same as the client graph. - Other information: -- How long till introduction points expire. How long till guard expires. -- How many of your responsible HSDirs are still up. - Other features: -- Red button to auto-publish yourself to ahmia (per #15008) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
On Wed, 11 Mar 2015 02:35:10 + Yawning Angel yawn...@schwanenlied.me wrote: The code: https://github.com/Yawning/tor/compare/feature6411 The spec: https://github.com/Yawning/torspec/compare/feature6411 Minor updates to both over the course of yesterday, thanks to all that gave useful feedback and corrections. The notable changes are: * DiscardPK is now Flags=DiscardPK, to allow for. [0]: Onions added this way will remain tied to the control port connection that created them for now. That particular dead pony has been loaded onto the cart and shipped off to the glue factory, and is no longer available for beatings. * I lied. People that want to shoot themselves in the foot can now specify the Detach flag which explicitly unlinks the newly created HS from any control port instance. Detached Onion Services will persist till tor termination, or explicitly removed by DEL_ONION. * DEL_ONION now will allow the removal of Onion Services belonging to the current connection in addition to any Onion Service created with the Detach flag. * Added GET_ONIONS that returns a list of Onion Services belonging to the current connection in addition to all Onion Services created with the Detach flag. I strongly recommend ignoring the fact that the Detach flag and GET_ONIONS command exists, beyond reviewing my code and making sure they're implemented correctly. That said, I know multiple developers will probably write applications that implements cleanup as DEL_ONION ALL THE THINGS, stomping over unrelated Detach-ed services[0]. Unless something comes up, I plan to rebase/squash my feature branch for review sometime by early next week, so if people have strong opinions on this feature, they should speak up now. Regards, -- Yawning Angel [0]: I have my not a bug/wontfix ready for such situations. pgpZA9563xnv3.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
