- tor-dev - lists.torproject.org

REMINDER: 1 hour until Cute Otter hidden services & publishing
by Tom Lowenthal 16 Oct '13

16 Oct '13

Just under an hour until 1130 Pacific on Wednesday 2013-10-16. We'll be in #tor-dev, talking hidden services and publishing. -Tom On 15 October 2013 21:40, Tom Lowenthal <me(a)tomlowenthal.com> wrote: > Sorry about the late notice, folks. I thought I'd sent these times out > already, but apparently I was rather mistaken. > > We'll be in #tor-dev tomorrow Wednesday 2013-10-16 at 1130 Pacific to > talk about hidden services, scaling thereof, and safe publishing > therewith. We may take up to 90 minutes, and plan to meet again next > week, probably at the same time unless there are conflicts. > > It'd be super neat if you could familiarize yourself with [Sina's > proposal][1] before the meeting. Come with constructive comments and > suggestions. > > See y'all tomorrow. > -Tom > > > [1]: https://lists.torproject.org/pipermail/tor-dev/2013-October/005558.html

1 0

Attentive Otter IM: tomorrow Wednesday 2013-10-16 at 1400h Pacific
by Tom Lowenthal 16 Oct '13

16 Oct '13

Sorry about this late notice too. I thought I'd sent these times out already, but apparently I was rather mistaken. We'll be in #tor-dev tomorrow Wednesday 2013-10-16 at 1430 Pacific to talk about the Tor IM project. We may take up to 90 minutes, and plan to meet again next week, probably at the same time unless there are conflicts. Arlo came up with [a cunning plan][1] m'lord. You should totes read it and come tomorrow with questions and suggestions about how best to implement Instantbird as the Tor IM app. See y'all tomorrow. Play nice, now. -Tom [1]: https://gist.github.com/arlolra/6969273

1 0

Cute Otter hidden services & publishing: tomorrow Wednesday 2013-10-16 at 1130 Pacific
by Tom Lowenthal 16 Oct '13

16 Oct '13

Sorry about the late notice, folks. I thought I'd sent these times out already, but apparently I was rather mistaken. We'll be in #tor-dev tomorrow Wednesday 2013-10-16 at 1130 Pacific to talk about hidden services, scaling thereof, and safe publishing therewith. We may take up to 90 minutes, and plan to meet again next week, probably at the same time unless there are conflicts. It'd be super neat if you could familiarize yourself with [Sina's proposal][1] before the meeting. Come with constructive comments and suggestions. See y'all tomorrow. -Tom [1]: https://lists.torproject.org/pipermail/tor-dev/2013-October/005558.html

1 0

Comments Requested: General anonymity with Tor video
by Sherief Alaa 15 Oct '13

15 Oct '13

Hello Everyone, I am working on a general anonymity with Tor video [0] and a script [1] for it. This video will be translated to all of the help desk languages. Basically, the video will some slides playing while I talk/explain them, both the video script and the slides can be found on trac [0][1] I would appreciate your comments/suggestions before I start recording the video. (Deadline 18-Oct-2013.) If you find any mistakes, please let me know here or on trac [0][1] Thanks! [0] https://trac.torproject.org/projects/tor/ticket/5991 [1] https://trac.torproject.org/projects/tor/ticket/6922 -- Sherief Alaa pgp 0x8623B882

2 1

REMINDER: Boisterous Otters helpdesk meeting in 1h
by Tom Lowenthal 15 Oct '13

15 Oct '13

Today at 1100h Pacific (an hour from now), we'll be in #tor-dev to discuss how we're going to start offering webchat support, in line with the [draft][1] produced by Colin (Phoul), with help from Lunar and Erinn (Helix). See y'all soon! -Tom [1]: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Boisterous…

1 0

OnionMail 0.1.1 Beta is Out
by Liste 15 Oct '13

15 Oct '13

Next week we will translate the web site. http://onionmail.info/

1 0

ACTION REQUESTED: Help me plan deliverables for Sponsor F, Year 4 [due Friday, discussion Monday]
by Tom Lowenthal 14 Oct '13

14 Oct '13

<https://pad.riseup.net/p/Vt0TDXcdH0PB_Tor-Sponsor-F_Year-4> Sponsor F year 3 ends at the end of this month. Fear not though, for year 4 starts right after that! We need to get to work planing the things that we'll do during year 4, so that we can tell Sponsor F what they are and all that good stuff. For your convenience, I have prepared a [RiseUp pad][1] where we can put all our ideas (no I don't have an [AllOurIdeas][2] instance). For convenience and expediency, I would very much like it if you could get your ideas into this pad before **Friday 2013-10-18**. Then folks can look at them over the weekend, and we can talk about it next **Monday 2013-10-21, from 1100-1230h Pacific**. If you are in the `to` field, that's because I have some particular reason to believe that you are likely to be involved in year 4 (probably because you were in year 3). You should totes make sure you get your plan into the pad. To get started, you should head over to the [pad][1] and add your thoughts. Any questions? -Tom [1]: https://pad.riseup.net/p/Vt0TDXcdH0PB_Tor-Sponsor-F_Year-4 [2]: http://www.allourideas.org/

1 0

Stem Release 1.1
by Damian Johnson 14 Oct '13

14 Oct '13

Hi all. After seven months of work I'm pleased to announce Stem's 1.1.0 release! For those who aren't familiar with it, Stem is a Python library for interacting with Tor. With it you can script against your relay, descriptor data, or even write applications similar to arm and Vidalia. https://stem.torproject.org/ So what's new in this release? ============================================================ * Remote Descriptor Fetching The stem.descriptor.remote module allows you download current Tor descriptor data from directory authorities and mirrors, much like Tor itself does. With this you can easily check the status of the network without piggybacking on a local instance of Tor (or even having it installed). https://stem.torproject.org/api/descriptor/remote.html For example... from stem.descriptor.remote import DescriptorDownloader downloader = DescriptorDownloader() try: for desc in downloader.get_consensus().run(): print "found relay %s (%s)" % (desc.nickname, desc.fingerprint) except Exception as exc: print "Unable to retrieve the consensus: %s" % exc ============================================================ * Connection Resolution One of arm's most popular features has been its ability to monitor Tor's connections, and stem can now do the same! Lookups are performed via seven *nix and FreeBSD resolvers, for more information and an example see... https://stem.torproject.org/tutorials/east_of_the_sun.html#connection-resol… ============================================================ * Numerous Features and Fixes For a rundown of other changes see... https://stem.torproject.org/change_log.html#version-1-1 Cheers! -Damian

1 0

Checking Tonga's consensus (was: Consensus issues)
by Karsten Loesing 14 Oct '13

14 Oct '13

On 10/14/13 6:45 AM, metrics wrote: > WARNING: The consensuses published by the following directory authorities are more than one hour old and therefore not fresh anymore: Tonga Hi Damian, why do you check Tonga's consensus? Tonga is not a v3 directory authority but just a directory mirror. All the best, Karsten

2 1

More Hidden Services help needed: Guard enumeration
by George Kadianakis 14 Oct '13

14 Oct '13

Greetings, another important Hidden Service issue, is the guard enumeration attack that was described by the "Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization" paper (in section VII) [0]. A trac ticket was created to fix this issue (#9001 [1]). The most popular solution so far seems to be the 'Virtual Circuit' concept. The idea here is that if you have already created a circuit to a Rendezvous Point, and then that circuit fails and you need to connect to a different RP, then maybe you could reuse the previous hops of the circuit and only change the last hop to the new RP. This is an interesting concept and useful in other occasions too. For example, if the network is flooded with CREATE cells (like during the recent botnet invasion) and relays reject them because of increased workload, then maybe clients shouldn't build entirely new circuits to send CREATE cells to different relays (because building new circuits increases the total load of the network even more). However, this concept must be designed carefully and in a security-conscious way. Reusing parts of old circuits to connect to new nodes might result in unexpected attacks. More solutions have been proposed in #9001, like "guard node layers", which need further investigations. If you think you can contribute to this topic, please write your ideas in this mailing list or in ticket #9001. Enjoy. [0]: www.ieee-security.org/TC/SP2013/papers/4977a080.pdf‎ [1]: https://trac.torproject.org/projects/tor/ticket/9001

1 0