On Sat, 14 Feb 2015 13:46:04 -0800 Damian Johnson <atagar@xxxxxxxxxxxxxx> wrote: > One gotcha to think about is that ADD_EPH_HS is using a variable > number of positional arguments. This will limit your ability to expand > this command in the future with new arguments. Also, I'd suggest > renaming addrPort to addrTarget (to avoid making this sound restricted > to a simple port). Hmm ok. Judging by the feedback, I'm thinking the following: * Auth is still a low-ish priority, I want to get the basic ephemeral stuff done first, and I need to read up more on how it works, and how the code is structured, before I can promise things in this area. * People seem to be ok with the tying ephemeral HSes to the originating control port (and if the only major argument against is "it's a bit weird, relative to other things, well, eph. HSes are weird, and this solves a bunch of problems). So this will be implemented as planned. * ADD_EPH_HS syntax changed to something like: "ADD_EPH_HS" keytype:keyblob 1*(SP "Port=" virtPort "," addrTarget) CRLF So, basically, space separated instances of "Port=virtPort,addrTarget" entries, of which there must be at least one. This clearly indicates the argument type and should be future proof (and also has the side benefit of being easier for me to validate. Thoughts? -- Yawning Angel
Attachment:
pgpW3mLYhimDX.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev