httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kent E Yoder <yod...@us.ibm.com>
Subject Re: [PATCH] OpenSSL dynamic engines under 2.0.48
Date Tue, 17 Feb 2004 22:33:33 GMT
Hi Geoff,

Geoff Thorpe <geoff@geoffthorpe.net> wrote on 17/02/2004 03:46:21 PM:

> As another example of where this can go, using HSM keys (or smart-cards, 

> usb-keys, etc) via custom control commands could be entirely supported 
in 
> this way - without needing to recompile openssl or apache. (An engine 
can 
> expose control commands to identify and load private keys, and the 
> private key file loaded by Apache could instead contain stub data 
> interpreted by the engine implementation to refer to the HSM keys). It's 

> a bit of an ugly hack, but it works. The point being; the only limit on 

  I think ours is winning the "hack" contest at this point. :-)  Yours 
would be
considerably more flexible.  Has the control command patch been explicitly 

rejected in the past?

> what you can do from the configuration file is what the engine 
> implementation exposes in the way of control commands - neither apache 
> nor openssl need to be adjusted for each feature.

  True, and this is mainly what we were shooting for..  Dynamic engines 
can
be compiled outside the openssl source, so there wouldn't need to be a 
recompile of either openssl (since the openssl project isn't accepting
static engines any longer) or apache (once a dynamic engine patch is
accepted).  All you'd need to do is compile the engine.
 
> Note also that as of openssl 0.9.8, platforms that have DSO_METHOD 
support 
> implemented will be able automatically load shared-library engines 
> without any of this. ENGINE_by_id("foo") will attempt to automatically 
> load and bind libfoo.so (dlfcn), "foo.dll" (win32), [etc] from a 
specific 
> sub-directory of the openssl installation if the "foo" ENGINE doesn't 
> already exist. So if Apache doesn't want to go the route of generalised 
> control commands, they could wait until 0.9.8 is out and then this basic 

> use-case will be available transparently, without any change to what's 
> there now.

  Would putting our patch inside #ifdef OPENSSL_VERSION < 0x00908000 be 
more acceptable? (For either patch)...

Kent
 
> Cheers,
> Geoff
> 
> -- 
> Geoff Thorpe
> geoff@geoffthorpe.net
> http://www.geoffthorpe.net/
> 


Mime
View raw message