On 20 Dec (17:44:31), George Kadianakis wrote:
> David Goulet writes:
>
> > On 06 Dec (10:09:57), teor wrote:
> >>
> >> > On 6 Dec. 2016, at 09:56, David Goulet wrote:
> >> >
> >> >
> >> >
> >>
> >> Here's a suggested strategy:
> >> * at load time, validate the HS options as if v2 is the def
David Goulet writes:
> On 06 Dec (10:09:57), teor wrote:
>>
>> > On 6 Dec. 2016, at 09:56, David Goulet wrote:
>> >
>> >
>> >
>>
>> Here's a suggested strategy:
>> * at load time, validate the HS options as if v2 is the default, and
>> validate them as if v3 is the default, and fail if eit
> On 6 Dec. 2016, at 10:32, David Goulet wrote:
>
> On 06 Dec (10:09:57), teor wrote:
>>
>>> ...
>
>>
>> Here's a suggested strategy:
>> * at load time, validate the HS options as if v2 is the default, and
>> validate them as if v3 is the default, and fail if either validation
>> fails.
>>
On 06 Dec (10:09:57), teor wrote:
>
> > On 6 Dec. 2016, at 09:56, David Goulet wrote:
> >
> > On 06 Dec (09:43:20), teor wrote:
> >>
> >>> On 6 Dec. 2016, at 08:02, David Goulet wrote:
> >>>
> >>> On 06 Dec (07:53:16), teor wrote:
>
> > On 6 Dec. 2016, at 07:42, David Goulet wrote:
> On 6 Dec. 2016, at 09:56, David Goulet wrote:
>
> On 06 Dec (09:43:20), teor wrote:
>>
>>> On 6 Dec. 2016, at 08:02, David Goulet wrote:
>>>
>>> On 06 Dec (07:53:16), teor wrote:
> On 6 Dec. 2016, at 07:42, David Goulet wrote:
>
> On 22 Nov (17:36:33), David Goulet wrote
On 06 Dec (09:43:20), teor wrote:
>
> > On 6 Dec. 2016, at 08:02, David Goulet wrote:
> >
> > On 06 Dec (07:53:16), teor wrote:
> >>
> >>> On 6 Dec. 2016, at 07:42, David Goulet wrote:
> >>>
> >>> On 22 Nov (17:36:33), David Goulet wrote:
> Hi everyone!
>
> We are soon at the
> On 6 Dec. 2016, at 08:02, David Goulet wrote:
>
> On 06 Dec (07:53:16), teor wrote:
>>
>>> On 6 Dec. 2016, at 07:42, David Goulet wrote:
>>>
>>> On 22 Nov (17:36:33), David Goulet wrote:
Hi everyone!
We are soon at the stage of implementing the service part of proposal 224
>
On 06 Dec (07:53:16), teor wrote:
>
> > On 6 Dec. 2016, at 07:42, David Goulet wrote:
> >
> > On 22 Nov (17:36:33), David Goulet wrote:
> >> Hi everyone!
> >>
> >> We are soon at the stage of implementing the service part of proposal 224
> >> (next gen. hidden service.). Parent ticket is #20657
> On 6 Dec. 2016, at 07:42, David Goulet wrote:
>
> On 22 Nov (17:36:33), David Goulet wrote:
>> Hi everyone!
>>
>> We are soon at the stage of implementing the service part of proposal 224
>> (next gen. hidden service.). Parent ticket is #20657 but I'll be discussing
>> here ticket #18054.
>>
On 22 Nov (17:36:33), David Goulet wrote:
> Hi everyone!
>
> We are soon at the stage of implementing the service part of proposal 224
> (next gen. hidden service.). Parent ticket is #20657 but I'll be discussing
> here ticket #18054.
>
> In a nutshell, we need to figure out the interface for the
> On 28 Nov. 2016, at 03:24, David Goulet wrote:
>
> On 27 Nov (00:44:39), Matthew Finkel wrote:
>> On Sat, Nov 26, 2016 at 09:25:44PM +1100, teor wrote:
>>>
On 26 Nov. 2016, at 02:25, David Goulet wrote:
>>
>> 2) It also means we create an option that will get deprecated o
On Sun, Nov 27, 2016 at 01:07:02PM -0500, chelsea komlo wrote:
> Hi,
>
> >> Yes, the onion-service-version and the version of the descriptor that tor
> >> publishes are now tightly coupled, comparing v2 and v3. However, this may
> >> not always be the case and, indeed, was not the case previously
On Sun, Nov 27, 2016 at 11:24:11AM -0500, David Goulet wrote:
> On 27 Nov (00:44:39), Matthew Finkel wrote:
> > On Sat, Nov 26, 2016 at 09:25:44PM +1100, teor wrote:
> > > > On 26 Nov. 2016, at 02:25, David Goulet wrote:
> > > >
> > > >>>
> > > >>> 2) It also means we create an option that will
Hi,
>> Yes, the onion-service-version and the version of the descriptor that tor
>> publishes are now tightly coupled, comparing v2 and v3. However, this may
>> not always be the case and, indeed, was not the case previously. I'm not
>> saying HiddenServiceVersion is not the correct torrc option,
On 27 Nov (00:44:39), Matthew Finkel wrote:
> On Sat, Nov 26, 2016 at 09:25:44PM +1100, teor wrote:
> >
> > > On 26 Nov. 2016, at 02:25, David Goulet wrote:
> > >
> > >>>
> > >>> 2) It also means we create an option that will get deprecated once v2 is
> > >>> phased out so we are adding a "tem
On Thu, Nov 24, 2016 at 08:14:55PM -0500, cko...@thoughtworks.com wrote:
> Hi,
>
> >
> > 2) It also means we create an option that will get deprecated once v2 is
> >phased out so we are adding a "temporary" option for users to "keep
> >creating v2 addresses" but then will be useless and we
On Sat, Nov 26, 2016 at 09:25:44PM +1100, teor wrote:
>
> > On 26 Nov. 2016, at 02:25, David Goulet wrote:
> >
> >>>
> >>> 2) It also means we create an option that will get deprecated once v2 is
> >>> phased out so we are adding a "temporary" option for users to "keep
> >>> creating v2 addre
> On 26 Nov. 2016, at 02:25, David Goulet wrote:
>
>>>
>>> 2) It also means we create an option that will get deprecated once v2 is
>>> phased out so we are adding a "temporary" option for users to "keep
>>> creating v2 addresses" but then will be useless and we'll deprecate and get
>>> a wh
Hi,
David Goulet wrote:
> On 24 Nov (11:13:06), teor wrote:
>>
>>> On 24 Nov. 2016, at 11:04, Yawning Angel wrote:
>>>
>>> On Thu, 24 Nov 2016 01:43:15 +0200
>>> s7r wrote:
I agree that this would be "the technical way" to do it, but real
world usability kind of prevents us to do it th
On 25 Nov (10:33:35), teor wrote:
>
> > On 25 Nov. 2016, at 03:40, David Goulet wrote:
> >
> > On 24 Nov (11:13:06), teor wrote:
> >>
> >>> On 24 Nov. 2016, at 11:04, Yawning Angel wrote:
> >>>
> >>> On Thu, 24 Nov 2016 01:43:15 +0200
> >>> s7r wrote:
> I agree that this would be "the t
Hi,
>
> 2) It also means we create an option that will get deprecated once v2 is
>phased out so we are adding a "temporary" option for users to "keep
>creating v2 addresses" but then will be useless and we'll deprecate and get
>a whole lot confusing if for instance v4 or v5 happens in
> On 25 Nov. 2016, at 03:40, David Goulet wrote:
>
> On 24 Nov (11:13:06), teor wrote:
>>
>>> On 24 Nov. 2016, at 11:04, Yawning Angel wrote:
>>>
>>> On Thu, 24 Nov 2016 01:43:15 +0200
>>> s7r wrote:
I agree that this would be "the technical way" to do it, but real
world usability
On 24 Nov (11:13:06), teor wrote:
>
> > On 24 Nov. 2016, at 11:04, Yawning Angel wrote:
> >
> > On Thu, 24 Nov 2016 01:43:15 +0200
> > s7r wrote:
> >> I agree that this would be "the technical way" to do it, but real
> >> world usability kind of prevents us to do it this way. The spec for
> >>
On 11/24/2016 2:24 AM, Jesse V wrote:
> On 11/23/2016 07:04 PM, Yawning Angel wrote:
>> Our fix: "Add another command, that does essentially the same thing,
>> because people picked the wrong options, then later deal with the
>> fallout from people getting used to the temporary command, and crying
On 11/23/2016 07:04 PM, Yawning Angel wrote:
> Our fix: "Add another command, that does essentially the same thing,
> because people picked the wrong options, then later deal with the
> fallout from people getting used to the temporary command, and crying
> when it's deprecated."
>
> I say "they s
On Thu, 24 Nov 2016 11:13:06 +1100
teor wrote:
> > On 24 Nov. 2016, at 11:04, Yawning Angel
> > wrote:
> >
> > On Thu, 24 Nov 2016 01:43:15 +0200
> > s7r wrote:
> >> I agree that this would be "the technical way" to do it, but real
> >> world usability kind of prevents us to do it this way.
> On 24 Nov. 2016, at 11:04, Yawning Angel wrote:
>
> On Thu, 24 Nov 2016 01:43:15 +0200
> s7r wrote:
>> I agree that this would be "the technical way" to do it, but real
>> world usability kind of prevents us to do it this way. The spec for
>> ADD_ONION indeed does not say that v2 hidden servi
> On 24 Nov. 2016, at 10:56, s7r wrote:
>
>
> teor wrote:
>>
>>>
>>> Very good. We can add a new torrc option for ed25519 key based
>>> authentication for clients (v3) so the current
>>> HiddenServiceAuthorizeClient (v2) will not break old torrc's until
>>> everyone upgrades.
>>>
>>> However
teor wrote:
> No-one is proposing we abolish ADD_ONION with v2 services straight away.
>
> What we will do is make BEST mean v3, rather than v2.
> RSA1024 will continue to mean v2, as it always has.
>
> ADD_ONION has always had an explicit BEST option, if clients don't want
> the BEST type of key
On Thu, 24 Nov 2016 01:43:15 +0200
s7r wrote:
> I agree that this would be "the technical way" to do it, but real
> world usability kind of prevents us to do it this way. The spec for
> ADD_ONION indeed does not say that v2 hidden services will be
> supported forever and it clearly SHOULD NOT, but
teor wrote:
>
>>
>> Very good. We can add a new torrc option for ed25519 key based
>> authentication for clients (v3) so the current
>> HiddenServiceAuthorizeClient (v2) will not break old torrc's until
>> everyone upgrades.
>>
>> However, we could just add an auth-type value after
>> HiddenServi
> On 24 Nov. 2016, at 10:43, s7r wrote:
>
>
> teor wrote:
How does ADD_ONION fit in?
>>>
>>> It's forward compatible by design, since you have to specify a key type
>>> when you handle key management, and Tor gets to do whatever it wants if
>>> you ask it to generate a key with the
teor wrote:
>>>
>>> How does ADD_ONION fit in?
>>
>> It's forward compatible by design, since you have to specify a key type
>> when you handle key management, and Tor gets to do whatever it wants if
>> you ask it to generate a key with the `BEST` algorithm.
>>
>> Assuming people who use it aren't
On Thu, 24 Nov 2016 01:18:46 +0200
s7r wrote:
> Yes, this looks good to me as well. As for ADD_ONION, I think we
> should give the people that use it automatically for other apps a
> change until they upgrade to be compatible with v3, so for the
> transition period as long as v2 is supported (but
> On 24 Nov. 2016, at 10:18, s7r wrote:
>
> Hello David,
>
> David Goulet wrote:
>> Hi everyone!
>>
>> We are soon at the stage of implementing the service part of proposal 224
>> (next gen. hidden service.). Parent ticket is #20657 but I'll be discussing
>> here ticket #18054.
>>
>> In a nut
> On 24 Nov. 2016, at 09:00, Yawning Angel wrote:
>
> On Wed, 23 Nov 2016 03:12:22 +0400
> meejah wrote:
>
>> David Goulet writes:
>>
>>> 1) Once v3 is released, from that point on _no_ v2 service will be
>>> allowed to be created by "tor" itself. It will always be possible
>>> to do it by h
Hello David,
David Goulet wrote:
> Hi everyone!
>
> We are soon at the stage of implementing the service part of proposal 224
> (next gen. hidden service.). Parent ticket is #20657 but I'll be discussing
> here ticket #18054.
>
> In a nutshell, we need to figure out the interface for the torrc f
On Wed, 23 Nov 2016 03:12:22 +0400
meejah wrote:
> David Goulet writes:
>
> > 1) Once v3 is released, from that point on _no_ v2 service will be
> > allowed to be created by "tor" itself. It will always be possible
> > to do it by hand by creating an RSA key and putting it in the
> > service di
> On 24 Nov. 2016, at 06:09, Jesse V wrote:
>
> On 11/23/2016 09:39 AM, David Goulet wrote:
>> I agree with you on the fact that ADD_ONION is nice and also crucial to
>> hidden
>> service as well. That will be addressed with the control port implementation
>> of next generation. It's still an u
On 11/23/2016 09:39 AM, David Goulet wrote:
> I agree with you on the fact that ADD_ONION is nice and also crucial to hidden
> service as well. That will be addressed with the control port implementation
> of next generation. It's still an undecided part of the engineering work which
> is how we ar
On 23 Nov (03:12:22), meejah wrote:
> David Goulet writes:
>
> > 1) Once v3 is released, from that point on _no_ v2 service will be allowed
> > to
> >be created by "tor" itself. It will always be possible to do it by hand
> > by
> >creating an RSA key and putting it in the service direc
David Goulet writes:
> 1) Once v3 is released, from that point on _no_ v2 service will be allowed to
>be created by "tor" itself. It will always be possible to do it by hand by
>creating an RSA key and putting it in the service directory (see 3
>below).
+1 or +2 at least :)
> Ok her
42 matches
Mail list logo
