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

3 participants