I think a better option is to have an extension to take a checksum over
a file, or an arbitrary subset of one. re(get|put) could then validate
the file before continuing with it.
This would be quite easy to do using the draft-secsh-filexfer
protocol's vendor extension mechanism, if someone want to try to
beat in implementing it :)
If anyone is interested, please discuss your proposed design on-list.
-d
Darryl L. Miles wrote:> Ben Lindstrom wrote (a very long time ago) :
>
> >The problem is in some cases the data being sent to you may be out of
> >order (thankful no sftp server does this yet). So reget/reput without
RFC
> >clearifications can lead to bad file transfers.
> >
> >I'm trying to drag up in my mind which one was the problem... I
believe
> >reput is fine since the client has control over the ordering. reget is
> >the troublesome some one without RFC clarifications stating out of
order
> >transfers are denied.
> >
> >if the RFC get clarified to disallow out of order transfers then a
cleaned
> >up version of this patch may not have a problem getting in.
>
>
> It seems everyone body has a patch for this but it still can't quite
> make it into any official distribution. Not wanting to stifle technical
> progress down surely the standards body have mechanism to allow new
> concepts to be experimentally deployed without affecting non-cooperating
> parties ?
>
> Is it really necessary to get RFC clarification on this, maybe its
> useful to leave as-is and have the option to execute out-of-order for in
> uses.
>
> Would it be possible to extend the channel initialisation options to
> negotiate a feature requesting "mandatory in-sequence execution of
> commands within this channel". I'm not sure how these options are
> created or assigned but maybe use some OpenSSH naming space until a
> standard group either accepts or rejects the concept and assigns it a
> standard option name.
>
> Non-conforming servers would not understand the option and the client
> could then disable the reget/reput commands from use in that session.
>
> I do not know enough about the OpenSSH implementation to know if its
> possible for it to ever execute commands out of sequence with respect to
> the channel they are in nor the contraints this may pose to future
> maintainace of OpenSSH.
>
> To confirm the scope of the option suggested, it says nothing about any
> other channel nor the order in which channels are attended to within the
> server, this stays as-is.
>
>
> RFC ? Please Cc your reply Thanks.
>
>