> HI! > > Thanks again for highlighting those issues. What would be the > best way for > the application using those pluggins to avoid this issue of > SSL_library_init()?
There are really two good ways that ensure that all problems are resolved. Other ways just deal with problems as they crop up and can never ensure there are no more problems (because you never really know what a future plug-in might do when you write a plug-in so you can never be sure it won't break something you rely on). One way is to design into the application a specification for accessing SSL and cryptographic routines. This specification would generally put one "master" module (or the application itself) in charge of initializing the library and managing all process-level library parameters. Thus the program 'wraps' OpenSSL. This may mean just replacing the startup and shutdown routines and forbidding changes to process-level state. It could mean wrapping a significant part of the library's API. Another way is to have each plugin use its own copy of OpenSSL with its own everything. This guarantees you start up and shut down your own build of OpenSSL and get exactly the version you want. (For some libraries, you have to change the symbols so the names don't conflict.) The first way has the disadvantage that plugins cannot use differing versions of OpenSSL and must settle on process-level settings that might not make any plugin perfectly happy. It also requires someone to actually create the rules and implement them and all plugins using the common library must follow the specification. The second way has the disadvantage that it's ugly and wastes resource, but it does allow each plugin to own its own process-level OpenSSL. Each plugin can get the version of OpenSSL it wants. Where it's too late for the first way, what is generally resorted to is fixing problems that crop up. Where possible, libraries can be redesigned to minimize process-level state. What happens if two plugins need different versions of OpenSSL? Generally, a plug-in library is strictly limited in what it is permitted to do and going outside that scope can cause weird instabilities. Consider a plugin that always worked fine because it only added 64-bit ciphers, then another plugin adds 256-bit ciphers, and the first plugin starts getting larger ciphers because they are preferred but then copies a key into a 64-bit buffer. Oopsie. Which plug-in is at fault? Plug-ins share all kinds of things, and this type of sharing requires agreement and cooperation. You cannot have all the plug-ins use the same library, where that library has process-level state, and just hope it will all work out somehow. Designing programs with plugin modules is not easy. It takes a *lot* of thinking from the beginning to keep it sensible and be relatively sure new modules won't break old ones. For some strange reason, this thread is making me feel old. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
