is SFTPv4 support possible?

[Damien Miller]

On Wed, 29 Sep 2021, Mike Frysinger wrote:

> > How many of these things could be implemented as extensions?
> > 
> > AFAIK we could use SSH_FILEXFER_ATTR_EXTENDED extensions to send
> > nanosecond timestamps as well as user/group names, and it should be
> > backwards compatible...
> 
> hmm, if we're thinking outside the box ...
> 
> one thought i had but figured would be rejected was that we'd backport
> the new SSH_FILEXFER_ATTR_OWNERGROUP to SFTPv3 (as it's backwards
> compatible), but that might work OK for client->server, but not so
> well for server->client (since the spec makes it sound like flags must
> be within the defined range only). so lets forget about this avenue.
>
> another idea was that we'd define an extension whereby the client
> could upgrade its connection (akin to HTTP upgrading to 1.1 or 2.0).
> the server would have "sftpv4-file-attrs at openssh.com", and if the
> client sent that request, then all file attrs would have to use the
> newer SFTPv4 form for the rest of the session. i think this is still
> within the SFTPv3 spec and wouldn't break anyone. it has the slight
> advantage of the types being directly encoded.

Well, I guess there are three broad extension approaches for file
attributes:

1. Define all the additional attributes as SSH2_FILEXFER_ATTR_EXTENDED
   extensions.

2. What you suggest above: have some modal extension that selected
   sftp v>3 attribute encoding to get the additional attributes.

3. Have some extension that allows the client and server to negotiate
   extended members in the attribute flags bitmask.

#1 has the advantage of being completely backwards compatible without
needing a negotiation mechanism. OTOH it's pretty heavy on the wire,
with even a single byte attribute needing a whole qualified name to
encode it.

I think #2 would make sense if we had a desire to move in the direction
of later protocol versions in the future. We don't - IMO the later
versions are at best a mixed bag of some desirable features and a lot
of junk.

#3 is basically #1 with most of the overhead removed (at the cost of
an additional thing that the client and server have to agree on)

For some things, #1 definitely makes the most sense - a number of
the things that you ask for can be considered extended information
that relates to attribute flags that already exist. For example,
we could send a filetimes at openssh.com extension that included
nanosecond times and ctime whenever we send an attribute with
SSH2_FILEXFER_ATTR_ACMODTIME.

I'm not 100% sure what the best approach for owner/group is
though. One one hand, we could send it as an extension whenever
SSH2_FILEXFER_ATTR_UIDGID is sent, but that is a lot of extra
information. Would a user/group-lookup at openssh.com extension work
better? That would allow the client to incur the cost only once for each
user/group resolved during a session (assuming the client implements a
cache).

Implementing these as lookup extensions has the side benefit of allowing
administrators to turn it off via the existing request denylisting
feature, as I expect a few will want to do.

For file type, can't you already infer this from the higher bits of
SSH2_FILEXFER_ATTR_PERMISSIONS? sftp-server doesn't filter them
from what stat(2) returns. I guess we could advertise this fact to make
it clear to clients that they can be relied upon...

-d