> On 5 Apr 2016, at 13:49, Xiaofan Li wrote:
>
> Another concern is the assumption on TOR_SOCKET_T in the Tor codebase. In
> particular, there are many call sites of fcntl, getsockname, setsockopt etc
> made directly on this object, assuming that it is a UNIX socket. For
> compatibility, afte
Tim:
Thank you for the detailed email. I've also included tor-dev on CC. Anyone
is welcome to comment.
To reply to your concerns:
1. All the documentation we have is basically in email correspondences
as well as in the generic simple-quic codebase here:
https://github.com/kku1993/simple-
> On 5 Apr 2016, at 02:54, David Goulet wrote:
> So, this basically gives a space of 12 hours between the SRV generation and
> the start of the next time period. We can then easily fit an overlap period
> of 6 hours before the next time periods starts.
You've implicitly adjusted hsdir-overlap-
On 04 Apr (19:13:39), George Kadianakis wrote:
> Hello,
>
> during March we discussed the cell formats of prop224:
> https://lists.torproject.org/pipermail/tor-dev/2016-March/010534.html
>
> The prop224 topic for this month has to do with the way descriptors get
> uploaded and downloaded, how t
Hello,
during March we discussed the cell formats of prop224:
https://lists.torproject.org/pipermail/tor-dev/2016-March/010534.html
The prop224 topic for this month has to do with the way descriptors get
uploaded and downloaded, how this is scheduled using time periods and how the
shared random
Check out CENO. Right now it runs Freenet as a back-end for distributed
caching but it can gain Tahoe-LAFS support.
https://censorship.no/
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-de
Hi,
Funny, this is exactly the direction my thinking has been going. There
are too many different variations on restrictions - it might make
sense to just have a large enough sampled set, and then filter it with
the further restrictions. If nothing is found, we can fail closed at least.
Cheers
--
On 04/04/16 11:47, George Kadianakis wrote:
> I wonder what would happen there if FascistFirewall gets toggled on and off.
>
> If our guardlist was sampled when FascistFirewall was on, shouldn't we sample
> from the beginning if FascistFirewall goes off? That's terrible though since
> we
> lose a
On 04/03/2016 08:48 PM, Ivan Markin wrote:
> Recently someone leaked enormous amount of docs (2.6 TiB) to the
> journalists [1]. It's still hard to do such thing even over plain old
> Internet. Highly possible that these docs were transfered on a physical
> hard drive despite doing so is really *ri
Tim Wilson-Brown - teor writes:
> [ text/plain ]
>
>> On 27 Mar 2016, at 05:42, s7r wrote:
>>
>> Hello,
>>
>> teor, asn, see comments inline.
>>
>> On 3/24/2016 5:00 PM, Tim Wilson-Brown - teor wrote:
>> [snip]
>> The proposal ignores client bootstrap.
>>
>> There are a limited number of har
John Brooks writes:
> [ text/plain ]
> (Thread forked from [tor-dev] Notes from the prop224 proposal reading group)
>
>> On Mar 17, 2016, at 7:29 PM, George Kadianakis wrote:
>>
>> Also, please see my torspec branch `prop224-fixes` for some torspec changes
>> on prop224.
>> My branch is sittin
11 matches
Mail list logo
