| Subject: | gssftp client cannot fully handle encoded multiline replies |
| From: | "Daniel Sands" <dnsands@sandia.gov> |
| To: | krb5-bugs@mit.edu |
| Date: | Thu, 13 Sep 2012 16:24:11 -0600 |
If a server reply encodes more than one line within a single encoded
line after secure authentication, the gssftp client will only print the
first line of the reply. So in an example from RFC2228:
631-base64(protect("123-First line\r\nSecond line\r\n 234 A line b"))
631 base64(protect("eginning with numbers\r\n123 The last line\r\n"))
the client will only see (and print out):
123-First line\r\n
eginning with numbers\r\n
This is because its internal line buffer is not equipped to rebuffer
the decoded lines. It naively expects the server to use a 1:1
correlation between each plaintext line and its encoded form.
Unfortunately, not all servers are so nice. It also adds an extra CRLF
to the end of a decoded line, which also breaks the example above.
krb5-appl versions up to and including 1.0.3
line after secure authentication, the gssftp client will only print the
first line of the reply. So in an example from RFC2228:
631-base64(protect("123-First line\r\nSecond line\r\n 234 A line b"))
631 base64(protect("eginning with numbers\r\n123 The last line\r\n"))
the client will only see (and print out):
123-First line\r\n
eginning with numbers\r\n
This is because its internal line buffer is not equipped to rebuffer
the decoded lines. It naively expects the server to use a 1:1
correlation between each plaintext line and its encoded form.
Unfortunately, not all servers are so nice. It also adds an extra CRLF
to the end of a decoded line, which also breaks the example above.
krb5-appl versions up to and including 1.0.3