userPassword Support not available, because it is not build with libssl-dev

[Herbert Straub]

The support for userPassword fields is only available with the libssl-dev package. I corrected the package with this patch:

--- debian/control.orig 2006-01-10 21:34:44.000000000 +0100
+++ debian/control 2006-01-10 21:34:54.000000000 +0100
@@ -2,7 +2,7 @@
 Section: net
 Priority: optional
 Maintainer: Guido Trotter <email address hidden>
-Build-Depends: debhelper (>= 4.0.0), dpatch, libgtk2.0-dev, libldap2-dev, libkrb5-dev, libxml2-dev
+Build-Depends: debhelper (>= 4.0.0), dpatch, libgtk2.0-dev, libldap2-dev, libkrb5-dev, libxml2-dev, libssl-dev
 Standards-Version: 3.6.2.1

 Package: gq

After recompiling the package, the userPassword support is available (drop down menu with encryption methods). This package is available on: http://apt-get.linuxhacker.at/ubuntu/dists/breezy/universe/pool/gq_1.0beta1-4hs1_i386.changes

It would be nice, if the next Ubuntu version would contain the userPassword support.

Thanks
Herbert Straub

[Herbert Straub (herbert)]

The support for userPassword fields is only available with the libssl-dev package. I corrected the package with this patch:

--- debian/control.orig 2006-01-10 21:34:44.000000000 +0100
+++ debian/control 2006-01-10 21:34:54.000000000 +0100
@@ -2,7 +2,7 @@
 Section: net
 Priority: optional
 Maintainer: Guido Trotter <email address hidden>
-Build-Depends: debhelper (>= 4.0.0), dpatch, libgtk2.0-dev, libldap2-dev, libkrb5-dev, libxml2-dev
+Build-Depends: debhelper (>= 4.0.0), dpatch, libgtk2.0-dev, libldap2-dev, libkrb5-dev, libxml2-dev, libssl-dev
 Standards-Version: 3.6.2.1

 Package: gq

After recompiling the package, the userPassword support is available (drop down menu with encryption methods). This package is available on: http://apt-get.linuxhacker.at/ubuntu/dists/breezy/universe/pool/gq_1.0beta1-4hs1_i386.changes

It would be nice, if the next Ubuntu version would contain the userPassword support.

Thanks
Herbert Straub

[Herbert Straub (herbert)]

I think the remote bug watch to debbugs #329312 hits another problem. I try to build gq with --enable-sasl and the dependency to libsasl2-dev, but the drop down menu for password encryption is not available.

I have two screenshots on my homepage to show the effect, if the package is build with openssl-dev is available and not available.

I think, the configure.in contains the relevant location:
dnl We require libcrypto for the dt_password DISPLAYTYPE handler ... peter
dnl If we do not find it, we do not enable DISPLAYTYPE_PASSWORD

AC_CHECK_LIB(crypto, OpenSSL_add_all_digests)

And the dt_password.c contains the code.

Thanks
Herbert Straub

[Herbert Straub (herbert)]

Yes an i forgot the URI for the screenshots:

https://info.linuxhacker.at/wiki/BreezyGQAndUserPasswrd

[Benjamin Montgomery (bmonty)]

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

Guido,
I'm working on a bug that was reported in the Ubuntu bug tracker[1]
regarding encryption of userPassword entries. I have also been using a
local package of gq that is built with libsasl2. I have been using my
package of gq to do GSSAPI binds with my ldap server. It also appears
that the userPassword encryption works correctly. I looked through the
BTS and noticed that you have disabled these features on purpose, but
I'm not clear on the reason why. Are there problems with these features?

A related issue is that of linking against OpenSSL. It seems the
authors of gq have allowed an exception to the GPL to get around the
OpenSSL license issues described here [2]. I think if the features that
OpenSSL enables work correctly, the OpenSSL attribution statement needs
to be added to the copyright file.

What are your thoughts on making these changes to the gq package?

Ben

[1] https://launchpad.net/distros/ubuntu/+source/gq/+bug/6629
[2] http://www.gnome.org/~markmc/openssl-and-the-gpl.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD0cAr14/jLHK8klURAjsYAKCyV3tIgzRRfwxyASH+NiODvnR+7ACff2oi
7F07tYyBDyp/65iVcY5G3w8=
=owjB
-----END PGP SIGNATURE-----

