A quick skim of this patch seems to indicate that it makes sense, though the litmus test will be to get some kind of regression coverage. Eg. do connections get left dangling in any common scenarios?
BTW, I note that the patch is against 0.9.8b, that's ... umm ... *old*. Could you please regen your patch against either 0.9.8h or a recent snapshot of the HEAD? Also, if you can let us know what test coverage you already have for this, that would help, and we could likewise ask here on the list for some others to verify that this doesn't tickle any other issues. (I'm thinking apache2 plus various https clients, stunnel, postfix-TLS, etc.) My vague concern here is that connection teardown is something browsers and bungled SSL/TLS implementations have managed to get wrong in various colourful ways in the past, so if your fix breaks interoperability in any of these scenarios, we'd need to rethink (or at least, we'd need to make the fixes conditional on the presence or absence of the appropriate run-time flags that turn on/off workarounds, etc). Thanks, Geoff On Tuesday 03 June 2008 09:01:34 Thor Lancelot Simon wrote: > As has been discussed several times in (at least) the past two years, > there's a serious problem with SSL_shutdown() for nonblocking connections: > it discards the underlying BIO's WANT_READ/WANT_WRITE information so that > the calling application cannot know in which direction it must wait for > I/O; so the choices are to spin (by waiting for I/O in either direction), > to use a timeout (not always practical in an event-driven application) and > re-check, or to switch to blocking mode -- again not really a good option. > Heuristics can reduce the chance of spinning or missing an I/O ready event > to a very small chance, but they cannot eliminate it. This patch makes the > problem go away. > > The attached patch was sent to openssl-dev by Darryl Miles two years > ago. I strongly believe it implements correct behavior and is not > really a change to the API -- it just uses WANT_READ/WANT_WRITE > appropriately rather than returning SSL_ERROR_SYSCALL when it should > not. This is *not* the patch offered by another frustrated nbio user > last year which added a new error code to the library -- it uses the > existing ones as it should. > > Would it be possible to get some feedback from the OpenSSL team? I > feel quite strongly this patch is needed and am sorely tempted to just > check it in to the copy of OpenSSL in NetBSD's tree, but would prefer > to not do so if there's any chance I can get OpenSSL developer comment > on the patch or the underlying problem, to avoid a local patch that > might not then be needed. > > Darryl's description of the patch is at > http://marc.info/?l=openssl-dev&m=115153998821797&w=2 but one should > note it addresses other problems with the API that may be more serious > in practice than the one he originally observed (e.g. the blocking/ > spinning described above). > > Thor ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
