GnuPG 1.1.90 released

[David Shaw]

On Sat, Jul 27, 2002 at 09:21:34PM +0000, Brian M. Carlson wrote:
> > > So for what do you all use the extension mechanism right now?  And why
> > > should we not compile everything in and have a mechanism to throw more
> > > modules into the build process?
> 
> Are you planning to have an installer like Debian does for realplayer
> and flashplayer? I think that would bloat the package and complicate it
> more than keeping the dynamic loading code in.

I don't see how you got from the original statement to this.  One
binary.  No installer.  No bloat.  If you drop, say, idea.c in the
gnupg directory when you build, it'll pick it up and include it.

> > I am also in favor of ditching the extensions and compiling everything
> > (cipher and random modules both) directly in.  It simplifies things in
> > many places.
> 
> I am opposed to this idea. Many people (especially Windows users) want
> the stock gpg binary, which they can add on to with the idea module.
> GnuPG still does not ship with SHA2 (at least not on my system, and I
> use the CVS version). Nor does it ship with MD2 (I attempted this
> once) or HAVAL-5-160. These would all be useful extensions that someone
> could dynamically load. However, it would be much less useful to try to
> work on, say, an MD2 extension, if I had to recompile gpg each time.

Why on earth would you recompile everything?  I work on GnuPG nearly
every day and I certainly don't recompile it each time.  I recompile
the files that I'm working on, which is exactly the same amount of
compiling that you'd be doing with a built-in cipher.

> There is a *big* difference between compiling one module and compiling
> the entire gpg binary. Have you seen the difficulty some people have had
> getting gpg compiled on the plethora of platforms that people use?

If they couldn't compile GnuPG in the first place, then surely they
are no worse off if they.... still can't compile it.

> > > Furthermore I don't think it does really make sense to use
> > > --enable-static-rnd=none to allow switching between different random
> > > modules.  This used to be a nice feature for debugging, but given that
> > > a couple of other applications also make use of EGD today, I don't
> > > think this is required at all.
> 
> I think it should be the user's choice what PRNG he or she uses. There
> is an ITP (maybe it was an RFP) in the Debian BTS for EGD. The
> GNU/Linux, GNU/FreeBSD, and GNU/NetBSD have random devices already, so
> this is somewhat redundant.

It is still the user's choice when random number module he uses.
Rather than dynamically loading it at runtime, it would be compiled
in.  How often do you change your random number generator?

> > > Adding new ciphers or hash algorithms does not make much sense unless
> > > they are officially supported by OpenPGP and have a number assigned.
> > > It is probably easier to grab a new GnuPG version in that case.
> 
> Are we planning on ditching TIGER192? Or are we only compiling it for
> platforms that have 64-bit support (not everyone has gcc, remember). And
> TIGER192 still does not have an OID assigned.

Until it has an OID, it is more or less an experimental toy.

Let's summarize this before it spirals out of control.  The random
module issue isn't really an issue since there is no real need for
regular people to change their random modules on a regular basis.

There is no hindrance for someone adding ciphers and hashes to GnuPG
since 'make' handles the build without rebuilding everything if only
one file has changed.

It really all boils down to IDEA.  If a user is not capable or willing
to build GnuPG themselves, and so uses a binary distribution, that's
just fine.  Since they were already willing to use a binary
distribution they didn't compile themselves, then they can just as
easily use a binary distribution with IDEA that they didn't compile
themselves.

So, three cases:

1) Users who can't compile at all.

   No change from now.  They get a binary distribution, with or
   without IDEA depending on their desires.

2) Users who can compile.

   No change from now.

3) Users who can compile enough to compile IDEA, but couldn't handle
   compiling all of GnuPG.

   This is the only case that is really different, and since they are
   already using a binary distribution of GnuPG, they might as well
   just get a binary distribution with IDEA.

I just don't see the minor frill of #3 outweighing the serious extra
complexity (and complexity in a security program is not what you want)
that dynamic loading brings.

David

-- 
   David Shaw  |  dshaw at jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson