Skip to content

Conversation

@danifus
Copy link

@danifus danifus commented Mar 6, 2020

No description provided.

@coveralls
Copy link

Coverage Status

Coverage remained the same at ?% when pulling f1a3b6e on danifus:b315 into 1122c7d on giampaolo:master.

@giampaolo
Copy link
Owner

Please explain =)

@danifus
Copy link
Author

danifus commented Mar 6, 2020

I was having a look through the issues and found #315 which was a bit old and you had asked for a python test demonstrating the issue and thought I would have a go.

The summary is:

  • Send b"AUTH TLS\r\nNOOP\r\n" in a single client.sock.sendall() call.
  • AUTH TLS\r\nNOOP\r\n is now in the server buffer
  • found_terminator() returns AUTH TLS, NOOP is still in the buffer.
  • tls socket is established
  • server returns 234 AUTH TLS successful.
  • found_terminator() returns NOOP
  • server returns 200 I successfully done nothin'. over the tls connection.

8b2d2ec#diff-3f8de7cee164531b3e8fa45af77f4626R355-R385 sets this up and tests that nothing is returned after the AUTH response (provided that is the way you want to go, as opposed to raising an error).

@danifus
Copy link
Author

danifus commented Mar 6, 2020

The fix just clears out asynchat inbound buffer in ftp_AUTH if a secure connection is being established. Not sure that is the proper fix and happy for you to choose a different approach

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants