On January 3, 2006 11:27 am, Kurt Roeckx wrote: > On Mon, Jan 02, 2006 at 06:57:59PM +0100, Andy Polyakov wrote: > > So let's make it a vote. > > > > 1. Should there be or not option for built-in engine in shared > > library context, or should all engines without exclusion be available > > as loadable modules? > > > > My vote is "there should be an option for built-in engines even in > > shared context."
No objections. FWIW, the casual justification for the engines that are currently "built-in" was that they're needed. Ie. the "dynamic" engine has to be there otherwise you can't load anything else. The cryptodev engine is built-in (unless you define OPENSSL_NO_STATIC_ENGINE, apparently) because on *BSD it should probably just be used by default. Not sure. The GMP engine was and is curiosity-value, so it's built-in-ness should be taken with a grain of salt. If you can find a cleaner way to parameterise which engines are(n't) built and which ones are(n't) built-in, go ahead. > > 2. If consensus is "yes for the option," which engines should be > > available as builtins? Popular ones? Small ones? Self-contained ones? > > Those addressing specific CPU capabilities directly? Those packager > > wishes to favor? Those we decide on per-engine basis? Part of the thing is to keep the libcrypto.[so|a] bloat to a minimum. One day in a bright future, we'd also rip the default software implementations out into modules that could be selectively loaded. In that case, the default "NULL" implementation would cease to exist. There's also the fact that the vendor-specific engines are of use to exactly noone except owners of corresponding hardware. So it is always possible that vendors might want to support their products and drivers directly by providing source or binaries for loadable engines rather than openssl.org doing so (and packagers potentially patching existing engines out of their builds and/or other engines in to their builds). Whatever. I think the emphasis for openssl should remain on keeping support code for proprietary hardware out of our core binaries/libs to ensure they're only part of the run-time footprint if enabled/used. So even for the engines we ship, I think it would make sense to keep them external if (a) they support proprietary hardware, and (b) building of dynamic engines isn't disabled. > > My vote is "per-engine basis based primarily on self-contained > > criteria [i.e. when engine can operate without additional [user-land] > > component provided by 3rd party, where 1st and 2nd parties are OS > > provider and OpenSSL]." A. > > I think we first need to start with why do we have loadable > modules. I can see a few reasons for this: > - 3rd party engines can be added and loaded. And I think this is > the most important one. And this would even be useful in case > the library is build/linked staticly. Yes. Most of the engines can lie dormant on the hard-disk without bothering the 99.9% of users that don't have the corresponding hardware. > - Reduces the size of the library, which might for instance be > important for embedded applications. But if size is important > they should try and disable things they don't need in the first > place. Breaking out engines is one way of attacking this problem. As you touched on though, the major part of that problem comes from the default software implementations themselves. To truly modularise things, you'd need to cull the algo-specific APIs and force everything through EVP. Only then can you start to think about genuinely disabling bits and pieces (currently, you can try to disable certain algorithms if you like, but you'll break linking if apps were depending on those APIs - in theory this shouldn't be the case if the app was going to obtain those APIs through the use of a hardware engine and didn't need the built in software). > I think that having build in eniges in a shared library can make > perfect sense. I currently don't see a good reason why all > those modules are external while they could be internal. Most of them should be external though. Very few openssl users have a cryptoswift card, or an atalla card, or an ncipher card, or ... Even fewer have and use more than one kind. Building the engines internally would put all of them into everyone's binaries and run-time overhead for no good reason at all. > I wondering what you mean with "3rd party". For instance, there > now seems to be a gmp engine (which is disabled by default). > It would seem that your definition would mean it required > something 3rd party. I don't see why that would be different > from the others. Or are you talking about something else? The GMP engine is a glue to the GMP library to get it to perform RSA operations using the GMP bignum implementation. It's not optimised favourably at all, but was used casually to compare GMP and OpenSSL exponentiation speeds on different architectures. It also serves as a development tool for anyone (eg. me) trying to work on engine code without needing to use any cryptographic hardware. > The gmp engine seems to be disabled, yet it gets build as a > shared module, but doesn't have any code in it. I don't think > it's useful that a module gets created for that, since I can't do > a thing with it. AFAICR, it should only be built if you explicitly configure it (it'll require GMP headers and libs anyway). It's not intended for production use and I would be quite surprised if any packagers shipped it. You are right however about the empty module - this is the case for any other engine that is "disabled". The problem is that the build system isn't aware of what modules to build and not build so goes ahead and builds them all anyway - the preprocessor causes disabled modules to compile empty. I'm not sure what the best fix to this is, but it certainly involves make, probably perl, and quite a bit of digging. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ Self-interest and materialistic desire are parts of who we are, but not all. To base a social and economic system on these traits is dangerously fundamentalist. -- Joel Bakan ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
