url passwords are not escaped, duplicity crashes

[edso]

this probably affects all data given in the url string!

text attached from original message:
http://lists.gnu.org/archive/html/duplicity-talk/2009-12/msg00028.html

I forward this because he is totally right and this should also be fixed upstream.

What duply does from the next release (which is from today's xmas release ;) is to url encode separately given user/password params and hinting the user in the conf file that special chars have to be url encoded in the parts username, password, path of the url.

As duplicity can't possibly know if a user already url encoded these, it can't really fix it. But it should still try to guide the user around such errors.
a) I guess some note about the necessity url encoding in the error message would help a lot here.
b) Additionally the whole url could be scanned for chars that are not A-Za-z0-9._-~:/ . As duplicity backends do not have querystrings I guess any other character in the url means that the url is not valid.

... merry days, ede

-------- Original Message --------
Bugs item #2920707, was opened at 2009-12-24 14:28
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1041147&aid=2920707&group_id=217745

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ftp passwords are not escaped, duplicity crashes

Initial Comment:
When an ftp password contains special characters (in my case the ? and = letters), they must be encoded as %3F and %3D. Currently, neither duply not duplicity do the escaping, and neither of them tell the user to do it manually. If they are not encoded properly, duplicity will crash with a rather meaningless error message. For ftplictiy V 0.5.18 it's:

User error detail: Traceback (most recent call last):
File "/usr/bin/duplicity", line 825, in <module>
with_tempdir(main)
File "/usr/bin/duplicity", line 818, in with_tempdir
fn()
File "/usr/bin/duplicity", line 747, in main
action = commandline.ProcessCommandLine(sys.argv[1:])
File "/usr/lib/python2.6/dist-packages/duplicity/commandline.py", line 593, in ProcessCommandLine
backup, local_pathname = set_backend(args[0], args[1])
File "/usr/lib/python2.6/dist-packages/duplicity/commandline.py", line 488, in set_backend
backend1, backend2 = backend.get_backend(arg1), backend.get_backend(arg2)
File "/usr/lib/python2.6/dist-packages/duplicity/backend.py", line 84, in get_backend
pu = ParsedUrl(url_string)
File "/usr/lib/python2.6/dist-packages/duplicity/backend.py", line 191, in __init__
raise InvalidBackendURL("Syntax error (port) in: %s" % url_string)
InvalidBackendURL: Syntax error (port) in: ftp://username123:address@hidden

In duplicity 0.5.09 the error message is different, more useless, but about the same type of problem.

I see three possible solutions:
* duply should encode the password properly
* duplicity should encode the password properly
* both duply and duplicity should state more clearly that they need pre-encoded passwords, so that the user knows he must do it himself

[edso (ed.so)]

I looked around .. only ftp,rsync and hsi use the functions in question

actually I think it's very bad codeing to obfuscate a commandline that was laready existing in parts. Meaning I will probably modify the mentioned backends to deliver a commanline with placeholders, which are filled in with credentials and therefor don't pose a security risk if printed out.

ede