is SFTPv4 support possible?

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20211007/ef788c5f/attachment.asc>