No more plug-ins?

David Champion dgc@uchicago.edu
Fri Aug 9 21:14:02 2002


* On 2002.08.09, in <87vg6joo4g.fsf@alberti.gnupg.de>,
*	"Werner Koch" <wk@gnupg.org> wrote:
> On Fri, 9 Aug 2002 09:03:33 -0500, David Champion said:
> 
> >     1. IDEA support. (I won't mean to get into arguments about this. I
> 
> It is still there as long as the system supports dlopen or is Windows.
> As an alternative you may simply copy idea.c into the cipher/
> directory and it will be statically linked.

Ah, okay -- didn't realize this.


> >     2. User-selectable RNGs. We run mostly on Solaris. Some machines
> >     have a real /dev/random, and use rndlinux. Others do not and can
> >     not, so we use rndegd or rndunix, depending on circumstances. With
> 
> I understand.  Is it really a problem?  We could link all in and have
> an option to enable them - shall I consider this?

I'd appreciate that. It's useful to be able to use the same binary
on all systems. It's convenient for system management, but it's also
nice for checking integrity of the executable. (You don't have 2 or 3
different, legitimate MD5 hashes for /opt/bin/gpg, for example.)

Maybe the default (if no RNG is selected by options) should be to use
the rndlinux driver since it's the most common interface, but allow it
to be overridden with "rng-options" or something.


> I know that you tweaked a lot of things to make the plugins work on
> Solaris but problems with the dynamic linking are still a large
> percentage of build problems.  By removing this I hope to make it

Yes, I've noticed -- but the infrastructure is there to make it work,
if only people will contribute the right options and they'll enter
the code. It also seems possible to create a "generic" case for DLL
builds where some environment variable(s) will set the compile options.
This doesn't solve the immediate problem of builds failing, but it
does provide a way for people to work around it via mailing list ideas
without having to understand shell scripts, autoconf, etc.


> easier for most people.  And there is of course a security issue due
> to the extra code required for loading it, and the code has never been
> very pretty.

Yes, that's a fair point. I don't worry about it much, myself, because
it provides a useful function. But if it's no longer necessary to
provide that utility, it's more of a hazard.

Thanks!

-- 
 -D.			Fresh fruit enriches everyone.  Takes the thirst
 Sun Project, APC/UCCO	out of everyday time.  A pure whiff of oxygen,
 University of Chicago	painting over a monochrome world in primary colors.
 dgc@uchicago.edu	We all know that.  It's why everyone loves fruit.