shell-escape supplied Subversion credentials

[joshpencheon]

Summary

Previously, if svn_username or svn_password contained e.g. whitespace, the SCM commands would fail. This PR uses the shellwords library (part of stdlib) to properly escape them.

Short checklist

• [x] Did you run bundle exec rubocop -a to fix linter issues?
• [ ] If relevant, did you create a test?
• [x] Did you confirm that the RSpec tests pass?
• [x] If you are fixing a bug or introducing a new feature, did you add a CHANGELOG entry?

[leehambley]

hi @joshpencheon thanks for your submission. Can you tell me a bit more about whats going on here and if you have any idea why now, 6 years (!!) after we wrote the code is now a good time to change it.

I'd suspect SVN isn't exercised very much and you have unusual chars in your password, but I'd like to verify those assumptions before acting.

Thanks!

[joshpencheon]

Dear @leehambley,

Thanks for taking a look. We're still using a private SVN repository for many of our codebases. Almost all of our projects are still using Capistrano 2 for other reasons, a recent one has finally (!) made the switch to Capistrano 3. With this came the switch to having a checkout of the repository on the target machine, rather than the client machine, which is why only now are we sending SCM credentials through Capistrano.

We found that some staff were able to deploy the project, and others couldn't. Upon taking the hood up, I realised these parameters are passed through without shell escaping, and sshkit does not escape them either. It then transpired that the staff members having problems had spaces in their SVN passwords.

Thanks, Josh

[leehambley]

I'm happy to take a patch, but we're not due a release for some time.

Have you considered using something like https://stackoverflow.com/questions/3985983/how-can-i-checkout-password-protected-subversion-repositories-with-bitbake ?

That has its drawbacks, but may simplify the svn repo <--> server part of your authentication/authorization story?

[joshpencheon]

Thanks for the pointer, @leehambley - we've got a workaround at the point where we feed credentials i in to Capistrano, so we're set for the time being.

I can only hypothesise why this issue hasn't been reported before, but including this patch in the next scheduled release would be much appreciated :)

[will-in-wi]

Hey @leehambley this makes sense to me. Any concerns with merging it?