[16534] in Athena Bugs
Re: kerberized ftp hash mode.
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Thu Dec 3 22:56:30 1998
Date: Thu, 3 Dec 1998 22:56:26 -0500
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Bill Cattey <wdc@MIT.EDU>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, bugs@MIT.EDU, linux-dev@MIT.EDU
In-Reply-To: Bill Cattey's message of Thu, 3 Dec 1998 19:42:46 -0500 (EST),
<oqNn064GgE6e1ZCBI0@mit.edu>
Date: Thu, 3 Dec 1998 19:42:46 -0500 (EST)
From: Bill Cattey <wdc@MIT.EDU>
Might it be possible to do some kind of buffer flush every minute of
real time or some such?
No, because the GSS token can't be processed until it is completely
received, and secure_getc() can't return until it has a valid character
to pass back to recvrequest().
The problem is that the hash printing is happening in recvrequest().
What needs to happen is for the hash printing to happen in recvrequest()
only if the file isn't being sent in a protected (encrypted or integrity
protected) form, and if it is being sent in a protected form, then it
has to happen inside looping_read(), which is called by
secure_getbyte(), which is called by secure_getc().
But looping_read(), secure_getbyte(), and secure_getc() is used for
other things besides just reading the data channel; it's also used for
the command channel.
This is why I described fixing it as being non-trivial. Probably the
best fix is to change all of these routines to take a "print_hash"
parameter, and then change all of the calls to these routines (in both
gss-ftp and gss-ftpd) to pass in 0 for print_hash, except for
recvremote() and sendremote(), which would have to pass in the value of
the hash variable.
- Ted
