GnuPG 1.1.90 released

[Brian M. Carlson]

On Sat, Jul 27, 2002 at 06:07:52PM -0400, David Shaw wrote:
> 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.

Ok, ok, I jumped to conclusions.
 
> > > 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.

It is much easier (and faster) to recompile a module and hit the up
button twice (sorry, three times) in bash to get it to dynamically load a
module.
 
> > 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.

There are precompiled versions for say, OpenBSD. (Go with me here, I've
never run OpenBSD.) I don't think OpenBSD includes IDEA, because there is
patent on it in Canada. So you can download it and compile it yourself.
Compiling one module is much more likely to succeed than the entire
tarball of code. Because if one source file in that entire tarball
fails... the program doesn't run.

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

I don't. But remember there was that issue that Linux was reporting more
entropy than it might have had? Someone might have wanted to switch to
EGD. But yes, it is quite unlikely.

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

So are we including it, or not? I'd hate to see it go. But then again,
I'd hate to see it used for actual message signing.

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

Do tell me where I'm going to get a binary distribution with IDEA on
GNU/Linux. Redhat doesn't provide one, and Debian most certainly doesn't
(it is *non-free*). You have effectively made OpenPGP backwards
compatibility on GNU/Linux a nightmare for new users.
 
> 2) Users who can compile.
> 
>    No change from now.

Yes. I'll agree. In fact, it is quite simple to compile and it works most
of the time.

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

As I said above, such a distribution is not available on GNU/Linux,
AFAIK. It is provided on Windows, however. Are *you* going to provide
debs and rpms with IDEA? Don't get me wrong -- I am all about free
software; I use Debian for that very reason. But some people care about
high quality software first. Those people will ignore the ethics of not
using IDEA, or the patent does not apply to them, so they are permitted
to use it.

I believe that providing a DFSG-free distribution (one without IDEA)
allows people to use the program in its natural state if they so choose.
Then, those people who wish to use IDEA (for whatever reason) may do so
by linking dynamically. It makes it easy for the user, legal, and
ethical. What could be better?

In fact, it seems that the Free Software Foundation is in favor of shared
library mechanisms. In the GNU Lesser General Public License v2.1 (I
realize GnuPG is GPL'd, but...) section 6b) it states:

Use a suitable shared library mechanism for linking with the Library.

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

I certainly agree, but it's been here this long. And most of the dynamic
loading complexity is in dlopen and friends. If you wanted to simplify it
more, you could use libltdl3.

I know it would make the code super-ugly, but you could use libltdl3 and
#ifdef out the code so that it compiles it only if you use
--with-dynamic-loading . You could even make it as unsupported as the FSF
manpages. ;-) How's that for a solution that makes everybody happy?

-- 
Brian M. Carlson <karlsson at hal-pc.org> <http://decoy.wox.org/~bmc> 0x560553E7
Seize the day, put no trust in the morrow!
		-- Quintus Horatius Flaccus (Horace)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 663 bytes
Desc: not available
Url : /pipermail/attachments/20020729/b6e2dfe1/attachment.bin