4 ms·

IMO sftp is underspecified. The 14 IETF drafts that exist for it have all expired and never reached RFC status. In practice, this means that the OpenSSH implem

IMO sftp is underspecified. The 14 IETF drafts that exist for it have all expired and never reached RFC status. In practice, this means that the OpenSSH implementation is the de facto standard, and that interoperating a non-OpenSSH client with a non-OpenSSH server is a gamble. It's interesting that they push for sftp. Personally, if scp is vulnerable to certain types of attacks, I'd rather see an entirely new standard and an effort to avoid having it in draft state for decades.

axaxs 8y ago
I'm not sure SCP is specified at all, though. I recently wrote a true SCP client for Go (not SFTP, which oddly enough all the other "SCP" clients for Go use). The only documentation I could find at all was a single blog post from a guy who worked at Oracle.
throwaway2048 8y ago
sftp died in IETF draft because they kept tacking on outdated and misguided concepts from the original FTP like ASCII/binary transfer mode and record file types(really guys, when was the last time an operating system that used this was popular, the 1980s?), as well as tons of other completely pointless cruft to an otherwise very clean protocol, so OpenSSH decided to stay at draft version 3, and being as they are the dominant implementation by far, the effort died. I'm not sure why we need to see an entirely new standard, sftp as implemented by openssh is well conceived, simple, and covers its use case very well.
- boomlinde 8y ago
  > I'm not sure why we need to see an entirely new standard, sftp as implemented by openssh is well conceived, simple, and covers its use case very well. The key to my point here is "as implemented by openssh". A relevant anecdote: I had to connect from my program to a third party (version 3) SFTP service, IIRC backed by some Oracle software (but don't quote me on that). I had a version 3 client library. The OpenSSH client worked just fine with the remote, and the client library worked just fine with an OpenSSH server. When connecting to the third party, the client gave up. After some debugging I learned that the third party server didn't include the language tag in its response statuses (as SFTP version 3 software should). OpenSSH was just fine with this and ignored the problem, and the third party software was probably only ever tested with OpenSSH based clients. It was definitely a bug in the third party service as far as I was concerned, but I think that this is the natural result of relying on behavior "as implemented by ssh" rather than a stable, well defined (and non-expired) standard.

axaxs 8y ago

I'm not sure SCP is specified at all, though. I recently wrote a true SCP client for Go (not SFTP, which oddly enough all the other "SCP" clients for Go use). The only documentation I could find at all was a single blog post from a guy who worked at Oracle.

throwaway2048 8y ago

sftp died in IETF draft because they kept tacking on outdated and misguided concepts from the original FTP like ASCII/binary transfer mode and record file types(really guys, when was the last time an operating system that used this was popular, the 1980s?), as well as tons of other completely pointless cruft to an otherwise very clean protocol, so OpenSSH decided to stay at draft version 3, and being as they are the dominant implementation by far, the effort died. I'm not sure why we need to see an entirely new standard, sftp as implemented by openssh is well conceived, simple, and covers its use case very well.

boomlinde 8y ago
> I'm not sure why we need to see an entirely new standard, sftp as implemented by openssh is well conceived, simple, and covers its use case very well. The key to my point here is "as implemented by openssh". A relevant anecdote: I had to connect from my program to a third party (version 3) SFTP service, IIRC backed by some Oracle software (but don't quote me on that). I had a version 3 client library. The OpenSSH client worked just fine with the remote, and the client library worked just fine with an OpenSSH server. When connecting to the third party, the client gave up. After some debugging I learned that the third party server didn't include the language tag in its response statuses (as SFTP version 3 software should). OpenSSH was just fine with this and ignored the problem, and the third party software was probably only ever tested with OpenSSH based clients. It was definitely a bug in the third party service as far as I was concerned, but I think that this is the natural result of relying on behavior "as implemented by ssh" rather than a stable, well defined (and non-expired) standard.