Similarly to git (CVE-2017-1000117), Subversion (CVE-2017-9800), and 
Mercurial (CVE-2017-1000116), options for scp/ssh/etc. can be smuggled 
in a darcs repository URL. For example:

darcs get 'ssh://-oProxyCommand=xdg-open https:example.com/'

I believe darcs offers no obvious way (such as git submodules) to 
deliver such an "evil" URL to an unsuspecting user, but I think this is 
still an unexpected security hazard.

What i do not understand here: isn't this a bug in ssh, rather than the
programs that use it? IMO, if ssh interprets 'ssh://-oWhatever' as an
option then it's command line parser is broken and should be fixed;
instead of burdening all existing programs and scripts that happen to
use ssh to apply work-arounds to avoid the issue.

The URL is parsed by darcs, not by ssh (note that darcs parses 
hostname:path syntax as well as ssh://hostname/path, and forms of this 
attack are possible with both syntaxes). The eventual command that gets 
run (you can see this with -debug) is something like:

ssh -oProxyCommand=blahblah darcs transfer-mode

Adding a -- in front of the hostname is sufficient to prevent it from 
being interpreted as a command-line option:

$ ssh -- -oProxyCommand=blah blah
ssh: Could not resolve hostname -oproxycommand=blah: No address 
associated with hostname

Thanks mithrandi, that clears it up; sorry for blaming ssh, will fix.

Fixed by

patch 315bc9fb58ce4245be4bb443d29ae3d1fccd2257
Author: Gian Piero Carrubba <gpiero@rm-rf.it>
Date:   Tue Jan  2 11:14:39 CET 2018
  * Resolve issue2545: prepend "--" to non-option arguments in ssh invocation