[Bug 3488] scp fails to locate remote paths containing a non-empty square bracket pair

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3488

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #3 from Darren Tucker <dtucker at dtucker.net> ---
What's happening is that the bracket pairs denote glob(3) patterns, and
examples E through H are patterns that do not match anything.  If you
add a file that does match the pattern you can see this:

$ touch path/foo0
$ scp -v 'localhost:path/foo[0]' /tmp
[...]
$ scp: debug1: Fetching path/foo0 to /tmp/foo0

and you can prefix the brackets with a backslash to prevent this:

$ scp -v 'localhost:path/foo\[0\]' /tmp
[...]
scp: debug1: Fetching path/foo[0] to /tmp/foo[0]

I suspect this might have worked with older scp versions because the
path would get passed to the shell, but since the glob didn't match
anything it would not be expanded and used literally.  It doesn't work
with scp's current fallback mode because the sent file ends up not
matching what the local scp thinks it requested and the defenses
against remote scp bogus path attacks block it:

$ scp -O 'localhost:path/foo[0]' /tmp
protocol error: filename does not match request

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.