slapd 2.1.29 crashes

[Debian Bug Importer]

Automatically imported from Debian bug report #244827
http://bugs.debian.org/244827

[Nikita V. Youshchenko (yoush)]

Unfortunately, same happens here.

I had to upgrade slapd from testing to sid because of other bug (probably
fixed upstream), and now slapd crashes every several hours.

Quite bad.

[srd (sr-gimp)]

Package: slapd
Version: 2.1.30-1
Severity: normal
Followup-For: Bug #244827

I have a very similar configuration as Michael Berg (slapd for user
authentication with tls, postfix mta and fetchmail running
periodically), and the problem persists with version 2.1.30-1.

Regs,
Sven

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.6
Locale: LANG=C, LC_CTYPE=C

Versions of packages slapd depends on:
ii coreutils [fileutils] 5.0.91-2 The GNU core utilities
ii debconf 1.4.25 Debian configuration management sy
ii fileutils 5.0.91-2 The GNU file management utilities
ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-16 Berkeley v4.2 Database Libraries [
ii libgcrypt7 1.1.90-1.1 LGPL Crypto library - runtime libr
ii libgnutls10 1.0.4-3 GNU TLS library - runtime library
ii libgpg-error0 0.7-1 library for common error values an
ii libiodbc2 3.51.2-2 iODBC Driver Manager
ii libldap2 2.1.30-1 OpenLDAP libraries
ii libltdl3 1.5.6-1 A system independent dlopen wrappe
ii libsasl2 2.1.18-4.1 Authentication abstraction library
ii libslp1 1.0.11-7 OpenSLP libraries
ii libtasn1-2 0.2.7-2 Manage ASN.1 structures (runtime)
ii libwrap0 7.6.dbs-4 Wietse Venema's TCP wrappers libra
ii perl [libmime-base64-perl] 5.8.4-2 Larry Wall's Practical Extraction
ii psmisc 21.5-1 Utilities that use the proc filesy
ii zlib1g 1:1.2.1.1-3 compression library - runtime

-- debconf information excluded

[srd (sr-gimp)]

Hi,
since the package maintainer hasn't said anything to this bugreport at all
(at least from what is viewable in the bug tracking system), I would
like him to just make a short statement as to the status of the bug
resolution.

Even something along the lines of "Can't reproduce, no clue
and no time right now" would be nice to have, since this bug is really
annoying and persistant. I'd hate to download openldap, compile and
install everything by hand to have the bug resolved in debian tomorrow,
but I'd also hate having to wait with a bandaged network for weeks
without knowing what's up.

It's been 40 days since the bug was first reported and considered
"grave", so some information from the maintainer would be nice to have.

Regs,
Sven
--
Sven Riedel <email address hidden>
Liebigstr. 38
30163 Hannover "Python is merely Perl for those who
                                 prefer Pascal to C" (anon)

[Torsten Landschoff (torsten)]

Hi Sven,

On Sun, May 30, 2004 at 04:52:34PM +0200, Sven Riedel wrote:

> Even something along the lines of "Can't reproduce, no clue
> and no time right now" would be nice to have, since this bug is really
> annoying and persistant. I'd hate to download openldap, compile and
> install everything by hand to have the bug resolved in debian tomorrow,
> but I'd also hate having to wait with a bandaged network for weeks
> without knowing what's up.
>
> It's been 40 days since the bug was first reported and considered
> "grave", so some information from the maintainer would be nice to have.

Truth to say, I have no idea what's going on there. slapd is working
just fine on my machine, without it I wouldn't even be able to login...
On the other hand I don't use TLS with PAM and NSS so far so most of the
time TLS is not used.

If you could provide a core file that could prove useful to diagnose the
problem...

Greetings

 Torsten

[srd (sr-gimp)]

Hi,
Thanks for the reply. Sure, a coredump is no problem. Should I mail it
here or to you directly?

Here's a backtrace that I got from the core:
#0 0x4026c960 in gcry_mpi_get_opaque () from /usr/lib/libgcrypt.so.7
#1 0x4026ccef in gcry_mpi_copy () from /usr/lib/libgcrypt.so.7
#2 0x401f12dc in _gnutls_get_dh_params () from /usr/lib/libgnutls.so.10
#3 0x401f1172 in _gnutls_verify_sig_params () from /usr/lib/libgnutls.so.10
#4 0x401e14c8 in _gnutls_recv_client_kx_message () from /usr/lib/libgnutls.so.10
#5 0x401dc410 in _gnutls_handshake_server () from /usr/lib/libgnutls.so.10
#6 0x401dba26 in gnutls_handshake () from /usr/lib/libgnutls.so.10
#7 0x4004ba8a in gnutls_SSL_free () from /usr/lib/libldap_r.so.2
#8 0x4004bc7a in gnutls_SSL_accept () from /usr/lib/libldap_r.so.2
#9 0x00000001 in ?? ()
#10 0x40b8b3f8 in ?? ()
#11 0x40049823 in ldap_pvt_tls_accept () from /usr/lib/libldap_r.so.2
#12 0x00000007 in ?? ()
#13 0x40b8b3e8 in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()
#16 0x400536e0 in ?? () from /usr/lib/libldap_r.so.2
#17 0x081726d0 in ?? ()
#18 0x00000012 in ?? ()
#19 0x4073e6d0 in ?? ()
#20 0x00000012 in ?? ()
#21 0x40b8b438 in ?? ()
#22 0x08057a6d in connection_read ()
Previous frame inner to this frame (corrupt stack?)

I don't know how libgcrypt and libgnutls interact regarding version
numbers, but this could be another symptom of the gnutls7 vs. gnutls10
problem thats' rearing it's head elsewhere in debian (e.g. cups a week
ago).

I'll install libgcrypt11 and see if the problems go away.

Regs,
Sven

--
Sven Riedel <email address hidden>
Liebigstr. 38
30163 Hannover "Python is merely Perl for those who
                                 prefer Pascal to C" (anon)

[Torsten Landschoff (torsten)]

On Mon, May 31, 2004 at 08:20:18PM +0200, Sven Riedel wrote:
> Previous frame inner to this frame (corrupt stack?)

I hate that sort of bug. Really hard to debug :(

> I don't know how libgcrypt and libgnutls interact regarding version
> numbers, but this could be another symptom of the gnutls7 vs. gnutls10
> problem thats' rearing it's head elsewhere in debian (e.g. cups a week
> ago).
>
> I'll install libgcrypt11 and see if the problems go away.

Okay. I am curious about the result...

Greetings

 Torsten

[srd (sr-gimp)]

On Mon, May 31, 2004 at 10:47:55PM +0200, Torsten Landschoff wrote:
> On Mon, May 31, 2004 at 08:20:18PM +0200, Sven Riedel wrote:
> > I don't know how libgcrypt and libgnutls interact regarding version
> > numbers, but this could be another symptom of the gnutls7 vs. gnutls10
> > problem thats' rearing it's head elsewhere in debian (e.g. cups a week
> > ago).
> >
> > I'll install libgcrypt11 and see if the problems go away.
>
> Okay. I am curious about the result...
Unfortunately, not much better. I ln -s'ed /usr/lib/libgcrypt.so.7 to
libgcrypt.so.11.1.1, ran ldconfig and fired up slapd. Unfortunately slap
died almost straight away. The Backtrace looks identical:
#0 0x4026c960 in gcry_mpi_get_opaque () from /usr/lib/libgcrypt.so.7
(no debugging symbols found)...(gdb) where
#0 0x4026c960 in gcry_mpi_get_opaque () from /usr/lib/libgcrypt.so.7
#1 0x4026ccef in gcry_mpi_copy () from /usr/lib/libgcrypt.so.7
#2 0x401f12dc in _gnutls_get_dh_params () from /usr/lib/libgnutls.so.10
#3 0x401f1172 in _gnutls_verify_sig_params () from /usr/lib/libgnutls.so.10
#4 0x401e14c8 in _gnutls_recv_client_kx_message ()
   from /usr/lib/libgnutls.so.10
#5 0x401dc410 in _gnutls_handshake_server () from /usr/lib/libgnutls.so.10
#6 0x401dba26 in gnutls_handshake () from /usr/lib/libgnutls.so.10
#7 0x4004ba8a in gnutls_SSL_free () from /usr/lib/libldap_r.so.2
#8 0x4004bc7a in gnutls_SSL_accept () from /usr/lib/libldap_r.so.2
#9 0x00000001 in ?? ()
#10 0x40b8b3f8 in ?? ()
#11 0x40049823 in ldap_pvt_tls_accept () from /usr/lib/libldap_r.so.2
#12 0x00000007 in ?? ()
#13 0x40b8b3e8 in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()
#16 0x400536e0 in ?? () from /usr/lib/libldap_r.so.2
#17 0x081224b0 in ?? ()
#18 0x00000012 in ?? ()
#19 0x4073e6d0 in ?? ()
#20 0x00000012 in ?? ()
#21 0x40b8b438 in ?? ()
#22 0x08057a6d in connection_read ()

Regs,
Sven

[srd (sr-gimp)]

Hi,
I compiled slapd from openldap 2.2.13 on friday, and it's been running
stable ever since then. So the problem is either a bug in 2.1.30 or it's
a compile-time option. I used the following configure options:

./configure --with-gnu-ld --enable-bdb --enable-ldbm --enable-wrappers
             --enable-slapd --enable-cleartext --enable-crypt
      --enable-spasswd --with-tls

All support-libraries needed came from debian sid.

As a general comment (no blame for this laid on Torsten): It would be
nice if debian got its act together with things ldap. Debain requires
libldap with nearly everything nowadays, but I've been having nothing
but grief with debians ldap packages (first libnss-ldap and libpam-ldap
and now slapd), and compiling each offender for myself always solved
the problem. Rant end.

Regs,
Sven
--
Sven Riedel <email address hidden>
Liebigstr. 38
30163 Hannover "Python is merely Perl for those who
                                 prefer Pascal to C" (anon)

[Stephen Frost (sfrost)]

* Sven Riedel (<email address hidden>) wrote:
> As a general comment (no blame for this laid on Torsten): It would be
> nice if debian got its act together with things ldap. Debain requires
> libldap with nearly everything nowadays, but I've been having nothing
> but grief with debians ldap packages (first libnss-ldap and libpam-ldap
> and now slapd), and compiling each offender for myself always solved
> the problem. Rant end.

Right, thanks for the next-to-useless rant. Perhaps you could elaborate
a bit on the problems you've had or point us to the bug reports you've
filed about these problems.

 Stephen

[Roland Bauerschmidt (roland-hbg-bremen)]

Sven Riedel wrote:
> I compiled slapd from openldap 2.2.13 on friday, and it's been running
> stable ever since then. So the problem is either a bug in 2.1.30 or it's
> a compile-time option. I used the following configure options:

Most likely, you compiled with OpenSSL rather than GNUTLS. Since the
problem seems to be GNUTLS related, you could probably also compile
2.1.30 with OpenSSL (which we can't though).

Roland

[srd (sr-gimp)]

On Sun, Jun 27, 2004 at 02:11:03PM +0200, Roland Bauerschmidt wrote:
> Most likely, you compiled with OpenSSL rather than GNUTLS. Since the
> problem seems to be GNUTLS related, you could probably also compile
> 2.1.30 with OpenSSL (which we can't though).

Hm, true, I used OpenSSL instead of GnuTLS. Seems rather strange though,
since everything else that uses libgnutls10 on the system (kde, cups and
saslauthd) work without problems. The one thing that _is_ different is
that I have certificates from a private CA set up for use with LDAP,
which was generated with OpenSSL. Maybe the parsing of the certificates
triggers the bug in question...

Regs,
Sven

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #244827
http://bugs.debian.org/244827

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 19 Apr 2004 23:41:45 -0600
From: Michael Berg <email address hidden>
To: "Debian Bug Tracking System" <email address hidden>
Subject: slapd 2.1.29 crashes

Package: slapd
Version: 2.1.29-2
Severity: grave
Justification: renders package unusable
Tags: sid

I upgraded to slapd 2.1.29 (and the corresponding libldap2) since it fixes
the TLS/SSL breakage of bug #234593 (which it does fix).

However, after upgrading, slapd 2.1.29 is crashing frequently on my system.

I'm using slapd with TLS/SSL support for user authentication. Crashing
slapd seems to be triggered fairly reliably when fetchmail retrieves
my mail and passes it to postfix for local delivery (which of course
contacts slapd to look up username and info).

Using a log level of 4095 (everything) in /etc/ldap/slapd.conf, I
obtain the syslog messages appended to the end of this email (trimmed
to what I *think* is the relevant parts -- if you need more than this,
just ask and I'll work on sanitizing usernames/schema from the rest
of it).

-- System Information:
Debian Release: testing/unstable
   APT prefers unstable
   APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.5
Locale: LANG=C, LC_CTYPE=C

Versions of packages slapd depends on:
ii coreutils [fileutils] 5.0.91-2 The GNU core utilities
ii debconf 1.4.22 Debian configuration management sy
ii fileutils 5.0.91-2 The GNU file management utilities
ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-16 Berkeley v4.2 Database Libraries [
ii libgcrypt7 1.1.90-1.1 LGPL Crypto library - runtime libr
ii libgnutls10 1.0.4-3 GNU TLS library - runtime library
ii libgpg-error0 0.7-1 library for common error values an
ii libiodbc2 3.51.2-2 iODBC Driver Manager
ii libldap2 2.1.29-2 OpenLDAP libraries
ii libltdl3 1.5.6-1 A system independent dlopen wrappe
ii libsasl2 2.1.18-4 Authentication abstraction library
ii libslp1 1.0.11-7 OpenSLP libraries
ii libtasn1-2 0.2.7-1 Manage ASN.1 structures (runtime)
ii libwrap0 7.6-ipv6.1-3 Wietse Venema's TCP wrappers libra
ii perl [libmime-base64-perl] 5.8.3-3 Larry Wall's Practical Extraction
ii psmisc 21.4-1 Utilities that use the proc filesy
ii zlib1g 1:1.2.1-5 compression library - runtime

-- debconf information:
   slapd/fix_directory: true
* shared/organization: homenet
   slapd/upgrade_slapcat_failure:
   slapd/backend: BDB
* slapd/allow_ldap_v2: false
   slapd/no_configuration: false
   slapd/move_old_database: true
   slapd/suffix_change: false
   slapd/slave_databases_require_updateref:
   slapd/autoconf_modules: true
* slapd/domain: homenet
   slapd/password_mismatch:
   slapd/invalid_config: true
   slapd/upgrade_slapadd_failure:
   slapd/purge_database: false
   slapd/admin:

# Excerpt fro...

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Thu, 29 Apr 2004 14:16:11 +0400
From: "Nikita V. Youshchenko" <email address hidden>
To: <email address hidden>
Subject: same happens here ...

Unfortunately, same happens here.

I had to upgrade slapd from testing to sid because of other bug (probably
fixed upstream), and now slapd crashes every several hours.

Quite bad.

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Thu, 27 May 2004 20:27:43 +0200
From: Sven Riedel <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: Continued slapd breakage with 2.1.30-1

Package: slapd
Version: 2.1.30-1
Severity: normal
Followup-For: Bug #244827

I have a very similar configuration as Michael Berg (slapd for user
authentication with tls, postfix mta and fetchmail running
periodically), and the problem persists with version 2.1.30-1.

Regs,
Sven

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.6
Locale: LANG=C, LC_CTYPE=C

Versions of packages slapd depends on:
ii coreutils [fileutils] 5.0.91-2 The GNU core utilities
ii debconf 1.4.25 Debian configuration management sy
ii fileutils 5.0.91-2 The GNU file management utilities
ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-16 Berkeley v4.2 Database Libraries [
ii libgcrypt7 1.1.90-1.1 LGPL Crypto library - runtime libr
ii libgnutls10 1.0.4-3 GNU TLS library - runtime library
ii libgpg-error0 0.7-1 library for common error values an
ii libiodbc2 3.51.2-2 iODBC Driver Manager
ii libldap2 2.1.30-1 OpenLDAP libraries
ii libltdl3 1.5.6-1 A system independent dlopen wrappe
ii libsasl2 2.1.18-4.1 Authentication abstraction library
ii libslp1 1.0.11-7 OpenSLP libraries
ii libtasn1-2 0.2.7-2 Manage ASN.1 structures (runtime)
ii libwrap0 7.6.dbs-4 Wietse Venema's TCP wrappers libra
ii perl [libmime-base64-perl] 5.8.4-2 Larry Wall's Practical Extraction
ii psmisc 21.5-1 Utilities that use the proc filesy
ii zlib1g 1:1.2.1.1-3 compression library - runtime

-- debconf information excluded

[Debian Bug Importer (debzilla)]

Message-ID: <20040530145234.GA29313@localnet>
Date: Sun, 30 May 2004 16:52:34 +0200
From: Sven Riedel <email address hidden>
To: <email address hidden>
Subject: Some feedback from maintainer?

Hi,
since the package maintainer hasn't said anything to this bugreport at all
(at least from what is viewable in the bug tracking system), I would
like him to just make a short statement as to the status of the bug
resolution.

Even something along the lines of "Can't reproduce, no clue
and no time right now" would be nice to have, since this bug is really
annoying and persistant. I'd hate to download openldap, compile and
install everything by hand to have the bug resolved in debian tomorrow,
but I'd also hate having to wait with a bandaged network for weeks
without knowing what's up.

It's been 40 days since the bug was first reported and considered
"grave", so some information from the maintainer would be nice to have.

Regs,
Sven
--
Sven Riedel <email address hidden>
Liebigstr. 38
30163 Hannover "Python is merely Perl for those who
                                 prefer Pascal to C" (anon)

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 30 May 2004 18:11:04 +0200
From: Torsten Landschoff <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#244827: Some feedback from maintainer?

--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Sven,=20

On Sun, May 30, 2004 at 04:52:34PM +0200, Sven Riedel wrote:
=20
> Even something along the lines of "Can't reproduce, no clue
> and no time right now" would be nice to have, since this bug is really
> annoying and persistant. I'd hate to download openldap, compile and
> install everything by hand to have the bug resolved in debian tomorrow,
> but I'd also hate having to wait with a bandaged network for weeks
> without knowing what's up.
>=20
> It's been 40 days since the bug was first reported and considered
> "grave", so some information from the maintainer would be nice to have.

Truth to say, I have no idea what's going on there. slapd is working
just fine on my machine, without it I wouldn't even be able to login...
On the other hand I don't use TLS with PAM and NSS so far so most of the
time TLS is not used.=20

If you could provide a core file that could prove useful to diagnose the
problem...

Greetings

 Torsten

--r5Pyd7+fXNt84Ff3
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAugeXdQgHtVUb5EcRAnSIAJ4y2GySh5iVjq9tx5LPI65bG8aJDgCfZpym
tUPnr+rKN6sQHqTl4nwJND0=
=GTNf
-----END PGP SIGNATURE-----

--r5Pyd7+fXNt84Ff3--

[Debian Bug Importer (debzilla)]

Message-ID: <20040531182018.GA9455@localnet>
Date: Mon, 31 May 2004 20:20:18 +0200
From: Sven Riedel <email address hidden>
To: <email address hidden>
Subject: Coredump

Hi,
Thanks for the reply. Sure, a coredump is no problem. Should I mail it
here or to you directly?

Here's a backtrace that I got from the core:
#0 0x4026c960 in gcry_mpi_get_opaque () from /usr/lib/libgcrypt.so.7
#1 0x4026ccef in gcry_mpi_copy () from /usr/lib/libgcrypt.so.7
#2 0x401f12dc in _gnutls_get_dh_params () from /usr/lib/libgnutls.so.10
#3 0x401f1172 in _gnutls_verify_sig_params () from /usr/lib/libgnutls.so.10
#4 0x401e14c8 in _gnutls_recv_client_kx_message () from /usr/lib/libgnutls.so.10
#5 0x401dc410 in _gnutls_handshake_server () from /usr/lib/libgnutls.so.10
#6 0x401dba26 in gnutls_handshake () from /usr/lib/libgnutls.so.10
#7 0x4004ba8a in gnutls_SSL_free () from /usr/lib/libldap_r.so.2
#8 0x4004bc7a in gnutls_SSL_accept () from /usr/lib/libldap_r.so.2
#9 0x00000001 in ?? ()
#10 0x40b8b3f8 in ?? ()
#11 0x40049823 in ldap_pvt_tls_accept () from /usr/lib/libldap_r.so.2
#12 0x00000007 in ?? ()
#13 0x40b8b3e8 in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()
#16 0x400536e0 in ?? () from /usr/lib/libldap_r.so.2
#17 0x081726d0 in ?? ()
#18 0x00000012 in ?? ()
#19 0x4073e6d0 in ?? ()
#20 0x00000012 in ?? ()
#21 0x40b8b438 in ?? ()
#22 0x08057a6d in connection_read ()
Previous frame inner to this frame (corrupt stack?)

I don't know how libgcrypt and libgnutls interact regarding version
numbers, but this could be another symptom of the gnutls7 vs. gnutls10
problem thats' rearing it's head elsewhere in debian (e.g. cups a week
ago).

I'll install libgcrypt11 and see if the problems go away.

Regs,
Sven

--
Sven Riedel <email address hidden>
Liebigstr. 38
30163 Hannover "Python is merely Perl for those who
                                 prefer Pascal to C" (anon)

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 31 May 2004 22:47:55 +0200
From: Torsten Landschoff <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#244827: Coredump

--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 31, 2004 at 08:20:18PM +0200, Sven Riedel wrote:
> Previous frame inner to this frame (corrupt stack?)

I hate that sort of bug. Really hard to debug :(

> I don't know how libgcrypt and libgnutls interact regarding version
> numbers, but this could be another symptom of the gnutls7 vs. gnutls10
> problem thats' rearing it's head elsewhere in debian (e.g. cups a week
> ago).
>=20
> I'll install libgcrypt11 and see if the problems go away.

Okay. I am curious about the result...

Greetings

 Torsten

--rwEMma7ioTxnRzrJ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAu5n7dQgHtVUb5EcRAms9AJ9RfyXBHwLWOjerLUMg6t4hZt2NaQCfSNM0
gbA46gvFSyCB/ZxOUUkAjvQ=
=cEjw
-----END PGP SIGNATURE-----

--rwEMma7ioTxnRzrJ--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 1 Jun 2004 02:55:48 -0700
From: Sven Riedel <email address hidden>
To: Torsten Landschoff <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#244827: Coredump

On Mon, May 31, 2004 at 10:47:55PM +0200, Torsten Landschoff wrote:
> On Mon, May 31, 2004 at 08:20:18PM +0200, Sven Riedel wrote:
> > I don't know how libgcrypt and libgnutls interact regarding version
> > numbers, but this could be another symptom of the gnutls7 vs. gnutls10
> > problem thats' rearing it's head elsewhere in debian (e.g. cups a week
> > ago).
> >
> > I'll install libgcrypt11 and see if the problems go away.
>
> Okay. I am curious about the result...
Unfortunately, not much better. I ln -s'ed /usr/lib/libgcrypt.so.7 to
libgcrypt.so.11.1.1, ran ldconfig and fired up slapd. Unfortunately slap
died almost straight away. The Backtrace looks identical:
#0 0x4026c960 in gcry_mpi_get_opaque () from /usr/lib/libgcrypt.so.7
(no debugging symbols found)...(gdb) where
#0 0x4026c960 in gcry_mpi_get_opaque () from /usr/lib/libgcrypt.so.7
#1 0x4026ccef in gcry_mpi_copy () from /usr/lib/libgcrypt.so.7
#2 0x401f12dc in _gnutls_get_dh_params () from /usr/lib/libgnutls.so.10
#3 0x401f1172 in _gnutls_verify_sig_params () from /usr/lib/libgnutls.so.10
#4 0x401e14c8 in _gnutls_recv_client_kx_message ()
   from /usr/lib/libgnutls.so.10
#5 0x401dc410 in _gnutls_handshake_server () from /usr/lib/libgnutls.so.10
#6 0x401dba26 in gnutls_handshake () from /usr/lib/libgnutls.so.10
#7 0x4004ba8a in gnutls_SSL_free () from /usr/lib/libldap_r.so.2
#8 0x4004bc7a in gnutls_SSL_accept () from /usr/lib/libldap_r.so.2
#9 0x00000001 in ?? ()
#10 0x40b8b3f8 in ?? ()
#11 0x40049823 in ldap_pvt_tls_accept () from /usr/lib/libldap_r.so.2
#12 0x00000007 in ?? ()
#13 0x40b8b3e8 in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()
#16 0x400536e0 in ?? () from /usr/lib/libldap_r.so.2
#17 0x081224b0 in ?? ()
#18 0x00000012 in ?? ()
#19 0x4073e6d0 in ?? ()
#20 0x00000012 in ?? ()
#21 0x40b8b438 in ?? ()
#22 0x08057a6d in connection_read ()

Regs,
Sven

[Debian Bug Importer (debzilla)]

Message-ID: <20040621063758.GA22831@localnet>
Date: Mon, 21 Jun 2004 08:37:58 +0200
From: Sven Riedel <email address hidden>
To: <email address hidden>
Subject: No Problems with self-compiled slapd

Hi,
I compiled slapd from openldap 2.2.13 on friday, and it's been running
stable ever since then. So the problem is either a bug in 2.1.30 or it's
a compile-time option. I used the following configure options:

./configure --with-gnu-ld --enable-bdb --enable-ldbm --enable-wrappers
             --enable-slapd --enable-cleartext --enable-crypt
      --enable-spasswd --with-tls

All support-libraries needed came from debian sid.

As a general comment (no blame for this laid on Torsten): It would be
nice if debian got its act together with things ldap. Debain requires
libldap with nearly everything nowadays, but I've been having nothing
but grief with debians ldap packages (first libnss-ldap and libpam-ldap
and now slapd), and compiling each offender for myself always solved
the problem. Rant end.

Regs,
Sven
--
Sven Riedel <email address hidden>
Liebigstr. 38
30163 Hannover "Python is merely Perl for those who
                                 prefer Pascal to C" (anon)

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 21 Jun 2004 08:11:28 -0400
From: Stephen Frost <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: [debian-openldap] Bug#244827: No Problems with self-compiled slapd

--i3ZeZWfMixn4X/oG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Sven Riedel (<email address hidden>) wrote:
> As a general comment (no blame for this laid on Torsten): It would be
> nice if debian got its act together with things ldap. Debain requires
> libldap with nearly everything nowadays, but I've been having nothing
> but grief with debians ldap packages (first libnss-ldap and libpam-ldap
> and now slapd), and compiling each offender for myself always solved=20
> the problem. Rant end.

Right, thanks for the next-to-useless rant. Perhaps you could elaborate
a bit on the problems you've had or point us to the bug reports you've
filed about these problems.

 Stephen

--i3ZeZWfMixn4X/oG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA1tBwrzgMPqB3kigRAoKWAJ9HkWMo3UtU5VDj2fR4G0IqAwcMogCeLIrP
ofs8nhi7ecfB76tFup5FLzk=
=3raJ
-----END PGP SIGNATURE-----

--i3ZeZWfMixn4X/oG--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 27 Jun 2004 14:11:03 +0200
From: Roland Bauerschmidt <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: [debian-openldap] Bug#244827: No Problems with self-compiled slapd

Sven Riedel wrote:
> I compiled slapd from openldap 2.2.13 on friday, and it's been running
> stable ever since then. So the problem is either a bug in 2.1.30 or it's
> a compile-time option. I used the following configure options:

Most likely, you compiled with OpenSSL rather than GNUTLS. Since the
problem seems to be GNUTLS related, you could probably also compile
2.1.30 with OpenSSL (which we can't though).

Roland

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 27 Jun 2004 05:52:02 -0700
From: Sven Riedel <email address hidden>
To: Roland Bauerschmidt <email address hidden>
Cc: <email address hidden>
Subject: Re: [debian-openldap] Bug#244827: No Problems with self-compiled slapd

On Sun, Jun 27, 2004 at 02:11:03PM +0200, Roland Bauerschmidt wrote:
> Most likely, you compiled with OpenSSL rather than GNUTLS. Since the
> problem seems to be GNUTLS related, you could probably also compile
> 2.1.30 with OpenSSL (which we can't though).

Hm, true, I used OpenSSL instead of GnuTLS. Seems rather strange though,
since everything else that uses libgnutls10 on the system (kde, cups and
saslauthd) work without problems. The one thing that _is_ different is
that I have certificates from a private CA set up for use with LDAP,
which was generated with OpenSSL. Maybe the parsing of the certificates
triggers the bug in question...

Regs,
Sven

[Matt Zimmerman (mdz)]

Remove myself from all these CCs now that we have the warty-bugs mailing list

[Matt Zimmerman (mdz)]

Increase severity of RC bugs to major, now that we have other, non-RC bugs in
the list

[Matthias Urlichs (smurf)]

reassign 244827 libgcrypt7
thanks

I am the new maintainer of gcrypt* and gnutls*. This looks like it's now
my bug :-/ and I've reassigned it to libgcrypt7, as that's where it
crashes.

Please verify that this still happens with the latest versions from
Unstable (gnutls10 1.0.4-4; libgcrypt7 1.1.90-9).

If so: In gdb, please list the shared ibraries ("gdb> inf sha") which
are loaded and say "gdb> fr 0" so that I can see *where* in
gcry_mpi_get_opaque the bug is.

Thank you.

--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>

[Debian Bug Importer (debzilla)]

Message-ID: <20040716103700.GO12012@kiste>
Date: Fri, 16 Jul 2004 12:37:01 +0200
From: "Matthias Urlichs" <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: My fault ;-)

--hTiIB9CRvBOLTyqY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

reassign 244827 libgcrypt7
thanks

I am the new maintainer of gcrypt* and gnutls*. This looks like it's now
my bug :-/ and I've reassigned it to libgcrypt7, as that's where it
crashes.

Please verify that this still happens with the latest versions from
Unstable (gnutls10 1.0.4-4; libgcrypt7 1.1.90-9).

If so: In gdb, please list the shared ibraries ("gdb> inf sha") which
are loaded and say "gdb> fr 0" so that I can see *where* in
gcry_mpi_get_opaque the bug is.

Thank you.

--=20
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>

--hTiIB9CRvBOLTyqY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA96/M8+hUANcKr/kRAtEhAJ4u8f5vKSPN5TtlaiSKtNEidw4QVgCZAUt1
nX8b0OWMWyC3S8VWNOHt0Ww=
=Gly/
-----END PGP SIGNATURE-----

--hTiIB9CRvBOLTyqY--

[Modestas Vainius (geromanas)]

Package: libgcrypt7
Version: 1.1.90-9
Followup-For: Bug #244827

Hello,

The problem persists with libgcrypt7_1.1.90-9 and libgnutls10_1.0.4-3.
However, the bug is not in gcry_mpi_get_opaque(), but in _gcry_mpi_copy()
gdb provides inaccurate backtrace when libgcrypt7 is compiled with -O2
That's what I got when I reproduced the problem with slapd, gnutls10 and
libgcrypt7 recompiled with DEB_BUILD_OPTIONS="noopt nostrip"

(gdb) bt
#0 0x402a53f5 in _gcry_mpi_copy (a=0x8116a58) at mpiutil.c:229
#1 0x402a57d0 in gcry_mpi_copy (a=0x8116a58) at mpiutil.c:343
#2 0x401ffcb8 in _gnutls_get_dh_params (dh_primes=0x8119ac8,
ret_p=0xbf7fc248, ret_g=0xbf7fc244) at gnutls_dh_primes.c:45
#3 0x401ffb8f in proc_dhe_client_kx (session=0x814a480, data=0x814d818
"", _data_size=98) at auth_dhe.c:268
#4 0x401ebc37 in _gnutls_recv_client_kx_message (session=0x814a480) at
gnutls_kx.c:329
#5 0x401e81c3 in _gnutls_handshake_server (session=0x814a480) at
gnutls_handshake.c:2241
#6 0x401e6ca9 in gnutls_handshake (session=0x814a480) at
gnutls_handshake.c:1892
#7 0x400529a7 in SSL_do_handshake (ssl=0x8147598, end=GNUTLS_SERVER) at
gnutls.c:627
#8 0x40052acd in gnutls_SSL_accept (ssl=0x8147598) at gnutls.c:670
#9 0x40050394 in ldap_pvt_tls_accept (sb=0x814e230, ctx_arg=0x0) at
tls.c:928
#10 0x08058ff0 in connection_read ()
#11 0x080564ab in slapd_daemon_destroy ()
#12 0x4032be51 in pthread_start_thread () from /lib/libpthread.so.0
#13 0x4032becf in pthread_start_thread_event () from
/lib/libpthread.so.0
#14 0x4046169a in clone () from /lib/libc.so.6

slapd segfaults, because:

(gdb) p a->d
$2 = (mpi_limb_t *) 0x10

The bug can be reproduced this way:

1) Start slapd ( slapd -d0 -h "ldap:/// ldaps:///" ). Be sure TLS is
enabled in slapd.conf

2) Run the script below concurrently in 4 (the number may vary) consoles
 I=1; while ldapwhoami -ZZ -D "<your login DN>" -w "<password>" -x > /dev/null; do I=$[I+1]; done

3) Patience. Usually slapd crashes in 1-2 mins (on Pentium4
2.67ghz), however, sometimes it keeps running for 5-10 mins or even
more. If you were waiting for too long with no "success", restart slapd
and rerun the scripts. You may try increasing/decreasing the number of
concurrent instances of the script too.

By the way, I was able to trigger the bug only with the script
concurrenly running in two or more consoles, so it seems that the bug
only occurs in a threaded environment.

"info sharedlibrary" says the following:

(gdb) info sharedlibrary
>From To Syms Read Shared Object Library
0x400280f0 0x40055920 Yes /usr/lib/libldap_r.so.2
0x4005e5b0 0x40066df0 Yes /usr/lib/liblber.so.2
0x40082530 0x4012c2a0 Yes /usr/lib/libdb-4.2.so
0x40144a70 0x40174250 Yes /usr/lib/libiodbc.so.2
0x40181320 0x40188090 Yes /usr/lib/libiodbcinst.so.2
0x4018cf40 0x40194870 Yes /usr/lib/libslp.so.1
0x40199540 0x401b0fd0 Yes /lib/libm.so.6
0x401bb180 0x401c98e0 Yes /usr/lib/libsasl2.so.2
0x401dd530 0x4023a000 Yes /usr/lib/libgnutls.so.10
0x4024d190 0x40258360 Yes /usr/lib/libtasn1.so.2
0x4025f3b0 0x402abf60 Yes /usr/lib/libgcrypt.so.7
0x402bfc30 0x402cbac0 ...

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Mon, 19 Jul 2004 16:06:16 +0300
From: Modestas Vainius <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: libgcrypt7: more info

Package: libgcrypt7
Version: 1.1.90-9
Followup-For: Bug #244827

Hello,

The problem persists with libgcrypt7_1.1.90-9 and libgnutls10_1.0.4-3.
However, the bug is not in gcry_mpi_get_opaque(), but in _gcry_mpi_copy()
gdb provides inaccurate backtrace when libgcrypt7 is compiled with -O2
That's what I got when I reproduced the problem with slapd, gnutls10 and
libgcrypt7 recompiled with DEB_BUILD_OPTIONS="noopt nostrip"

(gdb) bt
#0 0x402a53f5 in _gcry_mpi_copy (a=0x8116a58) at mpiutil.c:229
#1 0x402a57d0 in gcry_mpi_copy (a=0x8116a58) at mpiutil.c:343
#2 0x401ffcb8 in _gnutls_get_dh_params (dh_primes=0x8119ac8,
ret_p=0xbf7fc248, ret_g=0xbf7fc244) at gnutls_dh_primes.c:45
#3 0x401ffb8f in proc_dhe_client_kx (session=0x814a480, data=0x814d818
"", _data_size=98) at auth_dhe.c:268
#4 0x401ebc37 in _gnutls_recv_client_kx_message (session=0x814a480) at
gnutls_kx.c:329
#5 0x401e81c3 in _gnutls_handshake_server (session=0x814a480) at
gnutls_handshake.c:2241
#6 0x401e6ca9 in gnutls_handshake (session=0x814a480) at
gnutls_handshake.c:1892
#7 0x400529a7 in SSL_do_handshake (ssl=0x8147598, end=GNUTLS_SERVER) at
gnutls.c:627
#8 0x40052acd in gnutls_SSL_accept (ssl=0x8147598) at gnutls.c:670
#9 0x40050394 in ldap_pvt_tls_accept (sb=0x814e230, ctx_arg=0x0) at
tls.c:928
#10 0x08058ff0 in connection_read ()
#11 0x080564ab in slapd_daemon_destroy ()
#12 0x4032be51 in pthread_start_thread () from /lib/libpthread.so.0
#13 0x4032becf in pthread_start_thread_event () from
/lib/libpthread.so.0
#14 0x4046169a in clone () from /lib/libc.so.6

slapd segfaults, because:

(gdb) p a->d
$2 = (mpi_limb_t *) 0x10

The bug can be reproduced this way:

1) Start slapd ( slapd -d0 -h "ldap:/// ldaps:///" ). Be sure TLS is
enabled in slapd.conf

