bugs.txt

伯克利做的SFTP安全文件传输协议

Known bugs in SafeTP
--------------------

------
DB, forever:  16-bit apps under 95/98 hang the system hard-core.


Fixed bugs (include who, date, software & version)
--------------------------------------------------
SM, 9/29/99, sftpd 1.10:  Failed relay on PORT commands.

When data-channel encryption is off, but ftpd *is* happy with
3rd-party transfers, ftpd's (successful) reply to the PORT command
is not relayed to the client.

Also, in 959 interop mode, no command replies are relayed at all,
effectively disabling 959 interop entirely.

Fixed(SM):  Fixed with the 1.11 server release.


-------
SM, 9/29/99, sftpc 1.20:  Data-channel encryption on->off->on bufsize.

If data-channel encryption is on, then turned off, then turned back
on, the internal data buffer's size is not equal to PBSZ.  Since PBSZ
is typically larger than 4k (the size it becomes), this caused a
failed assertion.

Fixed(SM):  Fixed with the 1.21 client release.


------
SM, 4/16/99:  When HCL inetd is used to spawn ftpdw.exe, and SafeTP
is active, ftpdw.exe fails to respond to the LIST command.  This is true
regardless of the client setup (tried: raw ftp.exe, ftp.exe + SafeTP,
sftpc.exe).  This is true regardless of whether sftpd.exe is involved.
This does *not* happen with WFTPD.

Possible reason:  It seems likely that something happens when inetd32.exe
hands-off the accepted socket, such that the subsequent attempt by ftpdw.exe
to create a new listener socket fails.  It is unclear why only this program
should fail to create a new socket, whereas sftpd.exe has no such problem
in a similar situation.

Possible workaround:  Add ftpdw.exe to the excluded executables list
for SafeTP (can we add a key to the registry which contains this info?).

Notes:  This may only happen on Service Pack 0.  We have been unable to
reproduce it on SP4.

Fixed(DB):  Getting the flags to the right setting in the SPI interface,
which is part of the 16-bit thing, has solved this.

-----
SM: sftpc/sftpd sometimes hang on "tests" and/or "ptests".  This is
difficult to reproduce.  (2/14/99)

SM, 2/?/99:  Fixed the above.  This was the infamous 226 bug, caused when
the 150 and 226 from the data transmission would get coalesced into a single
packet, and I forgot to check my internal buffer for unprocessed data.

------
SM: When user fails to send user/pass, and does a LIST, no other file
transfers will work because of SHA1HMAC mismatch.  This is probably
because sftpc increments its file counter before getting confirmation
that sftpd did the same.  (2/14/99)

SM, 2/?/99:  Fixed the above.  Probably just changed the place I increment
the file counter.

------
SM: When sftpc "tests" is run in ascii mode, then run again, it hangs.
(2/14/99)

SM, 2/?/99:  Fixed the above, probably by improving the robustness of
the test code, and switching to binary mode immediately so it just doesn't
happen.  (More of a workaround than a fix, I guess.)

------
SM: sftpc should wait to see the 150 before trying to open a socket,
or at least detect the 500 for, say, file not found, and recover.
(2/14/99)

SM, 4/16/99:  Fixed the above.  This was necessary to keep sftpc running
after HCL's ftpdw.exe reports "533 tempfile.#: Error creating data connection."
when in fact it has failed to open the file it intends to write, on a STOR,
due to permissions settings on the disk.


Bugs in interoperating software
-------------------------------
SM, 4/16/99:  When HCL's ftpdw.exe attempts to create a file, in response to
a STOR command, but fails because of incorrect directory permissions, its
error code is "553 <filename>: Error creating data connection."  This
suggests, erroneously, that there was a problem making the socket call.