Op do 30 sep. 2021 om 00:53 schreef Damien Miller <djm@xxxxxxxxxxx>: > > > "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@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@xxxxxxxx: 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@xxxxxxxx: 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/ _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