2) Run the script below concurrently in 4 (the number may vary) consoles
 I=1; while ldapwhoami -ZZ -D "<your login DN>" -w "<password>" -x > /dev/null; do I=$[I+1]; done

3) Patience. Usually slapd crashes in 1-2 mins (on Pentium4
2.67ghz), however, sometimes it keeps running for 5-10 mins or even
more. If you were waiting for too long with no "success", restart slapd
and rerun the scripts. You may try increasing/decreasing the number of
concurrent instances of the script too.

By the way, I was able to trigger the bug only with the script
concurrenly running in two or more consoles, so it seems that the bug
only occurs in a threaded environment.

"info sharedlibrary" says the following:

(gdb) info sharedlibrary
>From To Syms Read Shared Object Library
0x400280f0 0x40055920 Yes /usr/lib/libldap_r.so.2
0x4005e5b0 0x40066df0 Yes /usr/lib/liblber.so.2
0x40082530 0x4012c2a0 Yes /usr/lib/libdb-4.2.so
0x40144a70 0x40174250 Yes /usr/lib/libiodbc.so.2
0x40181320 0x40188090 Yes /usr/lib/libiodbcinst.so.2
0x4018cf40 0x40194870 Yes /usr/lib/libslp.so.1
0x40199540 0x401b0fd0 Yes /lib/libm.so.6
0x401bb180 0x401c98e0 Yes /us...

