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

[Tor Bug Tracker & Wiki]

#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 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.

 [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.

 [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.

 [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 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.)

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9974#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online