[Benjamin Montgomery (bmonty)]

Subject: Re: SASL and OpenSSL with gq
Date: Sat, 21 Jan 2006 12:53:47 +0100
From: Guido Trotter <email address hidden>
To: Benjamin Montgomery <email address hidden>
References: <email address hidden>

On Fri, Jan 20, 2006 at 11:01:31PM -0600, Benjamin Montgomery wrote:

Hi,

> Guido,
> I'm working on a bug that was reported in the Ubuntu bug tracker[1]
> regarding encryption of userPassword entries. I have also been using a
> local package of gq that is built with libsasl2. I have been using my
> package of gq to do GSSAPI binds with my ldap server. It also appears
> that the userPassword encryption works correctly. I looked through the
> BTS and noticed that you have disabled these features on purpose, but
> I'm not clear on the reason why. Are there problems with these features?
>

Yeah, upstream (when he was still active) esplicitely said they were
completely
broken and unsupported... So I preferred to disable them!

> A related issue is that of linking against OpenSSL. It seems the
> authors of gq have allowed an exception to the GPL to get around the
> OpenSSL license issues described here [2]. I think if the features that
> OpenSSL enables work correctly, the OpenSSL attribution statement needs
> to be added to the copyright file.
>

That can surely be done! No problem!

Ciao,

Guido

[Benjamin Montgomery (bmonty)]

Guido Trotter wrote:
>>I'm working on a bug that was reported in the Ubuntu bug tracker[1]
>>regarding encryption of userPassword entries. I have also been using a
>>local package of gq that is built with libsasl2. I have been using my
>>package of gq to do GSSAPI binds with my ldap server. It also appears
>>that the userPassword encryption works correctly. I looked through the
>>BTS and noticed that you have disabled these features on purpose, but
>>I'm not clear on the reason why. Are there problems with these features?
>
> Yeah, upstream (when he was still active) esplicitely said they were completely
> broken and unsupported... So I preferred to disable them!

Just to make sure, you are refering to both the OpenSSL and SASL
features? Did upstream give examples of what was broken?

Have you done any testing with the userPassword encryption turned on?
Do you know if it produces the correct output? I can verify that SASL
GSSAPI binds work correctly on my network.

>>A related issue is that of linking against OpenSSL. It seems the
>>authors of gq have allowed an exception to the GPL to get around the
>>OpenSSL license issues described here [2]. I think if the features that
>>OpenSSL enables work correctly, the OpenSSL attribution statement needs
>>to be added to the copyright file.
>
> That can surely be done! No problem!

This isn't an issue if the OpenSSL code in gq is broken and not enabled.

[Benjamin Montgomery (bmonty)]

Herbert, can you do testing with the userPassword encryption and see if it generates the correct output? I'm not sure how this feature is supposed to work and I don't really have a good way to test. If you need a gq package with this feature enabled, let me know and I'll make it available to you.

[Benjamin Montgomery (bmonty)]

Guido Trotter wrote:
> I haven't tried because I use normal binding, on an SSL or TSL encrypted
> connection, which is perfectly fine security wise, and even better than
a SASL
> bind, from my point of view, as it protects the whole connection and not
only
> the password.

I'm using ldaps with a GSSAPI SASL bind. The passwords are stored in
kerberos and SASL uses kerberos tickets to grant access. This works
without problems. I haven't tried the other SASL methods. This is why
I was wondering what parts are broken, because SASL binds seem to work
correctly. My LDAP server is configured to not allow access unless the
request is authenticated with an appropriate kerberos ticket. I mostly
have it set up to provide a LDAP+Kerberos single sign on capability.

> You say the sasl works only with unencrypted passwords... are you sure
it's not
> *supposed* to behave that way? Thinking about it: if your password is
> transmitted over the wire then the LDAP server on the other end of the
> connection can use whichever hashing tecnique it has used to encrypt the
> password to verify its correctnes... On the other hand if the password
is used
> as a shared secret to provide some kind of challenge response
authentication how
> can the server actually do its work without *knowing* the secret himself
(rather
> than some one-way-encrypted version of it). It seems to be the same
tradeoff
> there is between PPP CHAP and PAP authentication.
>
> Anyway just to be sure it's not a gq issue: why don't you ask the user who
> complained to try binding to the same account with the command-line
ldapsearch
> and see if that works or not? If it doesn't it's probably not gq's fault!