[Matthias Urlichs (smurf)]

Hi,

Modestas Vainius:
> The problem persists with libgcrypt7_1.1.90-9 and libgnutls10_1.0.4-3.

Thanks for the info.

> However, the bug is not in gcry_mpi_get_opaque(), but in _gcry_mpi_copy()

Thought so...

> gdb provides inaccurate backtrace when libgcrypt7 is compiled with -O2

Not really -- gcc just suppresses symbol names which aren't externally
reachable, and gdb then uses the sybols it does see...

> (gdb) p a->d
> $2 = (mpi_limb_t *) 0x10
>
*Grumble* I hate bugs like these.

> 1) Start slapd ( slapd -d0 -h "ldap:/// ldaps:///" ). Be sure TLS is
> enabled in slapd.conf
>
Actually, /etc/default/slapd. ;-)

> By the way, I was able to trigger the bug only with the script
> concurrenly running in two or more consoles, so it seems that the bug
> only occurs in a threaded environment.
>
Looks like a nicely impossible-to-find memory corruption bug. Happiness.
Did you try to reproduce it under Electric Fence?

--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>

[Debian Bug Importer (debzilla)]

Message-ID: <20040719153535.GE14627@kiste>
Date: Mon, 19 Jul 2004 17:35:36 +0200
From: "Matthias Urlichs" <email address hidden>
To: Modestas Vainius <email address hidden>, <email address hidden>
Subject: Re: Bug#244827: libgcrypt7: more info

