And how, pray tell, should OpenSSL know the threading model the application uses?
Unless I'm missing something, it strikes me as perfectly reasonable for OpenSSL to require a "reasonable" threading API to implement SSL data integrity, and for the application to provide an implementation that wraps the threading model it uses within that API. -----Original Message----- From: [email protected] on behalf of Michael Sweet via RT Sent: Thu 6/24/2010 1:19 PM Cc: [email protected] Subject: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw An emerging issue with CUPS and other applications that use it has identified a critical design flaw in how OpenSSL supports multithreading. Specifically, a multi-threaded application or library that uses OpenSSL must provide its own threading functions for OpenSSL to use. When both an application and a library (say, Firefox and libcups) both initialize and register their own threading functions, bad things happen and the application can crash. Pushing the responsibility of making OpenSSL thread-safe on the application is a bad design choice and needs to be fixed ASAP to allow cross-platform, multi-threaded applications to be developed safely. ________________________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
