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]
