disabling local-to-local transfers?

[Theo de Raadt]

Brian Candler <b.candler at pobox.com> wrote:

> On 25/07/2026 02:05, Damien Miller wrote:
> > 	for av in "$@" ; do
> > 		if test -z "$_flagsdone" ; then
> > 			case "$av" in
> > 			-*) continue ;;
> > 			*) _flagsdone=1 ;;
> > 			esac
> > 		fi
> > 		case "$av" in
> > 		*:*) _remote=1 ;;
> > 		esac
> > 	done
> 
> That's a rough heuristic. I think that properly parsing scp arguments
> is hard, e.g.
> 
>     scp -J 2001:db8::1 foo bar
> 
> A fully-functional wrapper would likely have to duplicate the entire
> argument parsing code from scp.
> 
> FWIW: I've had a few cases over the years of accidentally creating
> local file copies, and I've never *intentionally* used scp for local
> copying. If the proposed feature were available, I'd certainly turn it
> on in my own ~/.ssh/config.

Oh great, another fiction!

scp does not open or read ~/.ssh/config

Having scp open and parse that file, which requires thousands of lines
of code in the option parser doesn't make sense.

It is highly likely that someone has a script running scp inside some
sort of filesystem containment mechanism that would fail
catastrophically because the ~/ directory is intentionally hidden, and
therefore break the command will behave differently, and someone's data
pipeline will develop a "new behavior".

I'll repeat the chunk from the manual page:

     The source and target may be specified as a local pathname, a remote host
     with optional path in the form [user@]host:[path], or a URI in the form
     scp://[user@]host[:port][/path].  Local file names can be made explicit
     using absolute or relative pathnames to avoid scp treating file names
     containing `:' as host specifiers.

The code which does this was in the ancestor rcp.c before many of you
were born.

It is too late.

I have personally spent decades working with others to change the
behaviour of established programs for various reasons, and always the
process is to re-discover all behaviours that stand in the way of a
change, then prototype fixes for those existing use cases to satisfy the
new proposed behaviour, OR recognize that the behaviour change faces too
high a barrier and find a different way or abandon the effort.  That is
not being done by anyone here, so the proposal and request is
uneducated, unjustified, and frankly irresponsible.