[tor-dev] little-t tor "projects" in need of another keyboard

2014-07-14 Thread tibicen
Hi everyone, Is there any project in little-t tor that needs another hacker? I have (under another name) been writing tor unit tests, which I've "finished". What should I work on next? Happy to work on either new code or more unit tests. I'm also reasonably skilled with python, if any pythonic pr

Re: [tor-dev] Revised Relay Descriptor Fields proposal

2014-07-14 Thread isis
Damian Johnson transcribed 1.1K bytes: > This is for extrainfo descriptors, not server descriptors. Do bridges > publish extrainfo descriptors? Oh. That wasn't clear to me from the proposal, but I must have simply missed it. Yes, bridges do publish extrainfo descriptors. BridgeDB parses those as

Re: [tor-dev] What little-t-tor bridge features/issues we should address?

2014-07-14 Thread David Fifield
On Fri, Jul 11, 2014 at 07:51:49PM +0300, George Kadianakis wrote: > Hello Roger and Nick, > > as far as I know, bridge support was hastily implemented in > little-t-tor, and it does not support all the features we would like > it to support. > > During the dev meeting roadmapping, we added a tas

Re: [tor-dev] :(

2014-07-14 Thread vmon
Interesting! It is not a fundamental error per say, if you are a server you can't handle more than some number of connections anyway (you can increase that if you are root), so the client need to wait. You need a ddos defence mechanism against that (e.g. iptables) independent of what kind of server

Re: [tor-dev] :(

2014-07-14 Thread Noah Rahman
Maybe having 12 tabs open while downloading TBB did it? On Jul 14, 2014 4:46 PM, wrote: > Interesting! It is not a fundamental error per say, if you are a server > you can't handle more than some number of connections anyway (you can > increase that if you are root), so the client need to wait. Y

Re: [tor-dev] Revised Relay Descriptor Fields proposal

2014-07-14 Thread Damian Johnson
> 0. Does this proposal include adding these additional `X-*` fields to > the `@type bridge-server-descriptor`s as well? Or only to the > non-bridge server-descriptors? This is for extrainfo descriptors, not server descriptors. Do bridges publish extrainfo descriptors? > 1. Why 5KB? > >

Re: [tor-dev] What little-t-tor bridge features/issues we should address?

2014-07-14 Thread Yawning Angel
On Mon, 14 Jul 2014 12:30:06 -0700 Kevin P Dyer wrote: (This is orthogonal to the bridge code, but since you asked...) > I would like to be able to bind to privileged ports when running a > PT-enabled bridge in managed mode --- will any changes to > little-t-tor be required for this feature? (A

Re: [tor-dev] Revised Relay Descriptor Fields proposal

2014-07-14 Thread isis
Ian Goldberg transcribed 1.2K bytes: > > There may need to be a maximum sum length of the X- entries. This is > > left to the developers. I propose a maximum sum length of 5 kilobytes. A couple questions: 0. Does this proposal include adding these additional `X-*` fields to the `@type bri

Re: [tor-dev] What little-t-tor bridge features/issues we should address?

2014-07-14 Thread Kevin P Dyer
I would like to be able to bind to privileged ports when running a PT-enabled bridge in managed mode --- will any changes to little-t-tor be required for this feature? -Kevin On Fri, Jul 11, 2014 at 9:51 AM, George Kadianakis wrote: > Hello Roger and Nick, > > as far as I know, bridge support

[tor-dev] Syboa: gui desktop tor monitor

2014-07-14 Thread Sean Robinson
This email is to announce the first public release of Syboa[1], a tor controller for monitoring a local daemon instance. My primary motivation for Syboa was to replace TorK, so it looks[2] more like TorK than Vidalia. Syboa is not ready for non-developer users[3]. But after seeing the "UX Idea - A

Re: [tor-dev] [patch] properly test for OPENSSL_NO_COMP

2014-07-14 Thread Ian Goldberg
On Sun, Jul 13, 2014 at 11:01:23PM -0400, grarpamp wrote: > On Sun, Jul 13, 2014 at 7:23 PM, Ian Goldberg wrote: > > On Sun, Jul 13, 2014 at 07:20:29PM -0400, grarpamp wrote: > >> >/* Don't actually allow compression; it uses ram and time, but the > >> > data > >> > * we transmit is all e