That's pretty much what I've done, although overloading no-hw. I'll change this to no-engine and send on some pacthes. I've totally ifdef'd out the engine related code in RSA_new_method, etc., although these functions are of course still passed an ENGINE* which gets ignored. I wasn't sure about ifdef'ing out the ENGINE* from the RSA and other structures. This would make it complete, but the structure would be different between engine and no-engine builds. I doubt this is a problem, but what do you think.
Steven -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Geoff Thorpe Sent: Wednesday, 28 August 2002 12:57 AM To: [EMAIL PROTECTED] Subject: Re: 0.9.7: no-hw Hi there, On Wed, 28 Aug 2002, Steven Reddie wrote: > Specifying "no-hw" to config/Configure in 0.9.7 defines OPENSSL_NO_HW but > builds the engine directory. Parts of those files are ifdef'd out but there > is still a fair amount built. Also, "#ifndef OPENSSL_NO_HW" isn't used much > throughout the code, so engine.h is included even with no-hw, and the > openssl utility still contains the engine command. > > This behaviour is different to the other no- options, such as no-idea, where > specifying the option results in the relevant directory not being built, > inclusion of the relevant header file being disabled (and trying to include > it causes an error), calls to the relevant functions being disabled, and the > relevant command being removed from the openssl utility. > > If you'll accept them I can send in some patches to properly disable the > engine. In keeping with the other no- options, "no-engine" may be a better > choice due to the name of the relevant directory. Please let me know if > you'd like a patch as I could do with this going into a 0.9.7 snapshot soon > to make my porting to Windows CE easier and cleaner. OPENSSL_NO_HW is what one would expect from "no-hw" but it's less than perfectly clear whether that's the same as would be wanted from "no-engine". To truly compile without engine code (or headers) would be a bigger task - eg. the ENGINE glue into RSA_new_method(), RSA_free() (and the DSA, DH, RAND, EVP_CIPHER, and EVP_DIGEST equivalents) would need to be pre-compiled out, ie. using a NULL'd replacement of the ENGINE table-lookups that are currently used. Anyhow, I'm personally not sure that the "hw" concept is all that relevant any more - the possible implementations are not restricted to "hardware" at all, eg. the "dynamic" engine, or a software ENGINE implementing new ciphers. Right now I'm working (with Richard) on ways to have all ENGINE implementations built externally as shared-libs that can be transparently and dynamically loaded/initialised when required - in this scheme it will be even less obvious what it means to not have any engines "compiled in". I think the more important configuration option is the one you're looking for: "no-engine" which would simply prune out the entire ENGINE abstraction completely. However, that requires you to figure out how to tie up the loose-ends the lack of ENGINE would leave you with :-) If you want to work on a "no-engine" patch, please go ahead and let us know how you get on - I would try and keep it as orthogonal to what exists in the source as possible, eg. by using a OPENSSL_NO_ENGINE directive that literally makes the entire ENGINE abstraction "go away" as with the other "no-***" options. Whether the various fine-grained directives for removing particular (or all) ENGINE modules will survive in their current forms remains to be seen, so I'd recommend trying to work independantly of those if possible. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