--9l24NVCWtSuIVIod
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

Modestas Vainius:
> The problem persists with libgcrypt7_1.1.90-9 and libgnutls10_1.0.4-3.

Thanks for the info.

> However, the bug is not in gcry_mpi_get_opaque(), but in _gcry_mpi_copy()

Thought so...

> gdb provides inaccurate backtrace when libgcrypt7 is compiled with -O2

Not really -- gcc just suppresses symbol names which aren't externally
reachable, and gdb then uses the sybols it does see...

> (gdb) p a->d
> $2 =3D (mpi_limb_t *) 0x10
>=20
*Grumble* I hate bugs like these.

> 1) Start slapd ( slapd -d0 -h "ldap:/// ldaps:///" ). Be sure TLS is
> enabled in slapd.conf
>=20
Actually, /etc/default/slapd. ;-)

> By the way, I was able to trigger the bug only with the script
> concurrenly running in two or more consoles, so it seems that the bug
> only occurs in a threaded environment.
>=20
Looks like a nicely impossible-to-find memory corruption bug. Happiness.
Did you try to reproduce it under Electric Fence?

--=20
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>

--9l24NVCWtSuIVIod
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA++pH8+hUANcKr/kRAs37AJ9UE0u5v479E6QDj9uP1QYDgM+wewCfZHXA
6CIZF3bMgnqoI+EmWEoO4XQ=
=YHEg
-----END PGP SIGNATURE-----

