[tor-bugs] #9974 [Flashproxy]: packaging and installation scripts for facilitator
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri Nov 15 12:41:35 UTC 2013
#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
More information about the tor-bugs
mailing list