The problem is not with binding. We are looking at the userPassword
field in an LDAP record. With the correct build-deps gq can handle
hashing passwords before they are sent to the server. You can tell if
this feature is enabled if there is a drop-down menu next to the
userPassword text entry box that allows you to pick a hash.

I had to add libsasl2-dev and libssl-dev to the build-deps in order to
enable the userPassword hash functionality and the ability to do a SASL
bind.

I've asked the orginal bug reporter to do some testing on the
userPassword hash functions and update the ubuntu bug report if gq
performs the hashes correctly.

At a minimum I think it makes sense to add libssl-dev to the build-deps
and update the copyright file. I can say that GSSAPI SASL binds work,
but I don't have the capability to check other types of SASL binds right
now. It probably is best to leave that feature disabled. Maybe we
could add to the README.Debian that SASL is untested and how to enable
it by building a local package?

Ben

--
Benjamin Montgomery
<email address hidden>

[Herbert Straub (herbert)]

Hallo Benjamin,

yes i'm sure, that the userPassword works with the encryption functionality. My test configuration: the ldap server with simple bind and a uw-imapd server with pam_ldap authentication and the accounts are stored in the ldap server. If i'm setup the password from the testaccount with the gq: i can log in via Thunderbird. And i'm trying to setup another password with gq and a encryption methond (sha, crypt, md5) and i have to use this new password in Thunderbird to login.

I'm sure, that this construct works long time ago, because i'm setup this environment one year ago under Suse Linux with Ldap and gq. Under Suse, the gq displays the encryption function on userPassword since one year(i think). I'm wondering why this encryption function is not available in Debian/Ubuntu. Now i'm pretty sure, that this is only the failing openssl-dev library on compile time, because i cannot see any other patches in the Suse package. I'm don't using GSSAPI only simple with TLS.

Second i try to setup the userPassword for the administrator accounts (example for bind dn: cn=administrator,dc=foo,dc=bar) and using the encryption method: sha and i can successfully login with the ldapsearch command.

I'm sure, this works and helps the administrator to working with encrypted userPassword fields with gq.

Thanks
Herbert Straub

[Philipp Hahn (pmhahn)]

Package: gq
Version: 1.0beta1-4
Followup-For: Bug #242532

You can convert your PEM-encouded certificates and revocation lists to
DER-encoding with "openssl" using
 openssl x509 -in my-crt.pem -outfrom der -out my-crt.der
 openssl crl -in my-crl.pem -outform der -out my-crl.der
Importing those work fine for me.
So this is not an "important bug", but a "whishlist" request for adding
an import filter mechanism for automatic conversion.

