GnuPG 1.1.90 released

[Brian M. Carlson]

On Thu, Jul 25, 2002 at 11:38:57PM -0400, David Shaw wrote:
> 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?

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 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.
 
> 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.

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?

> 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
> distribution.



> > 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.

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.

> > 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.

-- 
Brian M. Carlson <karlsson at hal-pc.org> <http://decoy.wox.org/~bmc> 0x560553E7
QOTD:
	"I've got one last thing to say before I go; give me back
	all of my stuff."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 663 bytes
Desc: not available
Url : /pipermail/attachments/20020727/8cd0bcbb/attachment.bin