On 10 Nov (04:06:55), teor wrote:
>
> > On 10 Nov 2017, at 03:17, Yawning Angel wrote:
> >
> > On Thu, 9 Nov 2017 10:13:45 -0500
> > David Goulet wrote:
> Ok fun! I'll add this. Good catch! And control-spec.txt should be
> updated.
>
> To be consistent then we could ask for
> On 10 Nov 2017, at 03:17, Yawning Angel wrote:
>
> On Thu, 9 Nov 2017 10:13:45 -0500
> David Goulet wrote:
Ok fun! I'll add this. Good catch! And control-spec.txt should be
updated.
To be consistent then we could ask for a as well:
"ED25519-V3:"
On Thu, 9 Nov 2017 10:13:45 -0500
David Goulet wrote:
> > > Ok fun! I'll add this. Good catch! And control-spec.txt should be
> > > updated.
> > >
> > > To be consistent then we could ask for a as well:
> > >
> > > "ED25519-V3:"
> > >
> > > ... which contains the ed25519 private key.
> >
On 09 Nov (09:27:15), Yawning Angel wrote:
> On Tue, 7 Nov 2017 12:20:15 -0500
> David Goulet wrote:
> > > This might need a couple more details; as-is ADD_ONION can take
> > > "NEW:BEST" (which should now return a v3 service?) or
> > > "NEW:ED25519-V3" for explicitly asking for a V3 key, or
> > >
On Tue, 7 Nov 2017 12:20:15 -0500
David Goulet wrote:
> > This might need a couple more details; as-is ADD_ONION can take
> > "NEW:BEST" (which should now return a v3 service?) or
> > "NEW:ED25519-V3" for explicitly asking for a V3 key, or
> > "ED25519-V3:<56 base32 chars>" for adding an already-e
On 8 Nov 2017, at 04:20, David Goulet wrote:
>>> 3.1.3. ADD_ONION
>>>
>>> For this command to support version 3, new values are added but the syntax
>>> is unchanged:
>>>
>>> "ADD_ONION" SP KeyType ":" KeyBlob
>>> [SP "Flags=" Flag *("," Flag)]
>>> 1*(SP
David Goulet writes:
> To be consistent then we could ask for a as well:
>
> "ED25519-V3:"
>
> ... which contains the ed25519 private key.
Maybe it's too late, but it would be nice if the hs_ed25519_secret_key
file was encoded in base64 as well (instead of binary) to facilitate
copying them
> Not entirely true actually, if we do that, the old Stem won't be able to
> pickup the descriptor ID from new Tor... So how do you suggest to proceed with
> backward compat? Just a new field like "DESCRIPTOR_ID=" and we leave the
> "DescriptorID" in duplicating the information for v2 descriptors?
On 07 Nov (12:47:43), David Goulet wrote:
> On 07 Nov (09:40:36), Damian Johnson wrote:
> > > What do you propose exactly?
> >
> > Hi David. What I mean is that having an optional positional field...
> >
> > MyEvent Field1 Field2 [Field3] Key1=Value1
> >
> > ... means we cannot ever add more pos
Damian Johnson writes:
>> What do you propose exactly?
>
> Hi David. What I mean is that having an optional positional field...
I think the missing fact here is that there is *already* the
DescriptorID field and it's already optional (in the current
control-spec).
--
meejah
___
David Goulet writes:
> On 06 Nov (10:15:18), Damian Johnson wrote:
>> Hi David, great proposal! Sorry I'm juggling too many things right
>> now to really really review it. Quick skim though looks great. One
>> quick thought is that the HS_DESC event has an optional positional
>> argument (Descrip
David Goulet writes:
> Indeed.
>
> I'm unsure between
> "512 Syntax error in command argument"
>
> "552 Unrecognized entity"
> [A configuration key, a stream ID, circuit ID, event,
> mentioned in the command did not actually exist.]
>
> But overall yes!
It looks like the
On 07 Nov (09:40:36), Damian Johnson wrote:
> > What do you propose exactly?
>
> Hi David. What I mean is that having an optional positional field...
>
> MyEvent Field1 Field2 [Field3] Key1=Value1
>
> ... means we cannot ever add more positional fields in the future. For
> example...
>
> MyEven
> What do you propose exactly?
Hi David. What I mean is that having an optional positional field...
MyEvent Field1 Field2 [Field3] Key1=Value1
... means we cannot ever add more positional fields in the future. For
example...
MyEvent Field1 Field2 [Field3] [Field4] Key1=Value1
... would be ambi
On 06 Nov (15:44:26), AntiTree wrote:
> Hey David,
>
> Are there any ways of revoking a service's key and should it be included as
> a control port function? For example, in the case that the master key is
> kept offline but the host and its descriptor signing key are compromised,
> the box could
On 06 Nov (22:35:32), meejah wrote:
> David Goulet writes:
>
> Hi David,
>
> Overall looks good! A few comments inline:
>
> > "onions/{current,detached}"
> >No change. This command can support v3 hidden service without changes
> >returning v3 address(es).
>
> Does the cont
On 06 Nov (10:15:18), Damian Johnson wrote:
> Hi David, great proposal! Sorry I'm juggling too many things right now
> to really really review it. Quick skim though looks great. One quick
> thought is that the HS_DESC event has an optional positional argument
> (DescriptorID). This is fine *but* I'
David Goulet writes:
Hi David,
Overall looks good! A few comments inline:
> "onions/{current,detached}"
>No change. This command can support v3 hidden service without changes
>returning v3 address(es).
Does the control-spec need a note pointing out that you might get some
Hi David, great proposal! Sorry I'm juggling too many things right now
to really really review it. Quick skim though looks great. One quick
thought is that the HS_DESC event has an optional positional argument
(DescriptorID). This is fine *but* I'd advise against it since it will
prevent you from e
Hey David,
Are there any ways of revoking a service's key and should it be included as
a control port function? For example, in the case that the master key is
kept offline but the host and its descriptor signing key are compromised,
the box could be run for a period of time(?) until the keys expi
Hi everyone,
Attached is the proposal draft for the hidden service v3 contro port
specification.
The idea with this proposal is to _only_ extend the current commands and
events to v3. Nothing new is added. We can think of more things to add after
but for now, I wanted a baseline to start with tha
21 matches
Mail list logo
