is SFTPv4 support possible?

[Stef Bon]

Op do 30 sep. 2021 om 00:53 schreef Damien Miller <djm at mindrot.org>:
>

>
> "just" implementing later sftp revisions means promising to support all
> the mandatory features in them, as well as providing compatibility for
> the current version.

Supporting different versions is not that hard. I've written a sftp
client (and busy writing a sftp subsystem) supporting all versions,
and a lot of the callbacks are the same. In my client the receive and
send operations are in an array, which differs per version, and a lot
of them are the same. See for example:

https://github.com/stefbon/OSNS/blob/main/src/sftp/send/send-v03.c
https://github.com/stefbon/OSNS/blob/main/src/sftp/send/send-v06.c

The parsing and setting of attributes is similar. Most important are
the change from uid/gid to owner and group in "user at domain" format,
the possibility of adding subseconds, and c(hange)time.

You say you have to support all mandatory features, that is not so.
They are voluntary, where a basic set (like size, permissions, times
and owner/group) is very advisable. The construction with the
"supported" structure in versions 5 and 6 is designed for that goal:
just set the attributes you want to support, and ignore everything you
do not want to like the ACL's, the mimetype and the untranslated name
for example in the attributes. This also counts for the open flags
(like (b)locks, text mode)

So if you have experienced those new features as mandatory, yes then
it's too much I can imagine, but they are not.

>
> The sftp standardisation process was a trainwreck of accepting poorly-
> justified features that made the later versions of the protocol bloated
> and unwieldy. OpenSSH jumped off the train fairly early and have no
> desire to get back on it.
>

Well there were a lot of things added, but you do not have to support
those. And the stat function in versions higher than version 3 is much
much better than in version 3.

> So, we've been demonstrably willing to consider extensions that fill in
> missing information for _well-justified_ use-cases (e.g. the statvfs
> extension doesn't even exist in later filexfer drafts) , but have no
> desire to adopt the whole mess that protocol became.

No I do not agree that the protocol has become a mess. Just take
out/support the things which have been improved (I've mentioned before
using the supported structure in the version packet) and there you go.

I'm thinking about adding some extensions myself like:

map-extension at osns.net: map a name to a code between 210 and 255, with
the sftp protocol it is possible to assign an opcode  to a name, which
will prevent an expensive name lookup in a linked list.

opendir at osns.net: add a valid parameter to tell the server the
attributes it may send back in a readdir. With a FUSE fs, after the
readdir provides a dentry, a lookup is done. That way the readdir does
not have to provide attributes, only the type and the name. With the
current versions both readdir and lookup (=stat) provide attributes
like size, perm, times and ownergroup, which is double. A valid
parameter in the opendir call makes it also possible to support the
readdirplus call, which is a readdir and lookup in one, where the
client (=FUSE fs) just wants to receive all the desired attributes in
one.
I also have been thinking about a flag and mask in the opendir to add
a fs change watch to a directory to the opendir call: after the
readdir has finished the directory is still watched on the server and
changes according to the mask are sent to the client. This is only a
bit difficult, since the SFTP protocol uses a request-response model
(using an unique id per request), and the server sending back fs
events will be a reply to the original opendir request. Only very
basic events like add, delete and change attributes of a child entry,
as well as (re)move of the directory the watch is on.

Anyway, what I want to say is that supporting the new versions is not that hard.

Stef Bon

https://github.com/stefbon/OSNS
https://osns.net/