--9l24NVCWtSuIVIod--

[Werner Koch (wk)]

On Mon, 19 Jul 2004 17:35:36 +0200, Matthias Urlichs said:

>> (gdb) p a->d
>> $2 = (mpi_limb_t *) 0x10
>>
> *Grumble* I hate bugs like these.

A glance at the ChangeLog doesn't reveal any interesting except for

 * mpiutil.c (_gcry_mpi_alloc_limb_space): Better allocate
 something even if NLIMBS is passed as 0.

I don't think it is the reason but I would give libgcrypt 1.2.0 a
short try, anyway

  Werner

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 19 Jul 2004 19:49:09 +0200
From: Werner Koch <email address hidden>
To: "Matthias Urlichs" <email address hidden>
Cc: <email address hidden>, Modestas Vainius <email address hidden>
Subject: Re: Bug#244827: libgcrypt7: more info

On Mon, 19 Jul 2004 17:35:36 +0200, Matthias Urlichs said:

>> (gdb) p a->d
>> $2 = (mpi_limb_t *) 0x10
>>
> *Grumble* I hate bugs like these.

A glance at the ChangeLog doesn't reveal any interesting except for

 * mpiutil.c (_gcry_mpi_alloc_limb_space): Better allocate
 something even if NLIMBS is passed as 0.

I don't think it is the reason but I would give libgcrypt 1.2.0 a
short try, anyway

  Werner

[Roland Bauerschmidt (bauerschmidt)]

On Mon, Jul 19, 2004 at 07:49:09PM +0200, Werner Koch wrote:
> A glance at the ChangeLog doesn't reveal any interesting except for
>
> * mpiutil.c (_gcry_mpi_alloc_limb_space): Better allocate
> something even if NLIMBS is passed as 0.
>
> I don't think it is the reason but I would give libgcrypt 1.2.0 a
> short try, anyway

Sven Riedel already has and I also just verified that the problem is
still present.

Thanks for your help though,

Roland

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 09:53:43 +0200
From: <email address hidden> (Roland Bauerschmidt)
To: Werner Koch <email address hidden>
Cc: Matthias Urlichs <email address hidden>, <email address hidden>,
 Modestas Vainius <email address hidden>
Subject: Re: Bug#244827: libgcrypt7: more info

On Mon, Jul 19, 2004 at 07:49:09PM +0200, Werner Koch wrote:
> A glance at the ChangeLog doesn't reveal any interesting except for
>
> * mpiutil.c (_gcry_mpi_alloc_limb_space): Better allocate
> something even if NLIMBS is passed as 0.
>
> I don't think it is the reason but I would give libgcrypt 1.2.0 a
> short try, anyway

Sven Riedel already has and I also just verified that the problem is
still present.

Thanks for your help though,

Roland

[Roland Bauerschmidt (bauerschmidt)]

On Mon, Jul 19, 2004 at 05:35:36PM +0200, Matthias Urlichs wrote:
> Looks like a nicely impossible-to-find memory corruption bug. Happiness.
> Did you try to reproduce it under Electric Fence?

I have just reproduced the bug under Electric Fence. The SEGV occurs
slightly earlier:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16386 (LWP 15079)]
0x402924fe in _gcry_mpi_copy (a=0x85cfbff6) at mpiutil.c:216
216 if( a && (a->flags & 4) ) {
(gdb) bt
#0 0x402924fe in _gcry_mpi_copy (a=0x85cfbff6) at mpiutil.c:216
#1 0x40292a48 in gcry_mpi_copy (a=0x85cfbff6) at mpiutil.c:343
#2 0x401fe3fc in _gnutls_get_dh_params (dh_primes=0x6c107ff8, ret_p=0xbf7fc248, ret_g=0xbf7fc24c)
    at gnutls_dh_primes.c:45
#3 0x401fe292 in proc_dhe_client_kx (session=0x6c01c630, data=0x85cfbff6 <Address 0x85cfbff6 out of bounds>,
    _data_size=2244984822) at auth_dhe.c:268
#4 0x401ee548 in _gnutls_recv_client_kx_message (session=0x6c01c630) at gnutls_kx.c:329
#5 0x401e94c0 in _gnutls_handshake_server (session=0x6c01c630) at gnutls_handshake.c:2241
#6 0x401e8ad6 in gnutls_handshake (session=0x6c01c630) at gnutls_handshake.c:1892
#7 0x400569a7 in SSL_do_handshake (ssl=0x485d0fdc, end=GNUTLS_SERVER) at gnutls.c:627
#8 0x40056acd in gnutls_SSL_accept (ssl=0x485d0fdc) at gnutls.c:670
#9 0x40054394 in ldap_pvt_tls_accept (sb=0x6bc15fe4, ctx_arg=0x0) at tls.c:928
#10 0x08058ff0 in connection_read (s=32) at /root/tls/openldap2-2.1.30/servers/slapd/connection.c:1134
#11 0x080564ab in slapd_daemon_task (ptr=0x0) at /root/tls/openldap2-2.1.30/servers/slapd/daemon.c:1863
#12 0x40312e51 in pthread_start_thread () from /lib/libpthread.so.0
#13 0x40312ecf in pthread_start_thread_event () from /lib/libpthread.so.0
#14 0x4044969a in clone () from /lib/libc.so.6

