gcrypt, MPI, GMP and powerpc64

Werner Koch wk at gnupg.org
Mon Sep 24 09:44:54 CEST 2007


On Fri, 21 Sep 2007 15:42, tg at swox.com said:

> Of course, not using "the whole GMP suff" doesn't mean one needs to
> rip out the code one wants to use.  That's the wonderful thing with
> libraries.

It is a matter of code auditing.  We don't want to have unused code in a
security critical application.  Even if not used it increases complexity
and requires an autitor to look at the unused code.

> There had been 3 releases (2.0 through 2.0.2) in the year before 1997.
> GMP 2.0 was the biggest ever change of GMP ever.  How many releaases
> per year would you want not to consider a project as "stalled"?

That is 10 years ago and I don't have my mail archives of that time
anymore online.  gmp 2.0.2 is from June 1996.  I am pretty sure that I
wrote to bug-gmp at prep.ai.mit.edu and to you (at the address given in the
ChangeLog).  The only reply I can remember (whether at this time or only
later) is to wait for GMP 3 which was released in April 2000.  Yes, I
call this stalled.

> That is simply not true.  I have been maintainer since the first
> release, without any interruption.

Comments in the ssh included gmp also indicated that there was no active
maintenance at that time.  Quite some bugs in the configure scripts and
longlong.h had been fixed in Debian and not by you. 

> It is a shame that you seem to have based your decision only on false
> information.

"Based on no information" wpuld express that better.  Anyway, there are
enough other reasons not to use GMP for GnuPG.

When eventually GMP 3 was released I was a bit disappointed that the
entire configuration system changed in a way which makes it very hard to
port the code to libgcrypt/gnupg but well that is my reponsibility.

>> So now GMP changed too much?  Either it is stalled, or it moves to
> rapidly.  :-)

I am talking about the years 1997 to 2000.

> I'd like to hear about them.  People often makes such claims, but they
> never seem to be able to get down to details of the optimization they
> have in mind.  (Granted, the x86_64 code in GMP is far from optimal.)

Meanwhile Werner Dittmann contributed faster X86_64 code.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.




More information about the Gcrypt-devel mailing list