Re: [tor-dev] How to introduce new RELAY_COMMAND_* types and new cell fields?

Op 10/09/15 om 04:10 schreef Mike Perry: I'm writing a handful of proposals that need to introduce either new cell sub-payloads or new command types. Specifically, I want to add: 1. Sub-fields to CELL_PADDING to allow clients to tell relays about the amount of link padding they want for

Re: [tor-dev] How to introduce new RELAY_COMMAND_* types and newcell fields?

>> 3. Additional RELAY_COMMAND_* types for clients to request out-of-band >> HMAC request cells for Proposal 253. Do you need to request that data? How about always sending it from middle nodes? (Less leakage about the client.) >> 4. Additional RELAY_COMMAND_* opcodes for clients to request

Re: [tor-dev] Bridge Guards (prop#188) & Bridge ORPort Reachability Tests

On Thu, 10 Sep 2015 07:01:58 + isis wrote: > 3. Should we change how the BridgeAuthority tests Bridge ORPort > reachability? If so, how? > > 4. If I'm going to refactor all of this, are there other (future) > things I should take into account? > > For example, if

Re: [tor-dev] Partitioning Attacks on Prop250 (Re: Draft Proposal: Random Number Generation During Tor Voting)

On 09 Sep (23:21:03), George Kadianakis wrote: > Nick Mathewson writes: > > > On Tue, Sep 8, 2015 at 7:10 AM, David Goulet wrote: > >> On 08 Sep (01:04:36), Tim Wilson-Brown - teor wrote: > >>> > >>> > On 7 Sep 2015, at 23:36, David Goulet

[tor-dev] CollecTor data of the current month older than 72 hours

Hi, data in the /recent folder goes back 72 hours, /archive is updated "every few days" [1]. The latest file in the archive folder [2] is currently from 2015-09-07: votes-2015-08.tar.xz07-Sep-2015 04:11 159M but does not contain any data from September 2015. is there currently

[tor-dev] Bridge Guards (prop#188) & Bridge ORPort Reachability Tests

Hey all, I have a working implementation of proposal #188, [0] which specifies a mechanism by which tor's (rather accidental) loose-source routing feature is utilised by Bridges in order to transparently inject a Bridge Guard into all client circuits. (See #7144. [1]) Currently, I am updating

Re: [tor-dev] How to introduce new RELAY_COMMAND_* types and newcell fields?

On 10 Sep 2015, at 12:37, tordev...@safe-mail.net wrote: >>> 3. Additional RELAY_COMMAND_* types for clients to request out-of-band >>> HMAC request cells for Proposal 253. > > Do you need to request that data? How about always sending it from middle > nodes? (Less leakage about the client.) >

Re: [tor-dev] Reproducibility of Pluggable Transports python.msi

On Thu, Sep 10, 2015 at 12:55 AM, Yawning Angel wrote: > > FWIW, I don't particularly think that there must be One True PT > language[0], I just recommend Go over the other alternatives due to it > being both memory safe and easy to build on mobile. If someone writes a >

Re: [tor-dev] Reproducibility of Pluggable Transports python.msi

On Thu, 10 Sep 2015 10:20:59 -0400 Brandon Wiley wrote: > I'm not advocating that the various PT implementations be abandoned, > just that we have a common implementation across products when > possible. If I recall correctly, there was a time when TBB, Tails, > and Orbot were

Re: [tor-dev] Partitioning Attacks on Prop250 (Re: Draft Proposal: Random Number Generation During Tor Voting)

On Wed, Sep 9, 2015 at 4:21 PM, George Kadianakis wrote: > Nick Mathewson writes: > >> On Tue, Sep 8, 2015 at 7:10 AM, David Goulet wrote: >>> On 08 Sep (01:04:36), Tim Wilson-Brown - teor wrote: > On 7 Sep 2015, at 23:36,

[tor-dev] [PATCH] Update prop#188 to match implementation from #7144.

* ADD a new section detailing loose-source routed circuits, including: - How the circuit should appear to the OP, the bridge, and the bridge guard, - How the hop(s) in the path is/are chosen, - How the first hop is handled and how circuit extension is handled, in a

Re: [tor-dev] Bridge Guards (prop#188) & Bridge ORPort Reachability Tests

On 10 September 2015 at 02:01, isis wrote: > 2.a. First, if there aren't any other reasons for self-testing: Is Bridge > reachability self-testing actually helpful to Bridge operators in > practice? Don't most Bridge operators just try to connect, as a

Re: [tor-dev] [tor-reports] Sebastian's August 2015

> On 11 Sep 2015, at 07:04, ilv wrote: >> Next up is more of the same, especially focusing on website tickets >> and preparing the community team's dev meeting contributions. > > Maybe we could have a session at the dev meeting to talk about the > website (content, structure,

Re: [tor-dev] [tor-reports] Sebastian's August 2015

On 06/09/15 13:01, Sebastian Hahn wrote: > Hi there, > Hi Sebastian, > Next up is more of the same, especially focusing on website tickets > and preparing the community team's dev meeting contributions. Maybe we could have a session at the dev meeting to talk about the website (content,

Re: [tor-dev] Bridge Guards (prop#188) & Bridge ORPort Reachability Tests

Yawning Angel transcribed 2.7K bytes: > On Thu, 10 Sep 2015 07:01:58 + > isis wrote: > > 3. Should we change how the BridgeAuthority tests Bridge ORPort > > reachability? If so, how? > > > > 4. If I'm going to refactor all of this, are there other (future) > > things I