v1.1.43 hangs with GLib/GDK threads

Werner Koch wk@gnupg.org
Wed, 01 Oct 2003 21:21:35 +0200

On Sun, 28 Sep 2003 20:02:55 -0700,   said:

> 1.) I updated the sources from CVS, but the compilation failed with:
> 'make[2]: *** No rule to make target `@LTLIBOBJS@', needed
> by `libgcrypt.la'.'  However, I patched v1.1.43's secmem.c, and
> it does appear to have fixed the problem.

Sure that you have the latest autoconf tools and did configure with

> 2.) I was wondering if the libgcrypt team was ever planning on
> releasing compiled binaries, like RPMs.  I'd like to release

No.  That is something the distributions should do.

> RPMs for Ultramagnetic, but I can't distribute a libgcrypt RPM
> on SourceForge because of the stupid export laws (SF is in the
> U.S.).

There should be no problem anymore with that. IIRC, you just have to
send a mail to some BXA mail address.

>     Can anyone donate a couple megs of server space to host
> binaries for my project?  That would be a huge help!

Megs are not a problm, traffic is the real issue ;-).  If you feel
safer hosting your stuff in Germany, the GUUG will certainly allow me
to offer you some space on ftp.gnupg.org.   According to the GPL, you
need to have the source on the same machine, though.

> 3.) What is the status of the libgcrypt sources?  I know that
> it is considered beta, but aren't the individual functions

We have recently done some major changes, so we are still waiting on
feedback.  A 1.2 version will probably released this year.

>     What I'm trying to get to is this:  my project uses
> ElGamal, AES-256, and DSA.  Would I need to wait until libgcrypt
> v2.0.0 is released before I release v1.0 to the public?  If so,

The API should not change anymore, but to be really sure, you better
wait for 1.2.0

> 4.) I see that 1024-bit DSA is the largest I can use.  Any plans
> on making the limit higher?  I'm paranoid.  (If not, I think I'm
> going to switch to 2048-bit RSA sigs...)

DSA is only defined up to 1024 bits; it should be obviously how to
do larger ones using SHA-256 but that is not defined yet.  It is
highly questionable whether RSA2048 using SHA-1 is theoretically
harder to break than DSA 1024 using SHA-1.


Werner Koch                                      <wk@gnupg.org>
The GnuPG Experts                                http://g10code.com
Free Software Foundation Europe	                 http://fsfeurope.org