is SFTPv4 support possible?

[Stef Bon]

Op wo 29 sep. 2021 om 08:34 schreef Mike Frysinger <vapier at gentoo.org>:
>
> On 29 Sep 2021 12:35, Damien Miller wrote:

> > 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.
>
> otherwise, i think your idea would also work within the SFTPv3 spec and not
> break anyone.  it would mean servers & clients would have to serialize to
> strings everywhere, but maybe that's not a big deal.  the standard & extension
> fields would have to both be specified, and the other side would ignore the
> standard data when it sees the extension.  e.g. the uid & gid fields would have
> to be specified, but if the username & group extensions were include, they'd be
> ignored in favor of dynamic lookup.
>
> rough sketch of extensions i'd be interested in:
> * attrs-type at openssh.com - the possible file types from stat/getdents:
>   "block" "char" "dir" "fifo" "link" "reg" "socket" "unknown"
> * attrs-owner at openssh.com - the username as a string (instead of uid)
> * attrs-group at openssh.com - the groupname as a string (instead of gid)
> * attrs-atime-sec at openssh.com - the 64-bit access time (if 32-bit overflows)
> * attrs-mtime-sec at openssh.com - the 64-bit modify time (if 32-bit overflows)
> * attrs-ctime-sec at openssh.com - the 64-bit status time
> * attrs-btime-sec at openssh.com - the 64-bit create time
> * attrs-atime-nsec at openssh.com - the subsecond access time (for nanoseconds)
> * attrs-mtime-nsec at openssh.com - the subsecond modify time (for nanoseconds)
> * attrs-ctime-nsec at openssh.com - the subsecond status time (for nanoseconds)
> * attrs-btime-nsec at openssh.com - the subsecond create time (for nanoseconds)
>
> maybe instead of "btime" we should use "createtime" as that would match newer
> SFTP specs better instead of matching Linux's statx field.
>
> i opting for separate sec fields here to make parsing a bit easier.  i figure
> doing strtoull on an entire string is easier than finding the . separator and
> parsing the numbers before/after that.  sscanf(buf, "%llu.%llu", &sec, &nsec).
>

What are you doing? You are reinventing SFTP. The features you want
are in the higher versions of SFTP. Just start supporting versions
higher than 3, and you are there.
And openssh is not the only server and client.

Stef