On 07 Oct 2021 17:08, Damien Miller wrote: > On Thu, 30 Sep 2021, Mike Frysinger wrote: > > i decided to look at what SFTPv4 would actually look like were it implemented. > > tbh, if we only do the server, i don't think it's really that bad, especially > > when we compare it to implementing custom extensions (vs the status quo). if > > anything, i think doing SFTPv4 is better code-wise than doing extensions. > > IMO the question remains: why? > > Specifcally, what use-cases do each of these things enable? i outlined this in the patch series i sent out ... but i'll summarize even more here. here are SFTPv3 problems that SFTPv4 solves. SFTPv3 is going to break in 2038 due to 32-bit timestamps. SFTPv3 is limited to seconds granularity (no-subseconds). SFTPv3 only supports numeric uid/gid, so can't do "chown vapier" and let the server resolve the names. SFTPv3 does not support birthtime stat. and to reiterate, supporting SFTPv4 does not require ACL processing of any sort. there is a single "acl" string in the file attributes, but there is no requirement that the server/client send it, or even process it. so my patches ignore it. which means supporting SFTPv4 in the server comes down to: (1) reworking file attributes parsing (2) skipping the "longname" field that was removed from a bunch of messages if we were to design our own set of extensions on top of SFTPv3, we'd have to basically do (1) anyways, so just supporting SFTPv4 instead seems like a better route to take. -mike
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
