On Mon, 7 Sep 2015 17:03:00 -0700
Kevin P Dyer wrote:
> Response inline.
>
> On Mon, Sep 7, 2015 at 3:29 PM, Yawning Angel
> wrote:
>
> > On Mon, 7 Sep 2015 14:37:07 -0700
> > Kevin P Dyer wrote:
> >
> > > ...and it shouldn't.
> > >
> > > Fortunately, the dependency is isolated to a single fi
The background: I've been trying to get the fteproxy package into debian.
In the code review process, the dependency on obfsproxy was flagged as a
not-so-great thing. I agree, and was hoping there's an easy solution...
-Kevin
On Mon, Sep 7, 2015 at 5:03 PM, Kevin P Dyer wrote:
> Response inline
Response inline.
On Mon, Sep 7, 2015 at 3:29 PM, Yawning Angel
wrote:
> On Mon, 7 Sep 2015 14:37:07 -0700
> Kevin P Dyer wrote:
>
> > ...and it shouldn't.
> >
> > Fortunately, the dependency is isolated to a single file. See [1].
> >
> > My understanding is that pyptlib [2] is no longer maintai
Yawning Angel writes:
> So, we currently have a Pluggable Transport (PT) spec, and it kind-of
> sort-of works (The documentation is a mess that I'm working on
> cleaning up, but it's an orthogonal issue for how well it works).
>
> There are a number of problems with the current PT spec that requi
So, we currently have a Pluggable Transport (PT) spec, and it kind-of
sort-of works (The documentation is a mess that I'm working on
cleaning up, but it's an orthogonal issue for how well it works).
There are a number of problems with the current PT spec that require
breaking backward compatibilit
Kevin P Dyer writes:
> ...and it shouldn't.
>
> Fortunately, the dependency is isolated to a single file. See [1].
>
> My understanding is that pyptlib [2] is no longer maintained.
>
> wiley/asn/etc. - What's the proper way to remove this dependency, but make
> it easy for fteproxy to be a PT?
>
On Mon, 7 Sep 2015 14:37:07 -0700
Kevin P Dyer wrote:
> ...and it shouldn't.
>
> Fortunately, the dependency is isolated to a single file. See [1].
>
> My understanding is that pyptlib [2] is no longer maintained.
It isn't? It hasn't gotten any updates because nothing broke and the pt
spec is
...and it shouldn't.
Fortunately, the dependency is isolated to a single file. See [1].
My understanding is that pyptlib [2] is no longer maintained.
wiley/asn/etc. - What's the proper way to remove this dependency, but make
it easy for fteproxy to be a PT?
-Kevin
[1] https://github.com/kpdyer
> 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 well as a new "conflict" line is added to the vote.
> …
> If an authority sees two distinct commitments from an other authority in
> the same period, th
Hello!
While working on the implementation of this proposal, we realized that
it was much more complicated to add a new consensus flavor than we
originally anticipated.
nickm then suggested to NOT use this new flavor (shared random document)
and instead change it to a persistent state on disk tha
I'm not a big fan of automated systems that ban authorities as it may get false
positives and it may be gamed and/or attacked.
An alternative solution is to make the voting a two-step system: first you
publish the sha256 hash of your vote, then a few minutes later you publish the
actual vote.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
Sending the comments from #tor-dev here as well.
This is related to the attack where exactly half of the directory
authorities commit to some values, and the last directory authority
can send different values to both camps, and have the ultimat
12 matches
Mail list logo
