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
Message-ID: <1347575051.28817.18.camel@s952894.srn.sandia.gov>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: list
Sender: krb5-bugs-incoming-bounces@PCH.mit.edu
Errors-To: krb5-bugs-incoming-bounces@PCH.mit.edu
Content-Length: 812

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