Also remeber, that those attributes must be DER-encoded and not
PEM-encoded, so GQ is actually right to prohibit you from importing a
PEM text string.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (989, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.11-walker
Locale: LANG=de_DE.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages gq depends on:
ii libatk1.0-0 1.11.4-1 The ATK accessibility toolkit
ii libc6 2.3.6-7 GNU C Library: Shared libraries
ii libglib2.0-0 2.10.2-1 The GLib library of C routines
ii libgtk2.0-0 2.8.17-1 The GTK+ graphical user interface
ii libldap2 2.1.30-13 OpenLDAP libraries
ii libpango1.0-0 1.12.1-2 Layout and rendering of internatio
ii libssl0.9.7 0.9.7i-1 SSL shared libraries
ii libxml2 2.6.23.dfsg.2-3 GNOME XML library
ii zlib1g 1:1.2.3-11 compression library - runtime

gq recommends no packages.

-- no debconf information

[Sven Herzberg (herzi)]

Hi guys,

  please build GQ with build-dep libssl-dev. Then this gets available
within GQ's GUI.

Regards,
  Sven

[Guido Trotter (ultrotter)]

On Wed, May 24, 2006 at 01:01:28PM +0200, Sven Herzberg wrote:

Hi!

> Hi guys,
>
> please build GQ with build-dep libssl-dev. Then this gets available
> within GQ's GUI.
>

Can we do so? Isn't there the GPL/Openssl licence compatibility problem?

Guido

[Guido Trotter (ultrotter)]

Source: gq
Source-Version: 1.0.0-3

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

gq_1.0.0-3.diff.gz
  to pool/main/g/gq/gq_1.0.0-3.diff.gz
gq_1.0.0-3.dsc
  to pool/main/g/gq/gq_1.0.0-3.dsc
gq_1.0.0-3_i386.deb
  to pool/main/g/gq/gq_1.0.0-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.
Guido Trotter <email address hidden> (supplier of updated gq 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: Thu, 25 May 2006 08:30:24 +0000
Source: gq
Binary: gq
Architecture: source i386
Version: 1.0.0-3
Distribution: unstable
Urgency: low
Maintainer: Guido Trotter <email address hidden>
Changed-By: Guido Trotter <email address hidden>
Description:
 gq - GTK-based LDAP client
Closes: 242532
Changes:
 gq (1.0.0-3) unstable; urgency=low
 .
   * Build-Depend on libssl-dev (closes: #242532)
   * Update copyright file stating the openssl linking exception
     present in the upstream one
   * Upgrade standards-version
Files:
 ff1a9b2e916435cb7a77d9b735297262 636 net optional gq_1.0.0-3.dsc
 3dc8293596ea7668713fdd84a1b7b1c3 30716 net optional gq_1.0.0-3.diff.gz
 17ace8fa8304ff4f121c8dea40b80f03 199818 net optional gq_1.0.0-3_i386.deb

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

iD8DBQFEda1zhImxTYgHUpsRAogaAJ0UhJQMPBESI1extQhsbeCELy8v0QCdEdBR
krDY1Jdwyd/d+gSfSGhl4iw=
=NT2M
-----END PGP SIGNATURE-----

[Herbert Straub (herbert)]

I build gq 1.0.0-2ubuntu1hs1 for dapper with selectable encryption mechanism for userPassword -> add libssl-dev to BuildDepends. Works fine on Dapper.

http://apt-get.linuxhacker.at/ubuntu/dists/dapper/universe/pool/gq_1.0.0-2ubuntu1hs1_i386.changes

The 1.0.0-3ubuntu1 version for edgy will contains the build dependency libssl-dev. Next time, i will test this version on edgy.

Thanks
Herbert Straub

[Sven Herzberg (herzi)]

As Debian (and thus Ubuntu) are afraid of linking against libssl-dev, I just added support for hashing with libgcrypt (instead of libcrypto) in GQ trunk.

Unfortunately I'm quite busy right now, and I only added MD5 for the libgcrypt build.

It would be very great if someone went ahead to implement the missing hash mechanisms with libgcrypt on GQ trunk. Please contact me if you're intested in getting this complete for GQ 1.2 (targeted for mid-september).

[Benjamin Montgomery (bmonty)]

Sven,
Can you please post a patch with your changes to this bug?

Thanks,
Ben

[Sven Herzberg (herzi)]

I can't because, because GQ 1.1 has had a lot of incompatible changes to GQ 1.0.0, so backporting isn't trivial.

BTW, and I don't think it makes sense to add extra workload to backport a feature that will be released next month.

[Benjamin Montgomery (bmonty)]

Sven Herzberg wrote:

> I can't because, because GQ 1.1 has had a lot of incompatible changes to
> GQ 1.0.0, so backporting isn't trivial.

OK, I didn't realize that upstream development had restarted.

> BTW, and I don't think it makes sense to add extra workload to backport
> a feature that will be released next month.

I agree! Once the new version is released we will have to update the
package in Ubuntu edgy via an upstream version freeze exception request.

Ben

--
Benjamin Montgomery <email address hidden>

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[Sven Herzberg (herzi)]

This is fixed with the lastest release of GQ (1.2.0), please rebuild this one (and add libgcrypt-dev to the build-depends to automatically detect it).

[Sven Herzberg (herzi)]

Will we get the updated 1.2.0 for edgy?

[Herbert Straub (herbert)]

This bug can be closed, because it is fixed in edgy. I installed gq 1.0.0-3ubuntu1 and now i can select the hash in the userpassword field. The debian changelog:

gq (1.0.0-3) unstable; urgency=low
  * Build-Depend on libssl-dev (closes: #242532)