[issue6706] asyncore's accept() is broken

2010-12-07 Thread Barry A. Warsaw
Barry A. Warsaw added the comment: I do not see this as a security bug so no patch for 2.6 please. (Comment requested from IRC). -- nosy: +barry ___ Python tracker ___

[issue6706] asyncore's accept() is broken

2010-11-01 Thread Giampaolo Rodola'
Giampaolo Rodola' added the comment: Fixed in r86084 (2.7) and r86085 (3.1). -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed type: behavior -> security versions: +Python 2.7, Python 3.1 ___ Python tracker

[issue6706] asyncore's accept() is broken

2010-10-30 Thread Arfrever Frehtes Taifersar Arahesis
Arfrever Frehtes Taifersar Arahesis added the comment: CVE-2010-3492 references this issue. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-3492 -- ___ Python tracker __

[issue6706] asyncore's accept() is broken

2010-10-30 Thread Arfrever Frehtes Taifersar Arahesis
Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue6706] asyncore's accept() is broken

2010-10-04 Thread Giampaolo Rodola'
Giampaolo Rodola' added the comment: Python 3.2 changes committed in r85220. Still have to commit EWOULDBLOCK/ECONNABORTED changes for 3.1 and 2.7. -- ___ Python tracker ___

[issue6706] asyncore's accept() is broken

2010-10-03 Thread Antoine Pitrou
Antoine Pitrou added the comment: I'm not an asyncore expert, but I can't see anything wrong with the patch. -- stage: needs patch -> patch review versions: -Python 2.6, Python 2.7, Python 3.1 ___ Python tracker _

[issue6706] asyncore's accept() is broken

2010-10-02 Thread Giampaolo Rodola'
Giampaolo Rodola' added the comment: Patch in attachment adds a handled_accepted() method to dispatcher class as recommended by Antoine. -- Added file: http://bugs.python.org/file19104/accept.patch ___ Python tracker

[issue6706] asyncore's accept() is broken

2010-09-25 Thread Giampaolo Rodola'
Giampaolo Rodola' added the comment: > As long as these errors are reasonably explainable. > If a strange error only occurs when running nmap on an OS X server, > then it might be useful for the user to know that the OS X server > isn't able to service all connections properly due to a bug in

[issue6706] asyncore's accept() is broken

2010-09-25 Thread Antoine Pitrou
Antoine Pitrou added the comment: > The point of frameworks such as asyncore and twisted is to hide all > system-specific errors as much as possible and provide a portable > interface across all platforms. As long as these errors are reasonably explainable. If a strange error only occurs when r

[issue6706] asyncore's accept() is broken

2010-09-25 Thread Giampaolo Rodola'
Giampaolo Rodola' added the comment: > I'm not convinced hiding operating system bugs is a good idea. Do you propose to let the error raise then? The point of frameworks such as asyncore and twisted is to hide all system-specific errors as much as possible and provide a portable interface acr

[issue6706] asyncore's accept() is broken

2010-09-25 Thread Antoine Pitrou
Antoine Pitrou added the comment: > EAGAIN can be raised too. I never experienced this error condition > myself in pyftpdlib >From the accept() man page: EAGAIN or EWOULDBLOCK The socket is marked nonblocking and no connections are present to be accepted. POSI

[issue6706] asyncore's accept() is broken

2010-09-25 Thread Giampaolo Rodola'
Giampaolo Rodola' added the comment: Patch in attachment makes accept() return None in case no connection takes place and modifies the doc to make this very clear, also providing an example on how an asyncore-based server should be properly set-up . -- versions: +Python 2.6 Added file

[issue6706] asyncore's accept() is broken

2010-09-24 Thread Giampaolo Rodola'
Giampaolo Rodola' added the comment: Here's a rewriting attempt (not tested). Now that I look at it I must say it's quite ugly, so I don't think we should follow this road. An alternative I see is to return None in case of errors occurring on accept() and make this very clear in doc. Other th

[issue6706] asyncore's accept() is broken

2010-09-23 Thread Dave Malcolm
Dave Malcolm added the comment: giampaolo: did you ever rewrite the patch? For reference to other users: http://code.google.com/p/pyftpdlib/source/browse/trunk/pyftpdlib/ftpserver.py Note the complexity of the two handle_accept implementations in that file; both of them begin: try:

[issue6706] asyncore's accept() is broken

2010-09-13 Thread Santoso Wijaya
Changes by Santoso Wijaya : -- nosy: +santa4nt ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue6706] asyncore's accept() is broken

2010-09-13 Thread jan matejek
Changes by jan matejek : -- nosy: +matejcik ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue6706] asyncore's accept() is broken

2010-08-03 Thread Giampaolo Rodola'
Giampaolo Rodola' added the comment: Shame on me, it seems I totally forgot to attach the patch. Unfortunately the patch went lost but I'm going to try to rewrite it. As for tests, ECONN and EAGAIN error conditions are hardly reproducible unless you're using nmap. I'm assigning this to me for n

[issue6706] asyncore's accept() is broken

2010-08-01 Thread Mark Lawrence
Mark Lawrence added the comment: @Giampaolo it looks as if you meant to attach a patch but didn't! :) If you do attach one could you also supply a modified unit test file with it, thanks. -- nosy: +BreamoreBoy stage: -> needs patch type: -> behavior versions: +Python 3.1, Python 3.2

[issue6706] asyncore's accept() is broken

2009-08-14 Thread Giampaolo Rodola'
New submission from Giampaolo Rodola' : An old bad design choice in asyncore is how it forces the user to override handle_accept() and then call self.accept() to obtain a socket pair. def handle_accept(self): conn, addr = self.accept() The documentation itself shows the code above