On June 16, 2004 07:48 pm, Richard Levitte - VMS Whacker wrote: > geoff> Indeed. However one problem with merging > geoff> ENGINE_get_static_state() to 0.9.6-stable is that it requires a > geoff> new exported API symbol in openssl. > > Well, I don't see that as a problem, since we don't have support for > dynamic engines *at* *all* in 0.9.6... I assume you really meant to > say 0.9.7-stable, and I see that as less of a problem on a general > level, since there's no newer OpenSSL version than that.
Well there will be, and I think the issue is that we have got to a point where we speak of openssl variants as being 0.9.6, 0.9.7, etc. Changes within a stable branch that affect interoperability, or worse still, configuration of dependant code, can be minefields. > geoff> Specifically, building dynamic engines uses an engine.h macro > geoff> that calls this (newly introduced) function, so we'd have to > geoff> bump the magic version stuff to prevent weird linker freakouts > geoff> and give more meaningful errors when the loading instance > geoff> doesn't have that new function. I'm not against merging it, as > geoff> such, but wanted to raise the issue. > > We *could* check if the magic version is the former level, and then > not check at all (i.e. have some backward compatibility cruft), but if > it's the newer level, we call ENGINE_get_static_state(). Of course, > that means we need to keep two variants of struct st_dynamic_fns and > do a bit of casting magic... I'm not sure what to say, I don't really have the variety of architectures to adequately test these combinations out. And given how complex this could get, it certainly will need decent testing to avoid creating a cure worse than the problem. I still wonder whether this can't be better settled in the version check itself? > geoff> The alternative is to make the check draconian so at least the > geoff> bug disappears - ie. if the error callbacks in the engine lib's > geoff> context don't match the callbacks in the crypto lib's context, > geoff> don't try to alter them (it'll fail anyway), just refuse the > geoff> load. This would probably break dynamic engine capability on > geoff> one or two strange platforms I guess, but then again, how could > geoff> they have been working in this form anyway? > > True, they probably worked better before I use > ERR_get_implementation() to check against fns->err_fns. At the time I > made that change, I didn't test on VMS for some reason, or I would > have caught it at that time... Oh well, this sort of architecture-picky stuff is a nightmare. But just out of interest - what would happen if we ensured ERR_get_implementation() returned NULL if no callbacks were registered instead of automatically setting them to defaults? Of course the other ERR functionality would need to continue to have the "set on first use" behaviour, but the ERR_get_implementation() API itself - could that survive being altered to be read-only? If so, wouldn't that help? I know I know, questions questions questions. I've got a cold, that's all I can manage for now. :-) Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
