* Richard Levitte via RT ([EMAIL PROTECTED]) wrote: > > OK, I looked at the no-engine patch again, and really saw no harm in it, so it's >committed, and will be part of all release from 0.9.7a and on (as well as the current >0.9.7 and main snapshots). > > This ticket is now resolved.
Erm, I think there's a fundemantal problem with this. I understand the desire to build a version of openssl such that it doesn't include the engine footprint, nor its execution overheads. I could possibly accept that binary incompatibilities could be accepted between applications and/or libraries on the basis that you'd only bother doing this stuff if you were *determined* to have ENGINE surgically removed. Ie. we already state that for binary compatibility, 0.9.x !~ 0.9.(x+1), however we could perhaps also tolerate the situation where for a fixed 'x', 0.9.x-engine !~ 0.9.x-noengine. What I can't accept is that the precompiler symbol used to *build* a non-engine version of openssl is used in the exported header files in a way that alters the definitions of API structures. Ie. if you build a non-engine version of openssl, your application code will silently compile and link whether you defined OPENSSL_NO_ENGINE or not (and/or whether you define OPENSSL_NO_ENGINE before or after including the relevant headers) - *but* the resulting object code will use conflicting descriptions of data structures unless the app's author got everything correct. As for how this could impact distributions using system-wide versions of openssl as shared-libraries is obvious and so in this state, the nonengine approach would be considered untouchable even by those who want it. I know, the practise of system-wide shared libraries is not considered wise for openssl - but if distributors are vigilant about only using version-specific linking then IMHO that's OK, this type of "configuration option" threatens to break that. IMHO the better way to have handled this would have been to opaquely define the ENGINE type in crypto.h (this could also reduce some header dependencies on engine.h BTW) so that all the existing structures can remain as-is. Ie. if RSA has an ENGINE* member, leave it there - but disable all use of the ENGINE API in the RSA implementation (and the trick of #error in engine.h is fine). This way, whether you get ENGINE functionality, footprint, and overheads at run-time depends *only* on whether openssl was built with it or without it. It won't be essential for applications to bother defining OPENSSL_NO_ENGINE - though if they do it will correctly stop them accidently including engine.h (and thus prevent linker failures if they accidently try to use ENGINE functionality). The point is, compatibility between application object code and openssl (be it static or dynamic) won't be volatile. FYI: the easiest example to see the problem is EVP_MD_CTX in crypto/evp/evp.h:280 - the structure definition is incompatible if OPENSSL_NO_ENGINE is defined (or undefined, as the case may be). IMHO OPENSSL_NO_ENGINE shouldn't change structure definitions, it should change only the building of openssl implementation code. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.openssl.org/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
