openssh unix dev - Aug 2020 - Deprecation of scp protocol and improving sftp client

I conjecture that only few of the existing use cases rely on remote expansion. 

In any case (no pun intended), IMHO it would be better to break a few of the
current use cases but leave the majority functional - than kill scp for all.

Regards,
Uri
> On Aug 3, 2020, at 02:50, Jakub Jelen <jjelen at redhat.com> wrote:
> 
> ?On Sat, 2020-08-01 at 00:17 +0000, Blumenthal, Uri - 0553 - MITLL
> wrote:
>> Why can the local and remote paths be sanitized?
> 
> Because remote path is *expected* to be expanded by remote shell before
> executing remote scp. If you sanitize it in any way, you will break
> existing use cases.
> 
>> Regards,
>> Uri
>> 
>>>> On Jul 31, 2020, at 19:57, Ethan Rahn <ethan.rahn at
gmail.com> wrote:
>>> 
>>> ?I wanted to bring this up again due to:
>>> https://github.com/cpandya2909/CVE-2020-15778/. This showcases a
>>> clear
>>> issue with scp which it sounds like cannot be fixed without
>>> breaking scp.
>>> This seems like it would lend some impetus to doing _something_,
>>> even if it
>>> breaks scp or necessitates using something new.
>>> 
>>> Cheers,
>>> 
>>> Ethan
>>> 
>>>> On Wed, Jul 15, 2020 at 7:47 AM Thorsten Glaser <
>>>> t.glaser at tarent.de> wrote:
>>>> 
>>>>> On Wed, 15 Jul 2020, Red Cricket wrote:
>>>>> 
>>>>> I have had this in my .bashrc for years:
>>>>> 
>>>>> alias scp='rsync -avzP'
>>>> 
>>>> Similar, though I named it rcp because nobody has the real rcp
>>>> installed
>>>> any more, but sometimes I need scp to connect to systems that
>>>> lack rsync.
>>>> 
>>>> 
>>>>
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=shellsnippets/shellsnippets.git;a=blob;f=mksh/rcp;hb=HEAD
>>>> 
>>>>> maybe rsync is a better replacement for scp than sftp would
be?
>>>> 
>>>> It could be, were it not under a restrictive licence?
>>>> 
>>>> 
>>>> This doesn?t preclude people from making SSH?s builtin
transfers
>>>> better, though.
>>>> 
>>>> bye,
>>>> //mirabilos
>>>> --
>>>> ?MyISAM tables -will- get corrupted eventually. This is a fact
of
>>>> life. ?
>>>> ?mysql is about as much database as ms access? ? ?MSSQL at
least
>>>> descends
>>>> from a database? ?it's a rebranded SyBase? ?MySQL however
was
>>>> born from a
>>>> flatfile and went downhill from there? ? ?at least jetDB
doesn?t
>>>> claim to
>>>> be a database?  (#nosec)    ??? Please let MySQL and MariaDB
>>>> finally die!
>>>> _______________________________________________
>>>> openssh-unix-dev mailing list
>>>> openssh-unix-dev at mindrot.org
>>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>>> 
>>> _______________________________________________
>>> openssh-unix-dev mailing list
>>> openssh-unix-dev at mindrot.org
>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> -- 
> Jakub Jelen
> Senior Software Engineer
> Security Technologies
> Red Hat, Inc.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5874 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200803/87a177a3/attachment.p7s>

Blumenthal, Uri - 0553 - MITLL wrote:
> I conjecture that only few of the existing use cases rely on remote
expansion.
For local-to-remote operation your conjecture may be correct,
for remote-to-local not so much.

It's a fairly key feature that scp globs on the remote, without roundtrip,
and the SFTP protocol doesn't offer a method to do so.


//Peter

On Mon, Aug 3, 2020 at 9:51 AM Blumenthal, Uri - 0553 - MITLL
<uri at ll.mit.edu> wrote:
>
> I conjecture that only few of the existing use cases rely on remote
expansion.
>
> In any case (no pun intended), IMHO it would be better to break a few of
the current use cases but leave the majority functional - than kill scp for all.
>
> Regards,
> Uri
Especially with "WinSCP" users still out there.

On Mon, 3 Aug 2020, Blumenthal, Uri - 0553 - MITLL wrote:
> I conjecture that only few of the existing use cases rely on remote
expansion.
No, this is used all the time.

scp remotehost:foo\* .

(Unless rsync is available, but sadly that?s ? GPLv3 and ? not
universally installed.)

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
Tel: +49 228 54881-393 ? Fax: +49 228 54881-235
HRB 5168 (AG Bonn) ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

I hear you - but it seems that the choice is between (a) limiting
"scp" functionality to address the security vulnerability, and (b)
killing "scp" altogether.

I'd much prefer (a), even if it means I lose "scp remotehost:foo\*
.".

Especially, since (almost always) I have equal privileges on both local and
remote hosts, so in that case I just originate that "scp" from that
remote. ;-)

TNX


?On 8/3/20, 11:09, "Thorsten Glaser" <t.glaser at tarent.de>
wrote:

    On Mon, 3 Aug 2020, Blumenthal, Uri - 0553 - MITLL wrote:

    > I conjecture that only few of the existing use cases rely on remote
expansion.

    No, this is used all the time.

    scp remotehost:foo\* .

    (Unless rsync is available, but sadly that?s ? GPLv3 and ? not
    universally installed.)

    bye,
    //mirabilos
    -- 
    tarent solutions GmbH
    Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
    Tel: +49 228 54881-393 ? Fax: +49 228 54881-235
    HRB 5168 (AG Bonn) ? USt-ID (VAT): DE122264941
    Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander
Steeg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200803/f18eb2b6/attachment-0001.p7s>

Thorsten Glaser kirjoitti maanantai 3. elokuuta 2020:
> On Mon, 3 Aug 2020, Blumenthal, Uri - 0553 - MITLL wrote:
> 
> > I conjecture that only few of the existing use cases rely on remote
expansion.
> 
> No, this is used all the time.
> 
> scp remotehost:foo\* .
> 
> (Unless rsync is available, but sadly that?s ? GPLv3 and ? not
> universally installed.)
And even if rsync *would* be there it is not really suited to fetching files
without recursing into subdirectories... Hence case for  scp.

  - juice -


-- 
Sent from my SFOS/XperiaX

I don't understand the concern. I just tried

	sftp remotehost:foo\* .

...and it did exactly what one would expect. It successfully retrieved all
files starting with foo.

It sure looks like globbing Just Works with sftp, so replacing the
underlying implementation of scp to use sftp should also work.

--Greg

On Mon, Aug 03, 2020 at 05:08:28PM +0200, Thorsten Glaser
wrote:
> On Mon, 3 Aug 2020, Blumenthal, Uri - 0553 - MITLL wrote:
> 
> > I conjecture that only few of the existing use cases rely on remote
expansion.
> 
> No, this is used all the time.
> 
> scp remotehost:foo\* .
> 
> (Unless rsync is available, but sadly that?s ? GPLv3 and ? not
> universally installed.)
> 
> bye,
> //mirabilos
> -- 
> tarent solutions GmbH
> Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
> Tel: +49 228 54881-393 ? Fax: +49 228 54881-235
> HRB 5168 (AG Bonn) ? USt-ID (VAT): DE122264941
> Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander
Steeg
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev