[Pkg-xmpp-devel] Bug#776847: gsasl 1.8.0-6 does not support GSSAPI

[Simon Josefsson]

Morgan, could you please test 'gsasl' from experimental?  It should fix
the GSSAPI issue you reported in #768352.  If you can confirm, I can
upload to unstable -- I'm hoping it is possible to fix this before the
release.

> On Mon, Feb 16, 2015 at 11:38:46PM +0100, Simon Josefsson wrote:
> > > On 16/02/15 22:13, Simon Josefsson wrote:
> > > > It seems clear that the #745332 fix was incorrect.  You can see
> > > > in the build logs GSSAPI is not enabled since krb5-config isn't
> > > > found:
> > > >
> > > > https://buildd.debian.org/status/fetch.php?pkg=gsasl&arch=amd64&ver=1.8.0-6&stamp=1412611018
> > > >
> > > > On considering solutions, I don't like the unpredictability in
> > > > depending on libkrb5-dev|libheimdal-dev.  The GSSAPI library
> > > > used by the binary libgsasl package in Debian will depend on
> > > > whether the buildds have Heimdal or MIT installed when you
> > > > built the package. Coping with different GSS libraries on
> > > > different architecture sounds like a recipe for disaster.  For
> > > > Jessie, gsasl should be built against the same Kerberos library
> > > > on all architectures, unless there is a reason not to -- and I
> > > > don't know of a reason. MIT is picked arbitrarily here.
> > > >
> > > > Cc'ing Jelmer (who reported 745332) and Andreas (who uploaded
> > > > it) -- any comments?  Jelmer, what prompted your initial
> > > > report?  The way I see it, it is important (for us) that you
> > > > buildds don't have multiple Kerberos development packages
> > > > installed when they build gsasl.  So the old way was the
> > > > preferred way, causing heimdal-dev to be removed and
> > > > libkrb5-dev to be pulled in.  People with other preferences who
> > > > build their own packages can surely modify the gsasl package to
> > > > their liking.
> > > >
> > > > I've pushed a fix in git and attmpted to upload to
> > > > experimental, so you can test the new packages.
> > > The main reason for proposing this change was just to make it
> > > easier to have heimdal-dev installed while working on other parts
> > > of the system. At the moment, building gsasl requires
> > > uninstalling a number of packages for me, that indirectly depend
> > > on heimdal-dev.
> > > 
> > > With the patch, the intent was to gsasl still build against MIT
> > > kerberos
> > > - e.g. no change in the binary packages. It merely changed the
> > > dependency from libkrb5-dev to libkrb5-multidev, the latter of
> > > which doesn't prevent heimdal-dev from being installed.
> > 
> > Right -- but the patch also had the consequence of completely
> > disabling GSSAPI in gsasl.  Reverting the patch makes GSSAPI work
> > again.
> FWIW the patch applied to the Debian package was different from the
> one I provided with the original bug report. 
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=0001-Depend-on-krb5-multidev-rather-than-libkrb5-dev.patch;att=1;bug=745332)
> 
> The upload that closed this bug just changes the dependency
> from libkrb5-dev to libkrb5-multidev (rather than krb5-multidev)
> and doesn't set KRB5_CONFIG.
> (http://anonscm.debian.org/cgit/pkg-xmpp/gsasl.git/commit/?id=1bbeb7bc1e9404daaf1cdef64ec382794a77b217)

Yeah, I made a typo in the first upload, and I thought Andreas fixed
that but now that I look I see that the rest of your patch was not
merged.  Oops.

> > > Anyway, as you say, I can manually patch gsasl if I need to, and
> > > at the moment I don't work on any packages that depend on
> > > libgsasl-dev. I still think it would be nice to not have gsasl
> > > conflict with heimdal-dev, but it's not the end of the world if
> > > it doesn't.
> > 
> > Maybe libkrb5-dev|heimdal-dev is a better build-dep -- but I don't
> > know what holds for Debian buildds: are they allowed to have some
> > packages pre-installed?  If they can never have heimdal-dev
> > installed (or for some other reason prefer heimdal-dev over
> > libkrb5-dev), I don't see a problem using libkrb5-dev|heimdal-dev
> > instead of libkrb5-dev.  But if there are no guarantees, I prefer
> > hard-coding libkrb5-dev to avoid linking with different Kerberos
> > libraries depending on Debian architecture.  Does anyone know?
> 
> heimdal and MIT kerberos have enough differences in behaviour that I 
> think allowing to build against build is likely to cause unexpected
> behaviour for users. MIT and Heimdal support different settings in
> krb5.conf, for example.
> 
> gsasl also currently doesn't build against heimdal-dev:
> /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H
> -I. -I..  -I../intl -D_FORTIFY_SOURCE=2 -fvisibility=hidden -g -O2
> -fstack-protector-strong -Wformat -Werror=format-security -Wall -c -o
> gss-extra.lo gss-extra.c libtool: compile:  gcc -DHAVE_CONFIG_H -I.
> -I.. -I../intl -D_FORTIFY_SOURCE=2 -fvisibility=hidden -g -O2
> -fstack-protector-strong -Wformat -Werror=format-security -Wall -c
> gss-extra.c  -fPIC -DPIC -o .libs/gss-extra.o In file included
> from /usr/include/gssapi.h:39:0, from gss-extra.h:30, from
> gss-extra.c:28: gss-extra.c:43:9: error: expected identifier or '('
> before '&' token gss_OID GSS_C_NT_HOSTBASED_SERVICE = &tmp; ^
> 
> For exactly this reason, cyrus sasl builds modules against both
> heimdal and MIT kerberos (libsasl2-modules-gssapi-heimdal and
> libsasl2-modules-gssapi-mit).

This would be nice -- but I'm not sure it is possible with gsasl, it
doesn't dlopen() modules but everything is linked in directly.  So maybe
libgsasl-mit and libgsasl-heimdal would be needed?  Not perfectly
flexible, since users cannot chose which to use since applications will
need to depend and be built against one of them.  Maybe something to
explore after jessie.

> This late in the release cycle, it's probably safest to go back to
> just depending on libkrb5-dev.

Yeah.  Sorry about this mess.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signatur
URL: <http://lists.alioth.debian.org/pipermail/pkg-xmpp-devel/attachments/20150218/0701ac64/attachment-0001.sig>