That a->d pointed to 0x10 in a previous post doesn't seem to be the
root of failure, but rather a consequence of this:

(gdb) f 0
#0 0x402924fe in _gcry_mpi_copy (a=0x85cfbff6) at mpiutil.c:216
216 if( a && (a->flags & 4) ) {
(gdb) p *a
Cannot access memory at address 0x85cfbff6
(gdb)

The variable 'a' is the same as cred->dh_params in #3:

(gdb) f 3
#3 0x401fe292 in proc_dhe_client_kx (session=0x6c01c630, data=0x85cfbff6 <Address 0x85cfbff6 out of bounds>,
    _data_size=2244984822) at auth_dhe.c:268
268 if ( (ret=_gnutls_get_dh_params( cred->dh_params, &p, &g)) < 0) {
(gdb) p cred->dh_params
Cannot access memory at address 0x85cfbff6
(gdb)

Before, cred gets assigned the following:

auth_dhe.c:
cred = _gnutls_get_cred(session->key, GNUTLS_CRD_CERTIFICATE, NULL);

const void *_gnutls_get_cred( GNUTLS_KEY key, gnutls_credentials_type type, int *err) {
        const void *retval = NULL;
        int _err = -1;
        AUTH_CRED * ccred;

        if (key == NULL) goto out;

        ccred = key->cred;
        while(ccred!=NULL) {
                if (ccred->algorithm==type) {
                        break;
                }
                ccred = ccred->next;
        }
        if (ccred==NULL) goto out;

        _err = 0;
        retval = ccred->credentials;

        out:
        if (err!=NULL) *err=_err;
        return retval;
}

_gnutls_get_cred walks through the l...

[Matthias Urlichs (smurf)]

Hi,

Roland Bauerschmidt:
> I have just reproduced the bug under Electric Fence. The SEGV occurs
> slightly earlier:
>
Yes -- still not terribly helpful however, we need to find out who
releases the memory.

Sometimes it occurs still earlier:

0x40200384 in _gnutls_get_dh_params (dh_primes=0x486baff8, ret_p=0xbf7fc248,
    ret_g=0xbf7fc24c) at gnutls_dh_primes.c:37
37 if (dh_primes == NULL || dh_primes->_prime == NULL ||
(gdb) whe
#0 0x40200384 in _gnutls_get_dh_params (dh_primes=0x486baff8,
    ret_p=0xbf7fc248, ret_g=0xbf7fc24c) at gnutls_dh_primes.c:37
#1 0x40200292 in proc_dhe_client_kx (session=0x484c1630,
    data=0x486baff8 '' <repeats 200 times>..., _data_size=1215016952)
    at auth_dhe.c:268
#2 0x401f0548 in _gnutls_recv_client_kx_message (session=0x484c1630)
    at gnutls_kx.c:329
#3 0x401eb4c0 in _gnutls_handshake_server (session=0x484c1630)
    at gnutls_handshake.c:2241
#4 0x401eaad6 in gnutls_handshake (session=0x484c1630)
    at gnutls_handshake.c:1892
#5 0x400599a7 in SSL_do_handshake (ssl=0x48572fdc, end=GNUTLS_SERVER)
    at gnutls.c:627
#6 0x40059acd in gnutls_SSL_accept (ssl=0x48572fdc) at gnutls.c:670

> Consequently, session->key->cred->credentials and cred should be
> *identical*. But they aren't (0x47210fb8 != 0x85cfbff6):
>
Umm...

> (gdb) p session->key->cred->credentials
> $53 = (void *) 0x47210fb8
> (gdb) p cred
> $54 = <value optimized out>
> (gdb) p *cred
> Cannot access memory at address 0x85cfbff6

... gdb actually uses the wrong value here (optimization!), especially since
session->key->cred->credentials is accessible. Try recompiling with -O0.

You might also try the helpful

(gdb) set env EF_FREE_WIPES 1

If you do that, you see
(gdb) p *((const CERTIFICATE_CREDENTIALS_INT *)session->key->cred->credentials)->dh_params
$40 = {_prime = 0xbdbdbdbd, _generator = 0xbdbdbdbd}

=> something freed the dh_params vector.

I haven't found the culprit yet.

--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>

[Modestas Vainius (geromanas)]

Tuesday 20 July 2004 14:44, Matthias Urlichs rašė:
> Yes -- still not terribly helpful however, we need to find out who
> releases the memory.
This is what I discovered with valgrind:

==12898== Thread 2:
==12898== Invalid read of size 4
==12898== at 0x3C217C4B: _gnutls_get_dh_params (gnutls_dh_primes.c:37)
==12898== by 0x3C217B8E: proc_dhe_client_kx (auth_dhe.c:268)
==12898== by 0x3C203C36: _gnutls_recv_client_kx_message (gnutls_kx.c:329)
==12898== by 0x3C2001C2: _gnutls_handshake_server (gnutls_handshake.c:2241)
==12898== by 0x3C1FECA8: gnutls_handshake (gnutls_handshake.c:1892)
==12898== by 0x3C0619A6: SSL_do_handshake (gnutls.c:627)
==12898== by 0x3C061ACC: gnutls_SSL_accept (gnutls.c:670)
==12898== by 0x3C05F393: ldap_pvt_tls_accept (tls.c:928)
==12898== by 0x8058FEF: connection_read (in /mnt/user/usr/sbin/slapd)
==12898== by 0x80564AA: (within /mnt/user/usr/sbin/slapd)
==12898== Address 0x3C510FE0 is 0 bytes inside a block of size 8 free'd
==12898== at 0x3C01F918: free (vg_replace_malloc.c:127)
==12898== by 0x3C2182C9: gnutls_dh_params_deinit (gnutls_dh_primes.c:229)
==12898== by 0x3C061AA2: SSL_do_handshake (gnutls.c:662)
==12898== by 0x3C061ACC: gnutls_SSL_accept (gnutls.c:670)
==12898== by 0x3C05F393: ldap_pvt_tls_accept (tls.c:928)
==12898== by 0x8058FEF: connection_read (in /mnt/user/usr/sbin/slapd)
==12898== by 0x80564AA: (within /mnt/user/usr/sbin/slapd)
==12898== by 0x3C34B110: thread_wrapper (vg_libpthread.c:837)
==12898== by 0xB800FACC: do__quit (vg_scheduler.c:1792)

[Roland Bauerschmidt (bauerschmidt)]

On Tue, Jul 20, 2004 at 01:44:46PM +0200, Matthias Urlichs wrote:
> => something freed the dh_params vector.
>
> I haven't found the culprit yet.

I think I might've found it (though not verified yet). In gnutls.c
(OpenLDAP code), SSL_do_handshake:

 [...]
        if (!ssl->session) {
   [...]
                        gnutls_error = gnutls_rsa_params_init(&rsa_params);
   [...]
                        gnutls_error = gnutls_dh_params_init(&dh_params);
   [...]
                        ldap_gnutls_need_rsa_params(ssl,&rsa_params);
   [...]
                        ldap_gnutls_need_dh_params(ssl,&dh_params);
   [...]
        }
  [...]
  if (rsa_params)
    gnutls_rsa_params_deinit(rsa_params);

  if (dh_params)
    gnutls_dh_params_deinit(dh_params);

I'm afraid, the _params_deinit functions should only be called when the
session is closed. ldap_gnutls_need_rsa_params uses
gnutls_certificate_set_{dh,rsa}_params to set the given params and
those functions only set a pointer...

Roland

[Matthias Urlichs (smurf)]

reassign 244827 slapd
thanks

Looks like it's not my problem after all ...

--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 13:34:16 +0200
From: <email address hidden> (Roland Bauerschmidt)
To: Matthias Urlichs <email address hidden>
Cc: Modestas Vainius <email address hidden>, <email address hidden>
Subject: Re: Bug#244827: libgcrypt7: more info

On Mon, Jul 19, 2004 at 05:35:36PM +0200, Matthias Urlichs wrote:
> Looks like a nicely impossible-to-find memory corruption bug. Happiness.
> Did you try to reproduce it under Electric Fence?

I have just reproduced the bug under Electric Fence. The SEGV occurs
slightly earlier:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16386 (LWP 15079)]
0x402924fe in _gcry_mpi_copy (a=0x85cfbff6) at mpiutil.c:216
216 if( a && (a->flags & 4) ) {
(gdb) bt
#0 0x402924fe in _gcry_mpi_copy (a=0x85cfbff6) at mpiutil.c:216
#1 0x40292a48 in gcry_mpi_copy (a=0x85cfbff6) at mpiutil.c:343
#2 0x401fe3fc in _gnutls_get_dh_params (dh_primes=0x6c107ff8, ret_p=0xbf7fc248, ret_g=0xbf7fc24c)
    at gnutls_dh_primes.c:45
#3 0x401fe292 in proc_dhe_client_kx (session=0x6c01c630, data=0x85cfbff6 <Address 0x85cfbff6 out of bounds>,
    _data_size=2244984822) at auth_dhe.c:268
