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

On Mon, 2020-08-03 at 19:17 +0200, Thorsten Glaser
wrote:
> That would be the same as killing scp?
Better that... than having an inherently insecure scp... or at least
make it absolutely clear and rename it to i[nsecure]scp.

If the core functionality of a program (which is here probably the
"secure") is no longer given, then it's IMO better to rather cause
breakage (at least for old clients), than to keep going.


Cheers,
Chris.

On 8/3/20, 14:40, "openssh-unix-dev on behalf of Christoph Anton
Mitterer" <openssh-unix-dev-bounces+uri=ll.mit.edu at mindrot.org on
behalf of calestyo at scientia.net> wrote:
    >> That would be the same as killing scp?
    >
    > Better that... than having an inherently insecure scp...

Not for me! Security provided by "scp" satisfies *my* use case.

    > or at least
    > make it absolutely clear and rename it to i[nsecure]scp.

Couldn't care less. There's a saying "You may call me 'pot'
- just don't stick me into the oven"

    > If the core functionality of a program (which is here probably the
    > "secure") is no longer given, then it's IMO better to
rather cause
    > breakage (at least for old clients), than to keep going.

Again. For me that remote path expansion is not the "core". The
"core" is the ability to do "cp" from one host within my
security domain to another.

-------------- 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/51f7fe87/attachment-0001.p7s>

On Mon, 2020-08-03 at 18:44 +0000, Blumenthal, Uri - 0553 - MITLL
wrote:
> Again. For me that remote path expansion is not the "core". The
> "core" is the ability to do "cp" from one host within
my security
> domain to another. 
Well I guess mandatory should what most people want/can reasonably
expect/and are promised by a given program,... which is here most
likely secure copying over any line from/to an remote host (i.e.
including a scenario with rogue clients and/or servers).

I.e. it should not focus on what just certain people (who e.g. get
their security by other means) need... or even those who don't do their
homework, by e.g. not upgrading to recent versions/etc..



Cheers.

On Mon, Aug 03, 2020 at 08:34:04PM +0200, Christoph Anton Mitterer <calestyo
at scientia.net> wrote:
> On Mon, 2020-08-03 at 19:17 +0200, Thorsten Glaser wrote:
> > That would be the same as killing scp?
> 
> Better that... than having an inherently insecure scp... or at least
> make it absolutely clear and rename it to i[nsecure]scp.
But it's not inherently insecure. For most cases, or at
least for the default case, where the users of scp are
also allowed to use ssh, this is not a vulnerability.
It only becomes insecure when general ssh access is not
allowed but scp access is.
> If the core functionality of a program (which is here probably the
> "secure") is no longer given, then it's IMO better to rather
cause
> breakage (at least for old clients), than to keep going.
The core functionality is the encrypted transfer of
files. That is still there.
> Cheers,
> Chris.
cheers,
raf