Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
>   Things in cryptosrc, i.e. ISAKMP implementations [pluto (aka dwightd) or
> racoond] that one might to distribute in binary form and permit people who
> can run RSA to just drop in the library. 
>   I agree that the ./configure is a problem, but i'm think it can be solved.

Right, sure, it's fairly obvious why you'd want to have a standard API
and/or a standard set of functions in a known library.


In a nutshell, all you suggested was having a shared library that may
contain just some stubs that abort (or whatever).  I don't see how
that helps solve any problem in any significant way.  Please clue me
in...  8-)

possibilities that i've considered as the problem being solved, which
_really_ don't make sense to me:

* building such programs for others to run with the 'real' library.
if you're doing it to allow such programs to be built, then you need a
lot more than the library.  e.g. headers.  also, this doesn't leave me
with warm fuzzies.  (good luck testing what you've built!)

* running such programs on a system with the fake library.  In
general, it's not desirable to have a core dump because a stub wasn't
implemented.  (if this is all the reliability you want, just let the
linker's lazy binding go boom when the symbols are used!)

If the intent is to both build and run the programs on a system with
'real' implementations of the functions that are stubbed in the
library, what use is the library of stubs?  8-)

Are you after a different problem, or do i just misunderstand what
you're getting at...


If you want to do something close to this, i think what you really
need is a way for a program to query the state of what the library
provides, so that it can find out what algorithms are supported and
dynamically modify its operation to do the right thing.  However,
you've signalled no intention of doing any such thing, or of modifying
the applications to do the right thing in the presence of such a
mechanism, so it doesn't sound like what you intended.

I'd actually think that a better alternative to that (if a 'standard'
API to do things like this doesn't already exist) would be having the
application try to dlopen() modules which contain the crypto
algorithms it wants to use.  That way:

	* you don't need the Big Honkin' Library, or any of the costs
	  or annoyances associated with it.

	* you get some additional flexibility and easier future
	  expansion.

	* the issues of figuring out whether or not you have a certain
	  crypto API present are well understood, and portable to
	  other systems.

Note that you're already assuming a shared library, so you're already
presuming dynamic linking capability...



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.