#4 0x401ee548 in _gnutls_recv_client_kx_message (session=0x6c01c630) at gnutls_kx.c:329
#5 0x401e94c0 in _gnutls_handshake_server (session=0x6c01c630) at gnutls_handshake.c:2241
#6 0x401e8ad6 in gnutls_handshake (session=0x6c01c630) at gnutls_handshake.c:1892
#7 0x400569a7 in SSL_do_handshake (ssl=0x485d0fdc, end=GNUTLS_SERVER) at gnutls.c:627
#8 0x40056acd in gnutls_SSL_accept (ssl=0x485d0fdc) at gnutls.c:670
#9 0x40054394 in ldap_pvt_tls_accept (sb=0x6bc15fe4, ctx_arg=0x0) at tls.c:928
#10 0x08058ff0 in connection_read (s=32) at /root/tls/openldap2-2.1.30/servers/slapd/connection.c:1134
#11 0x080564ab in slapd_daemon_task (ptr=0x0) at /root/tls/openldap2-2.1.30/servers/slapd/daemon.c:1863
#12 0x40312e51 in pthread_start_thread () from /lib/libpthread.so.0
#13 0x40312ecf in pthread_start_thread_event () from /lib/libpthread.so.0
#14 0x4044969a in clone () from /lib/libc.so.6

That a->d pointed to 0x10 in a previous post doesn't seem to be the
root of failure, but rather a consequence of this:

(gdb) f 0
#0 0x402924fe in _gcry_mpi_copy (a=0x85cfbff6) at mpiutil.c:216
216 if( a && (a->flags & 4) ) {
(gdb) p *a
Cannot access memory at address 0x85cfbff6
(gdb)

The variable 'a' is the same as cred->dh_params in #3:

(gdb) f 3
#3 0x401fe292 in proc_dhe_client_kx (session=0x6c01c630, data=0x85cfbff6 <Address 0x85cfbff6 out of bounds>,
    _data_size=2244984822) at auth_dhe.c:268
