[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #9974 [Flashproxy]: packaging and installation scripts for facilitator



#9974: packaging and installation scripts for facilitator
-----------------------------+--------------------------
     Reporter:  infinity0    |      Owner:  dcf
         Type:  enhancement  |     Status:  needs_review
     Priority:  normal       |  Milestone:
    Component:  Flashproxy   |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------------

Comment (by infinity0):

 Replying to [comment:10 dcf]:
 > Good job on this. I paid for a new server to try installing this new
 code on, but I haven't tried setting it up yet. I will try to do so today
 or tomorrow.
 >
 > It's not clear to me in what order I should read the different howto
 documents to set up a new facilitator. I guess it is:
 >  1. facilitator/doc/server-howto.txt
 >  2. facilitator/doc/http-howto.txt
 >  3. facilitator/INSTALL
 > (Followed by facilitator/doc/appspot-howto.txt and facilitator/doc
 /email-howto.txt if those were not already set up.) What is your imagined
 narrative of someone reading and following the instructions? What will
 they naturally try reading first, and what steps do you want them to take?
 I checked facilitator/INSTALL first; maybe that file should contain
 references to the others.
 >

 facilitator/README is a general overview that contains references to the
 others. INSTALL is mentioned first, then later "At a very minimum, you
 must configure and enable the HTTP method" then after that server-
 howto.txt. (I could move it up a bit, but it's now just some non-canonical
 suggestions, and only configures SSH and a firewall.)

 >
 [https://github.com/infinity0/flashproxy/commit/aafd15b8927e0d7519152d3e88f655b571037f04
 #diff-2751e08e60a242b8ab992d77d774e405L13 Setting FP_FACILITATOR in fp-
 reg.go.] It's good to make this externally configurable. I think it's
 better, however, to make the the configurable part a whole URL, and not
 just the domain part. We should support facilitators running on different
 ports and with different base paths. Run `go fmt` after making changes to
 Go files.
 >

 I believe the existing code already supports this, since we only put
 https:// and /reg/ around FP_FACILITATOR which is just a string. (/reg/ is
 hard-coded into facilitator.cgi so I thought to leave it hard-coded here
 too.) I'll fix the docstring to mention this though, right now it just
 says "host[:port]".

 >
 [https://github.com/infinity0/flashproxy/commit/7ed4f653df3b7b6ec92fef41efd3f2295bd097d8
 Removing separate mention of the url registration method.] I think of url
 as being distinct from the the http method. http is a relict from an
 earlier age--we could get rid of http but still keep url. url and appspot
 are more alike than are url and http. http uses a POST with plaintext
 parameters in the request body. url uses a GET with an encrypted payload
 in the path. With the http method, you contact the facilitator yourself,
 while with the url method the URL is retrieved by some third party. url
 isn't very nice by itself because it can't find out your external address
 and therefore can't work automatically, but I think it makes sense to
 discuss it separately in the context of someone operating a facilitator.
 >

 I had added some notes to this effect
 [https://github.com/infinity0/flashproxy/commit/b318c3e51e881e61d8912959b08c15b79c6a961a
 #diff-951f16f2267cb229c326b0d339c6f3ab here]. We can tweak it to make the
 distinction clearer if you want, too.

 >
 [https://github.com/infinity0/flashproxy/commit/a310c1d0f893ebd18a128a9d92684b3cf51d70a4
 Changes to name resolution in facilitator-email-poller.]
 > > - smarter default IMAP host; and resolve DNS by default - previously
 one had to use an IP address
 > > - add a nameOk option to parse_addr_spec as certificate verification
 requires imap host to be a name
 > This is a good bug you found. I'm not wild about the new more
 complicated interface to `parse_addr_spec` with the `nameOk` parameter.
 It's a reasonable thing to add, but I wonder if there is a better way.
 Maybe add a new lower-level function that additionally returns the host
 part string along with what `parse_addr_spec` normally returns--then
 `parse_addr_spec` could call the lower-level function and throw the extra
 information away.
 >

 I think a separate function would only move the complexity around. I found
 it weird that previously the "resolve" param controlled both input
 acceptance and output type. Ultimately, we need three behaviours:

 1. accepts name/ip as input, gives ip as output (nameOk, resolve)
 2. accepts name/ip as input, gives original as output (nameOk, not
 resolve)
 3. accepts ip as input, gives original as output (not nameOk, not resolve)

 In the newer version, "nameOk" controls which inputs are accepted and
 "resolve" controls the type of output. If we delegate (2) to a separate
 function, we'd only need one flag (resolve) but another function for users
 to know about. I think I prefer the two-simple-flags approach rather than
 one-complex-flag-and-one-separate-function.

 Incidentally, (2) is what parse_addr_spec from the client code does -
 accepts DNS names (so you can say e.g. localhost:9000), but doesn't
 resolve them. (But I still think 2-params is better.)

 > I don't think we need the heuristic of guessing imap.<domain> based on
 the email address. Just make the user be explicit. (Realistically, zero
 people are ever going to change the IMAP host, because the program simply
 won't work with any other mail provider than Gmail. If we were to add
 another provider, it might be a good design to have a separate poller
 program to do that, tailored for that other provider's idiosyncrasies.)

 OK, I can get rid of this for now. I suppose it's easier for the case
 where you have a gmail address that doesn't end in @gmail.com.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9974#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs