username not url decoded in backend (at least rsync)

[edso]

there is a long bug conversation at duply's bugtracker
https://sourceforge.net/tracker/index.php?func=detail&aid=2996459&group_id=217745&atid=1041147

summary
rsync backend does not use url decoded parsed_url.username but splits it itself from parsed_url.netloc. This leads to rsync asking for password because it does not decode the username, so it ends up unknown.

a quick test here actually showed that rsync behaved similar like ssh treating everything from protocol:// up to the last @ as username e.g. rsync://[user@foo@bar]@host

so using the url decoded parsed_url.username would solve this. ALternativly and cleaner would probably be using env vars, see rsync manpage

USER or LOGNAME
The USER or LOGNAME environment variables are used to determine the
default username sent to an rsync daemon. If neither is set, the username
defaults to "nobody".

I didn't check but probably other commandline backends suffer from the same problem (except ssh).

regards ede/duply.net

[edso (ed.so)]

Here they come .. Changes are

backend.py
- always urldecode password form url
- url_parse port for rsync now, silently ignore rsyncd syntax parse error, alternate port for rsyncd is determined by rsyncbackend
- deprecated os.system, os.popen functions namely run_command(_persist), popen(_persist), both are now interface compatible wrappers to new functions subprocess_popen(_persist)
- subprocess_popen(_persist) shows STDOUT/ERR output on error and returns exitcode, stdout, stderr and uses subprocess.popen which exists only since python 2.4

rsyncbackend.py
- rsyncd authenfication support (should be mentioned in manpage, that this only includes plain rsync and rsync+ssh needs key authentification or ssh-agent or the like)
- alternate port support for rsyncd and rsync over ssh

..ede

[edso (ed.so)]

discovered a bug, where for ssh-rsync the username not put into the rsync call .. fixed with the attached v2 patch

[edso (ed.so)]

sent the changes over to the bug reporter, who uses key auth .. of course he found another bug .. backend:get_password gettpass from input is now configurable for the backend (defaults to on, old behaviour)

attached v3 of the patches