On Wed, 9 Sep 2015 17:20:11 -0400
Brandon Wiley wrote:
> Thanks David, great info! Last time I checked, I think the C
> implementation was also still shipping with something, I think Orbot
> for Android. Perhaps this is also for either flash proxy or FTE
> support, since Python is not the best opt
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 Proposal 251. Mobile clients will
probably want les
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/09/2015 07:33 PM, Brandon Wiley wrote:
> I also don't know how well reproducible builds work with Go, so if
> someone knows that would be interesting information.
Take a look here:
https://gitweb.torproject.org/builders/tor-browser-bundle.gi
Yes and if we see more than 1 commitment value from the same authority
then it makes sense to revote with the remaining n-1 directory
authorities so that the attacker doesn't get a choice of the 9 vote
result versus the 8 vote result... but instead the attacker can chose
between the 9 vote result a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I think we can mitigate this by implementing a p2p-like distribution
system for the commitment values between the directory authorities.
When an authority sends to all other authorities its commitment /
reveal value, it also sends the commitment
Thanks David, great info! Last time I checked, I think the C implementation
was also still shipping with something, I think Orbot for Android. Perhaps
this is also for either flash proxy or FTE support, since Python is not the
best option on Android.
>From the graphs it looks like FTE is still in
On Wed, Sep 09, 2015 at 03:33:24PM -0400, Brandon Wiley wrote:
> I am in favor of standardizing on the Go codebase for pluggable transports
> that
> ship with Tor. This is something we talked about at the last developer
> meeting.
> The reason I favor this is not for reproducible build reasons, b
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 wrote:
>>> > ...
>>> > Please review it, mostly format of the state (before the SR document)
>>> > has changed. As
I am in favor of standardizing on the Go codebase for pluggable transports
that ship with Tor. This is something we talked about at the last developer
meeting. The reason I favor this is not for reproducible build reasons, but
because maintaining four implementations (C, Python, C++, and Go) is
con
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/09/2015 06:43 PM, Brandon Wiley wrote:
> Another option here, besides getting python to build in gitian is
> to phase out support for python-based pluggable transports. It's
> something to consider at least. Which transports are still only
> av
Another option here, besides getting python to build in gitian is to phase
out support for python-based pluggable transports. It's something to
consider at least. Which transports are still only available in python?
On Sun, Sep 6, 2015 at 7:26 PM, Jeremy Rand wrote:
> -BEGIN PGP SIGNED MESSA
I'm resending this, because tor-dev didn't accept my message
originally. Sorry David and Jeremy for the double message.
Hello David and Jeremy,
I am the "reproducible build specialist" that Jeremy was referring to,
though I don't know if I woul
I think we should (1) make pyptlib easier to use but (2) wait until the new
PT spec. is settled upon.
Let's pick this back up when the spec. is complete.
-Kevin
On Tue, Sep 8, 2015 at 5:56 PM, isis wrote:
> George Kadianakis transcribed 1.4K bytes:
> > Kevin P Dyer writes:
> >
> > > ...and it
Mike Perry writes:
> George Kadianakis:
>> Hello there,
>>
>> recently we've been busy specifying various important improvements to entry
>> guard security. For instance see proposals 250, 241 and ticket #16861.
>>
>> Unfortunately, the current guard codebase is dusty and full of problems (see
14 matches
Mail list logo
