GnuPG 1.1.90 released

David Shaw dshaw at
Fri Jul 26 06:38:01 CEST 2002

On Wed, Jul 03, 2002 at 04:38:22PM +0200, Werner Koch wrote:
> On Wed, 3 Jul 2002 09:40:07 -0400, David Shaw said:
> > My current inclination is that doing this is ok, but to add permission
> > and ownership checks on the enclosing directory to go along with the
> > existing ownership check of the extension file itself.  That can at
> > least catch obvious configuration mistakes.  Werner, what do you
> Yes, this should be done to be in sync with the other
> do-not-shoot-yourself-into-the-foot-checks.  OTOH, I'd would prefer to
> get rid of all that extension module code.  I wrote it originally to
> work around the RSA and IDEA patents.  Nowdays the only reason for
> this is probably the IDEA thing.  You all know my stance on that and I
> don't want to start a discussion again.
> The fact is that we should allow users in countries where IDEA is not
> patented to use it.  Distributing idea.c as an extra source,
> independent from gnupg, is one way to do it.  The other way to comply
> with the GPL is by having a way to include extra ciphers into the
> build process.  This way we won't distribute idea.c as part of a GnuPG
> but still have the ability to build a binary more or less
> automatically.  The drawback is that one won't be able to distribute a
> binary then (which is fine with me but probably not for everyone).
> 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?

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 don't really see a big problem with binary distribution.  Currently,
people can use a distributed binary and just compile the IDEA module
themselves.  If there were no modules, then they'd have to compile the
whole thing.  Either way they are compiling something (compiling all
of GnuPG is certainly a larger task, but there is autoconf to make it
easier).  Distributions where IDEA is not a problem (I don't know of
any, but it's possible) can just compile it in themselves.

So yes, it could be a pain, but for me this is outweighed by the
benefits.  There is also the nice side effect of encouraging people to
upgrade from the (sometimes old) version of GnuPG in their

> Regarding that one cipher I don't see a reason to have it configurable
> at all - one fixed location should be sufficient.  
> 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.
> 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.



   David Shaw  |  dshaw at  |  WWW
   "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

More information about the Gnupg-devel mailing list