Issue: Trusted strings, shell escaping and backwards compatibility.

Inizia esaminando la discussione in #283 e il percorso comune di execute() utilizzato da test(), capture() ed execute(), quindi traccia la gestione dell’ambiente attraverso with() e default_env. Determina il comportamento previsto per taint ed escaping di questi punti di ingresso, inclusi gli avvisi proposti compatibili con le versioni precedenti. Il lavoro è completato quando il comportamento è concordato e sono specificati la relativa compatibilità e i casi di errore.

@ncreuschling @mattbrictson /cc

Continuing from the discussion in #283 I'd like to raise the general issue of shell escaping (shellwords) and what we mean/expect about "escaping strings" and so forth, whilst closing #283 it came to my mind that Rails using Object#taint, Object#tainted? and family works mostly pretty well.

I want to unify behavior.

I would propose the following:

• Identify where we want to escape things, if at all:
  • Arguments to test(), capture(), execute() etc (via the common execute() function)
  • Environment variables, and values when used with with(){}
  • Environment variables when used with default_env
• Find out if strings are tainted or not by default in the Capistrano context.
• Find a backwards compatible way to:
  • Issue a release with warnings for "tainted" strings in the places we care about, warning that behavior will change
• See if it makes sense to compare untrusted (the trust vernacular is deprecated) against their shellescaped counterparts, and exit with an error in that case.

I'm afraid that strings coming from the same file that is running will be trusted by default, so the whole plan falls apart, I'd have to look more closely at the API to see if the default taint value for a string is tainted, untainted, or (ideally) none.

Ideally, this would mean, I could do something like this:

SSHKit.config.default_env = {
   "$MY_LITTLE_PONY".untaint => "i should however be escaped" 
}

This would lead to us calling a literal export $MY_LITTLE_PONY=i should however be escaped, for better or worse.