On Tue, 31 Oct 2000, Ben Laurie wrote:
> > Yes, your answer is satisfactory.
> > If I understand then I can't use openssl.exe main application for
> > testing my new engine
> > (of course after compilation of openssl with new engine features).
>
> Exactly, and this is wrong and bad. We should fix it.
Enough of the one liners already - go ahead and fix it! Sheesh!
This is not *that* big a deal anyhow.
Anything that could be assumed as far as default values for initialising
an ENGINE can be set by the author of the implementation. Anything that
needs to be pulled out of some kind of environment specific to the ENGINE
(eg. registry or configs relating to the engine-specific "thing") can also
be pulled out by the implementation (and its author). Which leaves us with
the only worthwhile point made in this little exchange so far, namely,
that it should be possible to set various things inside OpenSSL config
files that could be passed into the ENGINEs like a batch file. This *can*
be done, but it depends how you choose syntatically to do it ...
numerically isn't so hot except for "generic" parameter types that can be
defined in OpenSSL once and stay fixed (which is not likely to be the case
often IMHO). On the other hand, doing it string based might be ugly too.
Anyway, some way of batching a series of ENGINE_ctrl() functions by way of
config files could be done. The case that started this deals with some
kind of engine implementation that requires a hostname, username, and
password. That's hardly typical for engines (so far) - and if any such
thing as "default values" for those settings exists on that system, it's
very likely they're stored somewhere in the environment that controls (or
administers) the stuff that engine deals with. So the "requirement" that
they be specified by OpenSSL config files is at best a nice-to-have, but
hardly a showstopper. Your comment that;
> Leaves me with one - if specific engines have to be initialised "by
> hand", then we haven't got much in the way of abstraction, have we? Is
> there a better way? Config files? External programs?
is a little simplisitic, as have been most of the bite(yte)-sized comments
thus far; "to make the engine go" (as you said in another post) requires
whatever the engine's purpose dictates and whatever the environment it
operates in dictates. If defaults can be assumed, then by definition they
can be used inside the engine implementation to obviate the need for
ENGINE_ctrl()ing. Likewise if the defaults *exist* somewhere, they can
equally be pulled out automatically. The only issue is whether this can or
should be driven by generic OpenSSL-based settings rather than
ENGINE-specific settings.
Other possible cases of engines requiring settings are equally likely to
require smart cards, paths, one-time-pad keys, retina-scans, filenames,
network addresses, challenge-response variants, hardware settings, system
settings, system limitations (eg. RAM, disk caching, whatever), UIDs,
PINs, IRQs, DMAs, and probably a tonne of other things. There should be
some way to feed arbitrary name-value pairs into an ENGINE perhaps, maybe
an ENGINE_ctrl_ext() or some such variant, but the lack of that feature
thus far is hardly "not much in the way of abstraction", and likewise the
addition of that feature is not going to make such a general problem go
away.
BTW: Right now, all the existing engine implementations typically work
immediately without any "setup" beyond what they work out for themselves
before, during, or after initialisation.
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
