Hi there, On Thu, 18 Jul 2002, Frederic DONNAT wrote:
> I've sent the first release of our engine for 0.9.6x more than 6 months ago. > Later on, I've sent a release for the 0.9.7dev long before the 0.9.7beta versions. This has been an ongoing problem, for which we apologise. It's the main reason why RT exists - the submission of changes, new code, feature requests, bug reports, [ad infinitum] was outstripping our ability to keep track of things without most of it slipping through the cracks. W.r.t. ENGINE submissions - I have had innumerable mails from various hardware vendors who will, are, or have been developing implementations. For many of those, I have had multiple emails on various subjects from development problems, licensing/copyright issues, how to submit, openssl release timelines, blah blah blah. In the end, it's extremely difficult to know who has sent what, when, and how, and moreover what is currently waiting on action from me and what isn't. I know Richard has had his fair share of the same. So before dealing specifically with your mail, let me clarify something. Richard and I are currently working on an improved scheme for the ENGINE library code, with the hopes of having it ready in time for 0.9.8. In this scheme, all ENGINEs would be built as stand-alone shared-libraries - so whether the source is bundled with openssl or not has less bearing on a vendor's ability to support openssl on their clients' machines. The idea is that when an application (or admin/user/configuration) requests the use of engine "foo", openssl will check its internal list (as is currently the case), but when it finds no such ENGINE will take the additional step of probing a compiled-in installation directory such as $OPENSSLDIR/engines/ (though overridable by an environment variable) for the presence of a shared-library implementing "foo" (ie. using some canonical conversions, eg. libengine_foo.so, eng_foo.dll, etc). Right now we have numerous ENGINE implementations compiling in every openssl version on every platform and imposing a significant footprint on *every* openssl image. All this despite the fact that 99% of openssl users don't have any of these devices, most of the remaining 1% have at most one of these devices, and most of the supported devices themselves will never operate on more than 1 or 2 of the support platforms - despite the ENGINE support being compiled for every platform. In short, it's bloating out. Moreover, the speed at which new ENGINEs are coming in is increasing, to the point that we will have no choice soon but to unbundle them in *some* way. back to your post ... > We've tested in Linux (2.4.x), Windows (2k) and Solaris (8) platforms. > If it is mandatory to test in several platforms, please send me a list. > I'll be happy to do it :-) Until the late-binding support I mentioned is mature, your code would need to compile smoothly on every platform support by openssl for it to be included. Whilst that can be difficult to achieve in theory, getting compilation perfect (no warnings, and no ugly hacks to stop warnings) on a number of different platforms is a good start - anything else that remains will usually get noticed by someone else, particular during beta testing. You'd also need to give permission for the source to be covered by the openssl license. > On the other hand, I've proposed a patch for mod_ssl concerning the > random in crypto cards. Yes I saw that, and I believe Richard was looking at the equivalent points you mentioned in one or two openssl utilities (s_client and s_server IIRC)? > > Could you please open a ticket on the openssl request-tracker for this? > > http://www.openssl.org/support/rt2.html > > That's the appropriate place for this sort of change request. > > ok. I was not aware of the RT 'til now. That's why I sent the code in > the mailing list. OK - once it's in RT it won't get "lost" in list traffic. The only way for it to get completely passed by is for one of us to maliciously delete it, in which case you'll know who to chase and abuse :-) Note also that once it's on RT, anyone can look at the code and provide some peer-review, regardless of whether they're on the development team. > Sorry for any inconvinience but I think i'm not pushing too hard, am I? I don't think so, and again I apologise if you've found us a little unresponsive but I hope the above comments explain why, at least w.r.t. ENGINE implementations, things have been a little messy until RT came along. We have been steadily approaching a situation where we have to change the way these implementations are bundled, compiled, and loaded. That combined with the number of mails from various parties we get about ENGINE stuff makes it very difficult to keep track of everything and respond to all mail that deserves it. Cheers, Geoff PS: Now I'm going to have to bookmark this post when it hits the archives so I can use it as a canned response ... :-) -- Geoff Thorpe [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