268 if ( (ret=_gnutls_get_dh_params( cred->dh_params, &p, &g)) < 0) {
(gdb) p cred->dh_params
Cannot access memory at address 0x85cfbff6
(gdb)

Before, cred gets assigned the following:

auth_dhe.c:
cred = _gnutls_get_cred(session->key, GNUTLS_CRD_CERTIFICATE, NULL);

const void *_gnutls_get_cred( GNUTLS_KEY key, gnutls_credentials_type type, int *err) {
        const void *retval = NULL;
        int _err = -1;
        AUTH_CRED * ccred;

        if (key == NULL) goto out;

        ccred = key->cred;
        while(ccred!=NULL) {
                if (ccred->a...

[Debian Bug Importer (debzilla)]

Message-ID: <20040720114445.GD3379@kiste>
Date: Tue, 20 Jul 2004 13:44:46 +0200
From: "Matthias Urlichs" <email address hidden>
To: Roland Bauerschmidt <email address hidden>
Cc: Modestas Vainius <email address hidden>, <email address hidden>
Subject: Re: Bug#244827: libgcrypt7: more info

--+KJYzRxRHjYqLGl5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

Roland Bauerschmidt:
> I have just reproduced the bug under Electric Fence. The SEGV occurs
> slightly earlier:
>=20
Yes -- still not terribly helpful however, we need to find out who
releases the memory.

Sometimes it occurs still earlier:

0x40200384 in _gnutls_get_dh_params (dh_primes=3D0x486baff8, ret_p=3D0xbf7f=
c248,
    ret_g=3D0xbf7fc24c) at gnutls_dh_primes.c:37
37 if (dh_primes =3D=3D NULL || dh_primes->_prime =3D=3D NULL =
||
(gdb) whe
#0 0x40200384 in _gnutls_get_dh_params (dh_primes=3D0x486baff8,
    ret_p=3D0xbf7fc248, ret_g=3D0xbf7fc24c) at gnutls_dh_primes.c:37
#1 0x40200292 in proc_dhe_client_kx (session=3D0x484c1630,
    data=3D0x486baff8 '' <repeats 200 times>..., _data_size=3D1215016952)
    at auth_dhe.c:268
#2 0x401f0548 in _gnutls_recv_client_kx_message (session=3D0x484c1630)
    at gnutls_kx.c:329
#3 0x401eb4c0 in _gnutls_handshake_server (session=3D0x484c1630)
    at gnutls_handshake.c:2241
#4 0x401eaad6 in gnutls_handshake (session=3D0x484c1630)
    at gnutls_handshake.c:1892
#5 0x400599a7 in SSL_do_handshake (ssl=3D0x48572fdc, end=3DGNUTLS_SERVER)
    at gnutls.c:627
#6 0x40059acd in gnutls_SSL_accept (ssl=3D0x48572fdc) at gnutls.c:670

> Consequently, session->key->cred->credentials and cred should be
> *identical*. But they aren't (0x47210fb8 !=3D 0x85cfbff6):
>=20
Umm...

> (gdb) p session->key->cred->credentials
> $53 =3D (void *) 0x47210fb8
> (gdb) p cred
> $54 =3D <value optimized out>
> (gdb) p *cred
> Cannot access memory at address 0x85cfbff6

=2E.. gdb actually uses the wrong value here (optimization!), especially si=
nce
session->key->cred->credentials is accessible. Try recompiling with -O0.

You might also try the helpful

(gdb) set env EF_FREE_WIPES 1

If you do that, you see
(gdb) p *((const CERTIFICATE_CREDENTIALS_INT *)session->key->cred->credenti=
als)->dh_params
$40 =3D {_prime =3D 0xbdbdbdbd, _generator =3D 0xbdbdbdbd}

=3D> something freed the dh_params vector.

I haven't found the culprit yet.

--=20
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>

--+KJYzRxRHjYqLGl5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/QWt8+hUANcKr/kRAhlYAJ4j0sIBV5qfqupyiXK1u4xNoUY8xQCgmiNe
ztll+BNIeVAHKgm2vM+t89c=
=TLQM
-----END PGP SIGNATURE-----

--+KJYzRxRHjYqLGl5--

[Roland Bauerschmidt (bauerschmidt)]

reassign 244827 slapd
thanks

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Tue, 20 Jul 2004 15:15:33 +0300
From: Modestas Vainius <email address hidden>
To: "Matthias Urlichs" <email address hidden>
Cc: Roland Bauerschmidt <email address hidden>,
 <email address hidden>
Subject: Re: Bug#244827: libgcrypt7: more info

--Boundary-02=_wzQ/AUWO121Bn22
Content-Type: text/plain;
  charset="iso-8859-13"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Tuesday 20 July 2004 14:44, Matthias Urlichs ra=F0=EB:
> Yes -- still not terribly helpful however, we need to find out who
> releases the memory.
This is what I discovered with valgrind:

=3D=3D12898=3D=3D Thread 2:
=3D=3D12898=3D=3D Invalid read of size 4
=3D=3D12898=3D=3D at 0x3C217C4B: _gnutls_get_dh_params (gnutls_dh_primes=
=2Ec:37)
=3D=3D12898=3D=3D by 0x3C217B8E: proc_dhe_client_kx (auth_dhe.c:268)
=3D=3D12898=3D=3D by 0x3C203C36: _gnutls_recv_client_kx_message (gnutls_=
kx.c:329)
=3D=3D12898=3D=3D by 0x3C2001C2: _gnutls_handshake_server (gnutls_handsh=
ake.c:2241)
=3D=3D12898=3D=3D by 0x3C1FECA8: gnutls_handshake (gnutls_handshake.c:18=
92)
=3D=3D12898=3D=3D by 0x3C0619A6: SSL_do_handshake (gnutls.c:627)
=3D=3D12898=3D=3D by 0x3C061ACC: gnutls_SSL_accept (gnutls.c:670)
=3D=3D12898=3D=3D by 0x3C05F393: ldap_pvt_tls_accept (tls.c:928)
=3D=3D12898=3D=3D by 0x8058FEF: connection_read (in /mnt/user/usr/sbin/s=
lapd)
=3D=3D12898=3D=3D by 0x80564AA: (within /mnt/user/usr/sbin/slapd)
=3D=3D12898=3D=3D Address 0x3C510FE0 is 0 bytes inside a block of size 8 f=
ree'd
=3D=3D12898=3D=3D at 0x3C01F918: free (vg_replace_malloc.c:127)
=3D=3D12898=3D=3D by 0x3C2182C9: gnutls_dh_params_deinit (gnutls_dh_prim=
es.c:229)
=3D=3D12898=3D=3D by 0x3C061AA2: SSL_do_handshake (gnutls.c:662)
=3D=3D12898=3D=3D by 0x3C061ACC: gnutls_SSL_accept (gnutls.c:670)
=3D=3D12898=3D=3D by 0x3C05F393: ldap_pvt_tls_accept (tls.c:928)
=3D=3D12898=3D=3D by 0x8058FEF: connection_read (in /mnt/user/usr/sbin/s=
lapd)
=3D=3D12898=3D=3D by 0x80564AA: (within /mnt/user/usr/sbin/slapd)
=3D=3D12898=3D=3D by 0x3C34B110: thread_wrapper (vg_libpthread.c:837)
=3D=3D12898=3D=3D by 0xB800FACC: do__quit (vg_scheduler.c:1792)

--Boundary-02=_wzQ/AUWO121Bn22
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA/QzwHO9JRnPq4hQRAm9oAJ4h5hXsFRtlP8XwiIpC7oV75Iq5GwCcCVug
XLhwlkMjRPY9HrFub+uO4UU=
=IJL2
-----END PGP SIGNATURE-----

--Boundary-02=_wzQ/AUWO121Bn22--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 14:20:15 +0200
From: <email address hidden> (Roland Bauerschmidt)
To: Matthias Urlichs <email address hidden>
Cc: Modestas Vainius <email address hidden>, <email address hidden>
Subject: Re: Bug#244827: libgcrypt7: more info

On Tue, Jul 20, 2004 at 01:44:46PM +0200, Matthias Urlichs wrote:
> => something freed the dh_params vector.
>
> I haven't found the culprit yet.

I think I might've found it (though not verified yet). In gnutls.c
(OpenLDAP code), SSL_do_handshake:

 [...]
        if (!ssl->session) {
   [...]
                        gnutls_error = gnutls_rsa_params_init(&rsa_params);
   [...]
                        gnutls_error = gnutls_dh_params_init(&dh_params);
   [...]
                        ldap_gnutls_need_rsa_params(ssl,&rsa_params);
   [...]
                        ldap_gnutls_need_dh_params(ssl,&dh_params);
   [...]
        }
  [...]
  if (rsa_params)
    gnutls_rsa_params_deinit(rsa_params);

  if (dh_params)
    gnutls_dh_params_deinit(dh_params);

I'm afraid, the _params_deinit functions should only be called when the
session is closed. ldap_gnutls_need_rsa_params uses
gnutls_certificate_set_{dh,rsa}_params to set the given params and
those functions only set a pointer...

Roland

[Debian Bug Importer (debzilla)]

Message-ID: <20040720124113.GE3379@kiste>
Date: Tue, 20 Jul 2004 14:41:13 +0200
From: "Matthias Urlichs" <email address hidden>
To: <email address hidden>
Subject: OK, so it's slapd after all

--tVmo9FyGdCe4F4YN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

reassign 244827 slapd
thanks

Looks like it's not my problem after all ...

--=20
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>

--tVmo9FyGdCe4F4YN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/RLp8+hUANcKr/kRAkSFAJ4l8O06HOOGKat6Q+qugol7k+6vnQCbBoFt
1gRgvzQX/YjDHJPGh91AS14=
=OW2G
-----END PGP SIGNATURE-----

--tVmo9FyGdCe4F4YN--

[Roland Bauerschmidt (bauerschmidt)]

tags 244827 +pending
thanks

Fixed in SVN.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 15:47:47 +0200
From: <email address hidden> (Roland Bauerschmidt)
To: <email address hidden>
Subject: Re: Bug#244827: Info received (was Bug#244827: libgcrypt7: more info)

reassign 244827 slapd
thanks

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 16:13:53 +0200
From: <email address hidden> (Roland Bauerschmidt)
To: <email address hidden>
Subject: Fixed in SVN

tags 244827 +pending
thanks

Fixed in SVN.

[Matt Zimmerman (mdz)]

Patch in SVN:

http://svn.debian.org/viewcvs/pkg-openldap?view=rev&rev=323

[Matt Zimmerman (mdz)]

I don't have time for this tonight; Fabio, please take a look in the morning, it
should be straightforward to fix in Warty

[Fabio Massimo Di Nitto (fabbione)]

Bug fixed for us with openldap2_2.1.30-2ubuntu1 upload.

[Fabio Massimo Di Nitto (fabbione)]

Fix in rev323 was not complete. backport from r326 and upload as
openldap2_2.1.30-2ubuntu2

[Roland Bauerschmidt (rb)]

Source: openldap2
Source-Version: 2.1.30-3

We believe that the bug you reported is fixed in the latest version of
openldap2, which is due to be installed in the Debian FTP archive:

ldap-utils_2.1.30-3_i386.deb
  to pool/main/o/openldap2/ldap-utils_2.1.30-3_i386.deb
libldap2-dev_2.1.30-3_i386.deb
  to pool/main/o/openldap2/libldap2-dev_2.1.30-3_i386.deb
libldap2_2.1.30-3_i386.deb
  to pool/main/o/openldap2/libldap2_2.1.30-3_i386.deb
libslapd2-dev_2.1.30-3_all.deb
  to pool/main/o/openldap2/libslapd2-dev_2.1.30-3_all.deb
openldap2_2.1.30-3.diff.gz
  to pool/main/o/openldap2/openldap2_2.1.30-3.diff.gz
openldap2_2.1.30-3.dsc
  to pool/main/o/openldap2/openldap2_2.1.30-3.dsc
slapd_2.1.30-3_i386.deb
  to pool/main/o/openldap2/slapd_2.1.30-3_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Roland Bauerschmidt <email address hidden> (supplier of updated openldap2 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Mon, 26 Jul 2004 18:41:23 +0200
Source: openldap2
Binary: libslapd2-dev slapd libldap2 ldap-utils libldap2-dev
Architecture: source i386 all
Version: 2.1.30-3
Distribution: unstable
Urgency: high
Maintainer: Torsten Landschoff <email address hidden>
Changed-By: Roland Bauerschmidt <email address hidden>
Description:
 ldap-utils - OpenLDAP utilities
 libldap2 - OpenLDAP libraries
 libldap2-dev - OpenLDAP development libraries
 libslapd2-dev - OpenLDAP slapd back-end development headers
 slapd - OpenLDAP server (slapd)
Closes: 244827
Changes:
 openldap2 (2.1.30-3) unstable; urgency=high
 .
   * Urgeny high since previous releases were hardly usable (at least
     with TLS).
   * Roland Bauerschmidt <email address hidden>
     + libraries/libldap/gnutls.c, libraries/libldap/tls.c,
       include/ldap_pvt_gnutls.h: Use callback with
       gnutls_certificate_set_params_function to generate dh_params and
       rsa_params (this is also the way, it's done with OpenSSL). We need
       GNUTLS 1.0.9 for this. With the new version of libgcrypt, we also
       need to initialize threading explicitly. The previous
       segmentation faults resulted from the *global* param structure
       being recreated and freed for every session. Many thanks to
       Matthias Urlichs who helped debugging a lot and also packaged
       GNUTLS 1.0.16 very quickly... Closes: #244827.
     + debian/control: Add build dependency to libgcrypt11-dev (we're
       initializing it directly now) and change libgnutls10-dev to
       libgnutls11-dev.
     + libraries/libldap/gnutls.c: in tls_gnutls_need_{dh,rsa}_params
       (formerly ldap_gnutls_need_...), create temp files more securely,
       doing unlink before opening and opening them with O_EXCL. This is
       necessary because under Linux 2....

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Tue, 27 Jul 2004 02:32:05 -0400
From: Roland Bauerschmidt <email address hidden>
To: <email address hidden>
Subject: Bug#244827: fixed in openldap2 2.1.30-3

Source: openldap2
Source-Version: 2.1.30-3

We believe that the bug you reported is fixed in the latest version of
openldap2, which is due to be installed in the Debian FTP archive:

ldap-utils_2.1.30-3_i386.deb
  to pool/main/o/openldap2/ldap-utils_2.1.30-3_i386.deb
libldap2-dev_2.1.30-3_i386.deb
  to pool/main/o/openldap2/libldap2-dev_2.1.30-3_i386.deb
libldap2_2.1.30-3_i386.deb
  to pool/main/o/openldap2/libldap2_2.1.30-3_i386.deb
libslapd2-dev_2.1.30-3_all.deb
  to pool/main/o/openldap2/libslapd2-dev_2.1.30-3_all.deb
openldap2_2.1.30-3.diff.gz
  to pool/main/o/openldap2/openldap2_2.1.30-3.diff.gz
openldap2_2.1.30-3.dsc
  to pool/main/o/openldap2/openldap2_2.1.30-3.dsc
slapd_2.1.30-3_i386.deb
  to pool/main/o/openldap2/slapd_2.1.30-3_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Roland Bauerschmidt <email address hidden> (supplier of updated openldap2 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Mon, 26 Jul 2004 18:41:23 +0200
Source: openldap2
Binary: libslapd2-dev slapd libldap2 ldap-utils libldap2-dev
Architecture: source i386 all
Version: 2.1.30-3
Distribution: unstable
Urgency: high
Maintainer: Torsten Landschoff <email address hidden>
Changed-By: Roland Bauerschmidt <email address hidden>
Description:
 ldap-utils - OpenLDAP utilities
 libldap2 - OpenLDAP libraries
 libldap2-dev - OpenLDAP development libraries
 libslapd2-dev - OpenLDAP slapd back-end development headers
 slapd - OpenLDAP server (slapd)
Closes: 244827
Changes:
 openldap2 (2.1.30-3) unstable; urgency=high
 .
   * Urgeny high since previous releases were hardly usable (at least
     with TLS).
   * Roland Bauerschmidt <email address hidden>
     + libraries/libldap/gnutls.c, libraries/libldap/tls.c,
       include/ldap_pvt_gnutls.h: Use callback with
       gnutls_certificate_set_params_function to generate dh_params and
       rsa_params (this is also the way, it's done with OpenSSL). We need
       GNUTLS 1.0.9 for this. With the new version of libgcrypt, we also
       need to initialize threading explicitly. The previous
       segmentation faults resulted from the *global* param structure
       being recreated and freed for every session. Many thanks to
       Matthias Urlichs who helped debugging a lot and also packaged
       GNUTLS 1.0.16 very quickly... Closes: #244827.
     + debian/control: Add build dependency to libgcrypt11-dev (we're
       initializing it directly now) and change libgnutls10-dev to
       libgnutls11-dev.
     + libraries/libldap/gnutls.c: in tls...