Opened 4 years ago

Last modified 4 years ago

#9976 new defect

flashproxy-client needs to pass args to reg-methods

Reported by: infinity0 Owned by: dcf
Priority: Medium Milestone:
Component: Archived/Flashproxy Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

At the moment it's not possible to (e.g.) give an email address to flashproxy-client for use in reg-email.

One possibility is to have args like --reg-email-arg=x --reg-email-arg=y then [x, y] gets passed as args to reg-email. This is similar to what I have implemented in obfs-flash, where --fp-arg=x gets passed to flashproxy-client.

Child Tickets

Change History (3)

comment:1 Changed 4 years ago by dcf

This is a good observation. We currently special-case a few options (like --facilitator, which has meaning only for flashproxy-reg-http). But we don't want to do that for every possible option for every possible registration helper.

I'm afraid I must vigorously object to passing options as arguments of other options. I think it's long and hard to read, like a doubly escaped string. Some things I would prefer (just brainstorming, not meant to be exhaustive):

  1. A configuration file stating what command to run for each registration method string. We might need to introduce some syntax so that the usual options controlled by flashproxy-client are still propagated correctly.
    [appspot]
    flashproxy-reg-appspot ${AF_INET:+-4} ${AF_INET6:+-6} ${TRANSPORT:+--transport=$TRANSPORT} ${UNSAFE_LOGGING:+--unsafe-logging} ${FACILITATOR_PUBKEY:+--facilitator-pubkey=$FACILITATOR_PUBKEY} $ADDRESS
    [email]
    flashproxy-reg-email ${AF_INET:+-4} ${AF_INET6:+-6} ${TRANSPORT:+--transport=$TRANSPORT} ${UNSAFE_LOGGING:+--unsafe-logging} ${FACILITATOR_PUBKEY:+--facilitator-pubkey=$FACILITATOR_PUBKEY} $ADDRESS
    [http]
    flashproxy-reg-http ${AF_INET:+-4} ${AF_INET6:+-6} ${TRANSPORT:+--transport=$TRANSPORT} ${UNSAFE_LOGGING:+--unsafe-logging} ${FACILITATOR_URL:+--facilitator=$FACILITATOR_URL} $ADDRESS
    [twitter]
    my-twitter-registerer ${TRANSPORT:+--transport=$TRANSPORT} ${UNSAFE_LOGGING:+--loglevel=none} --register-address=$ADDRESS
    
    The ${:+} syntax is borrowed from Bash and is just a suggestion. This is a pretty heavyweight solution but it's also general and complete because it doesn't require changes to flashproxy-client when a new helper is added (perhaps somebody's private homebrew helper), and it doesn't require helpers to conform to the option naming convention we've established (notice the fictitious "twitter" helper I added).
  2. A flashproxy-client option to give an entire command line to run.
    flashproxy-client --register-command='flashproxy-reg-email --email=blah@blah'
    # Try http, appspot, and a custom command.
    flashproxy-client --register-methods http,appspot --register-command='my-twitter-registerer'
    
    This way, the custom commands would not automatically pick up options like -4 and --unsafe-logging. But it would provide complete flexibility to use the helpers we ship, and also would allow you to use any other helper you may have.
  3. An option that at least lets you set all the helper's extra options at once. So
    flashproxy-client --reg-email-extra='--foo bar'
    
    Instead of
    flashproxy-client --reg-email-arg=--foo --reg-email-arg=bar
    
    Something to note about this technique (may not be important) is that it doesn't allow you to delete options that might otherwise be set.

comment:2 Changed 4 years ago by infinity0

I'm ok with the single-command line idea, but it could potentially lead to even worse double-escaping :p (or even worse, non-functionality, depending on whether Tor parses the ClientTransportPlugin line coherently).

We can use http://docs.python.org/2/library/shlex.html to split the line. Implementation-wise it would be simpler to use python's %()s syntax, so then we'd get something like:

flashproxy-client --register-command='reg-twitter --extra-twitter-specific-flags %(fp_options) %(address)'

If feasible, I'd prefer to keep things simple and keep all the potentially-inheritable options in a single %(fp_options) variable. If the reg-method gets non-sensical options (e.g. facilitator URL for reg-email) it should just ignore them. (We could move this code to the common library, so anything written in python can do this with ease.)

Some more possibilities:

  • automatically append "%(fp_options) %(address)" to any command string that doesn't have a % character.
  • automatically convert "xxx yyy zzz" to "flashproxy-reg-xxx yyy zzz" if "xxx" doesn't exist on the PATH.
Last edited 4 years ago by infinity0 (previous) (diff)

comment:3 in reply to:  2 Changed 4 years ago by dcf

Replying to infinity0:

I'm ok with the single-command line idea, but it could potentially lead to even worse double-escaping :p (or even worse, non-functionality, depending on whether Tor parses the ClientTransportPlugin line coherently).

We can use http://docs.python.org/2/library/shlex.html to split the line. Implementation-wise it would be simpler to use python's %()s syntax, so then we'd get something like:

I agree that shlex is clearly the right way to parse options representing a command line.

flashproxy-client --register-command='reg-twitter --extra-twitter-specific-flags %(fp_options) %(address)'

If feasible, I'd prefer to keep things simple and keep all the potentially-inheritable options in a single %(fp_options) variable. If the reg-method gets non-sensical options (e.g. facilitator URL for reg-email) it should just ignore them. (We could move this code to the common library, so anything written in python can do this with ease.)

That's an interesting idea, to have registration helpers ignore options that are not meant for them. I think it's quite reasonable, at least, to force all registration helpers into a common command-line option rubric, so that we don't have to worry about cases like a program accepting --my-transport instead of --transport or something like that.

Some more possibilities:

  • automatically append "%(fp_options) %(address)" to any command string that doesn't have a % character.
  • automatically convert "xxx yyy zzz" to "flashproxy-reg-xxx yyy zzz" if "xxx" doesn't exist on the PATH.

These two options seem more magical than I like, but we can talk about it. The first one sounds better, and not likely to surprise anyone, though potentially unnecessary. The second one, I don't know, it's not like people are typing those torrc lines so much that we need to abbreviate. ("Explicit is better than implicit"?) It would allow someone who can create programs in your PATH to hijack your exec, by creating a file called flashproxy-reg-xxx. May be even easier if xxx contains a slash.

Note: See TracTickets for help on using tickets.