On 31 Jan (09:02:35), teor wrote: > > > On 27 Jan 2017, at 01:58, David Goulet <dgoulet@xxxxxxxxx> wrote: > > > >> - "./hostname" [FILE] > >> > >> This is a file containing the onion address of the onion service. > >> > >> As you can see it's the same filename as in v2. Should we suffix it with v3 > >> to make it clear that it's v3 onion? Would we ever have v2 and v3 onions > >> living in the same directory? > > > > I don't believe we should suffix here because for almost 10 years, users/apps > > have been exposed to "hostname" and it does make sense that it's the goto file > > for that. > > This works for applications that simply display the hostname without any > further processing. > > But code that expects a short hostname file may become confused when > exposed to a longer hostname. It may fail silently, refuse to work, > or have some other issue. > > Have you tested any applications that use the hostname file with longer > names? To be honest, I would really hope applications just don't blindly open the file and regex on a 16 char onion... They will be really sad with client auth. But, we can't assume they are all perfect so yes that could be a problem. And I hope that if it's the case, they error gracefully if regex fails. It's kind of unreasonable to ask us to make sure we don't break any applications out there doing such. The only assertion they should make on the "hostname" file is that it contains the address of the address. Your next question is a good one actually so jumping into it! > > > Current implementation doesn't allow two services in the same HiddenServiceDir > > and for prop224, the ongoing implementation doesn't allow it either. Sharing a > > directory brings all sorts of uneeded complexity. So if the directory is v3, > > everything in it will be v3. > > How does an application tell the difference between a v2 and v3 > directory? Right now, apart from the "key tag" in the public key file that will be something like "v3", I don't see any :S ... And I think you are raising a good point. How can we make it easy for any application *only* looking on disk what version the hidden service is? The onion address has the version encoded into it *but* that would require the application to do some base32 decode and truncation magic. Not user friendly enough? Maybe but apart from that, we would need to make it obvious either with a filename or litterally an extra "version file". However, there is kind of an issue rising from this. Imagine that v4 changes the onion address format because new crypto. We'll end up with a problem where the how to extract the version from the address is actually version specific... A solution to that is that "whatever size/encoding the address is, version will ALWAYS be the last 1 byte." Thoughts? > > What's the supported method, that we will continue to support in > future, regardless of key or algorithm changes? Not 100% sure what you mean by "supported method" but I'll take a guess. Those are the one that comes to mind: - Single onion service - Client auth (only basic for now, we don't have stealth specified) Also, every single Hidden Service torrc option will be supported for v3 *EXCEPT* the Tor2Web one. Hope that answers. Thanks! David > > T > > -- > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > ricochet:ekmygaiu4rzgsk6n > xmpp: teor at torproject dot org > ------------------------------------------------------------------------ > > > -- laomWpXMwfgJQSD00XsC6WR0haEh1gK8WeNTaAPQf20=
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev