Bugzilla Bug 185899

Heimdal version 1.0 is out.  0.7.2 is the latest in the tree.  This update is
important because it adds support for NTLM, SPNEGO stuff, and PKINIT (great for
smartcard users).  KCM is also a nice feature.

Reproducible: Always

Created an attachment (id=125369) [edit]
heimdal-1.0.ebuild

Ebuild, tested on x86 - note that this DOESN'T address any of the
heimdal-prefix-changing stuff going on in other bugs.  I agree that symlinks in
/usr/include need to be altered or heimdal should be moved to a new prefix, but
this ebuild works for me (although cyrus-sasl won't build against it unless
you're clever with those symlinks - hint: try ln -s heimdal/gssapi gssapi and
ln -s gssapi/gssapi.h gssapi.h, then link the things it complains about).

*** Bug 152460 has been marked as a duplicate of this bug. ***

Created an attachment (id=125370) [edit]
heimdal-1.0-gentoo-patches-0.1.tar.bz2

Some patches were included/fixed upstream, and this adds a heimdal-kcm init
script.  By the way, the ebuild gets rid of the sample password checker as it's
broken.

Thanks!

I had some trouble switching from mit-krb5 to heimdal-1.0 using this ebuild.
It seems that app-crypt/libgssapi conflict with heimdal. What I had to do was
emerge -C mit-krb5 and libgssapi, emerge heimdal, then revdep-rebuild (which
recompiled samba, openssh, gnome-vfs and other things).

please add a !app-crypt/libgssapi to the DEPEND to specify that it conflicts.

I haven't actually USED it yet :) but it compiled and seems to work except for
nfs-utils which I had to set USE=-kerberos for to make even compile... Now
that's not a big problem for me since I don't use nfs here but I guess it's a
showstopper for many..

(In reply to comment #4)
> Thanks!
> 
> I had some trouble switching from mit-krb5 to heimdal-1.0 using this ebuild.
> It seems that app-crypt/libgssapi conflict with heimdal. What I had to do was
> emerge -C mit-krb5 and libgssapi, emerge heimdal, then revdep-rebuild (which
> recompiled samba, openssh, gnome-vfs and other things).
> 
> please add a !app-crypt/libgssapi to the DEPEND to specify that it conflicts.
> 
> I haven't actually USED it yet :) but it compiled and seems to work except for
> nfs-utils which I had to set USE=-kerberos for to make even compile... Now
> that's not a big problem for me since I don't use nfs here but I guess it's a
> showstopper for many..
> 

On my portage tree, nfs-utils is marked as explicitly depending on mit-krb5 and
libgssapi when USE=kerberos.  So unless you explicitly edited the ebuild, you
shouldn't have been able to get a compile-time failure.

I'll take a look at compiling nfs-utils against Heimdal 1.0; I never used
kerberized NFS because I use OpenAFS instead.

Thanks for the heads-up on libgssapi conflicts - Heimdal doesn't need that
library as it has all its functionality and more integrated already (NTLM
support, etc).

(In reply to comment #5)
> On my portage tree, nfs-utils is marked as explicitly depending on mit-krb5
> and libgssapi when USE=kerberos.  So unless you explicitly edited the ebuild,
> you shouldn't have been able to get a compile-time failure.

nfs-utils depends on mit-krb5, but libgssapi doesn't, so you can still break
your system by simply emerging libgssapi for any reason like e.g. trying to
compile nsf-utils manually, using other gssapi mechanisms, because of switched
kerberos implementation, or whatever.

> I'll take a look at compiling nfs-utils against Heimdal 1.0; I never used
> kerberized NFS because I use OpenAFS instead.

Cross reference: bug 134064 comment 15 and following

> Thanks for the heads-up on libgssapi conflicts - Heimdal doesn't need that
> library as it has all its functionality and more integrated already (NTLM
> support, etc).

The libgssapi conflict is not new, I reported bug 168509 for it. It has
implications on nss_ldap using gssapi as well, so it's not only nfs affected.

If Heimdal doesn't need this library, what does this mean for programs that
currently link against the libgssapi from heimdal? Should they link against
some other library from the heimdal installation, or should depend on and link
against the libgssapi used for nfs?

(In reply to comment #6)

I was wrong - nfs-utils does require libgssapi's libgssapi.so.2.  I'm pretty
sure that the functionality it uses is present in Heimdal too, but the code
isn't written to make use of it.

I've just thrown together a Heimdal 1.0 build that installs libs to
/usr/heimdal/lib and includes to /usr/heimdal/include (as well as setting
prefix to /usr so krb5-config --prefix works).  I was able to build cyrus-sasl
and openssh against the newly located Heimdal without trouble after adding
/etc/env.d/heimdal with an extra line for /etc/ld.so.conf.

It seems that nfs-utils' check for Kerberos versions is actually broken -
something's wrong with aclocal/kerberos5.m4 which I couldn't figure out.  But
I've got a patch that hacks around it.  But that doesn't solve the problem of
needing to use /usr/lib/libgssapi.so.2 for nfs-utils and
/usr/heimdal/lib/libgssapi.so.2 for everything else, while still letting
nfs-utils make use of Heimdal's other libraries.

Maybe we should compile nfs statically?  Is that too extreme?

(In reply to comment #7)

Oh, so the heimdal libgssapi.so changed version number from 4 to 2. That's even
worse than before, where a simple change of a symlink was enough to fix many
issues.

http://www.mail-archive.com/heimdal-discuss@sics.se/msg00392.html seems
important. It states that
1. libgssapi.so should support multiple GSSAPI mechanisms, not only Kerberos
2. app-crypt/libgssapi does so, and can link against libgssapi.so from heimdal

If the libgssapi.so from heimdal-1.0 supports other methods as well, it should
be possible to use that as a replacement for app-crypt/libgssapi and also link
nfs-utils against it. As you say this was not possible, I assume the heimdal
libgssapi.so does not provide support for other mechanisms.

I would assume the best solution should be to have all applications linked
against app-crypt/libgssapi and to have that use the heimdal implementation if
the kerberos method of gssapi is requested.

I guess in that case we'd have to make the new heimdal ebuild depend on
app-crypt/libgssapi in some way, probably PDEPEND. That way there will always
be a libgssapi.so available for other programs to link against. Or we could add
that dependency to all ebuilds currently depending on heimdal. Of course some
checks would be needed to find out whether all kerberized programs accept this
version of the library, or whether some require heimdal-specific stuff.

(In reply to comment #8)
> (In reply to comment #7)
> 
> Oh, so the heimdal libgssapi.so changed version number from 4 to 2. That's even
> worse than before, where a simple change of a symlink was enough to fix many
> issues.
> 
> http://www.mail-archive.com/heimdal-discuss@sics.se/msg00392.html seems
> important. It states that
> 1. libgssapi.so should support multiple GSSAPI mechanisms, not only Kerberos
> 2. app-crypt/libgssapi does so, and can link against libgssapi.so from heimdal
> 
> If the libgssapi.so from heimdal-1.0 supports other methods as well, it should
> be possible to use that as a replacement for app-crypt/libgssapi and also link
> nfs-utils against it. As you say this was not possible, I assume the heimdal
> libgssapi.so does not provide support for other mechanisms.
> 
> I would assume the best solution should be to have all applications linked
> against app-crypt/libgssapi and to have that use the heimdal implementation if
> the kerberos method of gssapi is requested.
> 
> I guess in that case we'd have to make the new heimdal ebuild depend on
> app-crypt/libgssapi in some way, probably PDEPEND. That way there will always
> be a libgssapi.so available for other programs to link against. Or we could add
> that dependency to all ebuilds currently depending on heimdal. Of course some
> checks would be needed to find out whether all kerberized programs accept this
> version of the library, or whether some require heimdal-specific stuff.
> 

No, Heimdal DOES implement three mechanisms: spnego, krb5, and ntlm.

libgssapi itself does nothing except call the appropriate sub-library.  But
nfs-utils uses symbols which are present in libgssapi and not in heimdal,
precluding linking it directly against heimdal.

The issue is that, having two libgssapi.so.2 libraries installer, I don't know
a way to have programs linked against libssapi in /usr/lib and the rest of
heimdal in /usr/heimdal/lib.  /usr/lib is one of the "trusted" directories in
LDPATH and so always comes after the things in ld.so.conf.  Also, I'm not sure
apps currently linked against Heimdal will work if libgssapi comes first in
their library search path.

I think the solution may be to pull libgssapi into the nfs-utils ebuild and
statically link the one NFS binary that depends on it.  That was nfs-utils can
contain its custom gssapi stuff and there will be only one libgssapi.so.2.

Created an attachment (id=125797) [edit]
heimdal-1.0.ebuild

New Heimdal ebuild - harder better faster stronger.

Created an attachment (id=125799) [edit]
force_inclusion_by_path.patch

Makes a minor change to gssapi.h to prevent weirdness when building nfs-utils
against CITI libgssapi and heimdal.

Created an attachment (id=125865) [edit]
Alternative heimdal-1.0.ebuild

Before finding this bug, I've successfully installed heimdal-1.0.ebuild adapted
from those of Harald Barth
http://www.pdc.kth.se/~haba/gentoo-stuff/portage/app-crypt/heimdal/ (see Bug
#134064). It does not require so many patches -- any suggestion of tests to
check my installation if it actually works?

(In reply to comment #12)
Harald Barth's practice is to install heimdal into a directory separate from
the main system tree. Information needed to compile all the dependend packages
is provided by krb5-config script, a standard part of the heimdal distribution.
If packages using kerberos do not use that script in their configure scripts,
their ebuilds have to be adapted to use it.

I've added the patch for the net-mail/fetchmail-6.3.8 ebuild to Bug #185652

(In reply to comment #12)
Patch for gnome-extra/evolution-data-server-1.10.2 ebuild filed as Bug #186509

(In reply to comment #10)
I've noticed two issues for this build, because ebuilds don't use krb5-config
and thus don't find the needed kerberos headers.

dev-db/postgresql-8.2.4-r1:
configure: error: header file <krb5.h> is required for Kerberos 5

sys-auth/nss_ldap-254: (looks like bug 165638 but it is a different cause here)
ldap-nss.c:1891: error: ‘GSS_S_COMPLETE’ undeclared (first use in this
function)

There are probably more ebuilds. Is there some systematic check going on or
planned, or should I continue to report issues as I experience them?

(In reply to comment #15)
> (In reply to comment #10)
> I've noticed two issues for this build, because ebuilds don't use krb5-config
> and thus don't find the needed kerberos headers.
> 
> dev-db/postgresql-8.2.4-r1:
> configure: error: header file <krb5.h> is required for Kerberos 5
> 
> sys-auth/nss_ldap-254: (looks like bug 165638 but it is a different cause here)
> ldap-nss.c:1891: error: ‘GSS_S_COMPLETE’ undeclared (first use in this
> function)
> 
> There are probably more ebuilds. Is there some systematic check going on or
> planned, or should I continue to report issues as I experience them?
> 

vapier feels strongly that pkg-config is superior to krb5-config (and I agree
with him).  Heimdal is moving to pkg-config.

I fixed nss_ldap on my end by adding --with-gssapi-dir=foo.

Created an attachment (id=126059) [edit]
heimdal-1.0-1.0.1_rc1.ebuild.diff

Basically the heimdal-1.0.ebuild by Bryan Jacobs (needs renaming the tar.bz2
patchset from 1.0 version to 1.0.1_rc1).

Several commented out lines removed. Hacky simlinks for SASL checks commented
out in favor of changing of problematic ebuilds to use krb5-config. Install
dirs manipulated to avoid, hopefully, clashes with other packages like
app-crypt/libgssapi (in case having the GSSAPI wrapper library around proves to
be useful).

Creation of .pc files for pkg-config attempted, but all the packages using
hardcoded kerberos path will have to be modified anyway.

(In reply to comment #16)

I've started modifying all the ebuilds I install to use krb5-config and
reporting appropriate bugs for such changes. Of course it's far from a
systematic check of the whole portage tree. I just try installing what I want,
and if it fails complaining about some kerberos header or library not found, I
try to introduce krb5-config into its configuration.

At the Bug #185509 I've been scolded heavily for using krb5-config, which is
inferior to pkg-config. That's why I've tried to modify the heimdal ebuild to
create .pc files for pkg-config; but now I'm not sure not only of their
correctness, but even less of the proper way to introduce pkg-config usage into
the dependent ebuilds.

(In reply to comment #18)
> At the Bug #185509 

Not Bug #185509, but Bug #186509 -- excuse, please, my typo.

Created an attachment (id=126114) [edit]
heimdal-1.0-0.8.1-r1.ebuild.diff

Bryan Jacobs' 1.0 ebuild changed to install into /usr/heimdal. bin and sbin
directories contents symlinked into the system /usr/bin and /usr/sbin; name
changes (telnet->ktelnet etc.) done only to the symlinks (in case some package
looks for the binaries inside the heimdal subtree under the original names).
Creation of .pc files for pkg-config attempted.

The patchset slightly modified for 0.8.1: 010_all_heimdal-system-libss.patch
adapted to the elder lib/sl/Makefile.am and inside 012_all_heimdal-berkdb.patch
changed the location of ndbm_wrap.c to the elder path lib/otp/ndbm_wrap.c.
Otherwise the ebuild applies to newer heimdal versions as well; release
candidates require

 HOMEPAGE="http://www.pdc.kth.se/heimdal/"
-SRC_URI="ftp://ftp.pdc.kth.se/pub/heimdal/src/${P/_rc/rc}.tar.gz
+SRC_URI="ftp://ftp.pdc.kth.se/pub/heimdal/src/snapshots/${P/_rc/rc}.tar.gz
     http://dev.gentoo.org/~seemant/distfiles/${PATCH_P}.tar.bz2

The _rc to rc change in the release version is an artefact I've been too lazy
to edit out.

From 0.9 series of release candidates, Bryan Jacobs' patchset seems to be
applicable without modification.

With 0.8.1 release in a separate installation directory I have easily installed
app-crypt/libgssapi, net-libs/librpcsecgss and net-fs/nfs-utils, having just
changed the net-fs/nfs-utils dependency from app-crypt/mit-krb5 to
virtual/krb5. With newer versions of heimdal I've run into problems installing
net-fs/nfs-utils. For now I've tried several heimdal versions and found one
that works with nfs-utils without further work. As soon as I feel like playing
with that again I'm going to submit a detailed report of my compilation
problems as well as anything I eventually find; since the nfs-utils developers
seem to support heimdal, chances are that my problems either are results of my
wrong setup or will go off in the next nfs-utils version.

Created an attachment (id=126115) [edit]
heimdal-0.8.1-gentoo-patches-0.1.tar.bz2

(In reply to comment #20)
> 
> With 0.8.1 release in a separate installation directory I have easily installed
> app-crypt/libgssapi, net-libs/librpcsecgss and net-fs/nfs-utils, having just
> changed the net-fs/nfs-utils dependency from app-crypt/mit-krb5 to
> virtual/krb5. With newer versions of heimdal I've run into problems installing
> net-fs/nfs-utils. For now I've tried several heimdal versions and found one
> that works with nfs-utils without further work. As soon as I feel like playing
> with that again I'm going to submit a detailed report of my compilation
> problems as well as anything I eventually find; since the nfs-utils developers
> seem to support heimdal, chances are that my problems either are results of my
> wrong setup or will go off in the next nfs-utils version.
> 

Even if you manage to compile nfs-utils with Heimdal 1.0 installed, you will
not be able to run rpc.gssd nor rpc.svcgssd.

libgssapi and Heimdal 1.0 by default install "libgssapi.so.2".  You must change
the library version of one or the other in order for the dynamic linker to
function properly with both in the LDPATH (as they both must be for nfs-utils).

(In reply to comment #22)
> Even if you manage to compile nfs-utils with Heimdal 1.0 installed, you will
> not be able to run rpc.gssd nor rpc.svcgssd.

Verified :-(

Switched to the newest Heimdal (1.0.1_rc1) again, removed app-crypt/libgssapi.

Instead of modifying net-libs/librpcsecgss acording to Bug #186392 libgssapi.pc
created by heimdal ebuild: changing the dependencies of librpcsecgss ebuild was
enough then.

net-fs/nfs-utils ebuild modified to use your patch from the Bug #134064 (more
discussion there). Everything compiled well, but rpc.svcgssd still does not
start (and does not say why). May be I would need some specific kernel
configuration, or even kernel patch? (Not that I actually need kerberised NFS
running.)

Created an attachment (id=126185) [edit]
heimdal-1.0-1.0.1_rc1.ebuild.diff

Patch to Bryan Jacobs' 1.0 ebuild to install the current release candidate, use
a separate installation directory and create .pc files for pkg-config (mainly
libgssapi.pc used by net-libs/librpcsecgss). Uses Bryan Jacobs' patchset, just
renamed to reflect the version.

(In reply to comment #23)
> net-fs/nfs-utils ebuild modified to use your patch from the Bug #134064 (more
> discussion there). Everything compiled well, but rpc.svcgssd still does not
> start (and does not say why). May be I would need some specific kernel
> configuration, or even kernel patch? (Not that I actually need kerberised NFS
> running.)
> 
In order to use Kerberized NFS, you must have rpcsec_gss support in the kernel
(modprobe appropriate stuff if necessary).  This means you need to enable NFSv4
server support and the krb5 mechanism in your kernel config.

Try to run rpc.gssd or rpc.svcgssd with the -f -vvv options.  Check syslogs
too.  They'll complain about missing stuff in /proc or /var if you don't have
appropriate modules loaded or the nfs filesystem mounted.

Created an attachment (id=128519) [edit]
app-crypt/heimdal/heimdal-1.0.1.ebuild

Symlinks fixup.

Created an attachment (id=128521) [edit]
app-crypt/heimdal/files/1.0.1/001_all_heimdal-no_libedit.patch

Created an attachment (id=128523) [edit]
app-crypt/heimdal/files/1.0.1/002_all_heimal-fPIC.patch

Created an attachment (id=128524) [edit]
app-crypt/heimdal/files/1.0.1/003_all_heimdal-rxapps.patch

Created an attachment (id=128526) [edit]
app-crypt/heimdal/files/1.0.1/005_all_heimdal-suid_fix.patch

Created an attachment (id=128528) [edit]
app-crypt/heimdal/files/1.0.1/010_all_heimdal-system-libss.patch

Created an attachment (id=128529) [edit]
app-crypt/heimdal/files/1.0.1/012_all_heimdal-berkdb.patch

Created an attachment (id=128531) [edit]
app-crypt/heimdal/files/1.0.1/013_all_heimdal-pthread-lib.patch

Created an attachment (id=128533) [edit]
app-crypt/heimdal/files/1.0.1/014_all_heimdal-path.patch

Created an attachment (id=128534) [edit]
app-crypt/heimdal/files/1.0.1/015_all_heimdal-fixit.patch

Created an attachment (id=128536) [edit]
app-crypt/heimdal/files/1.0.1/100_all_force_inclusion_by_path.patch

Created an attachment (id=128537) [edit]
app-crypt/heimdal/files/configs/heimdal-kadmind

Created an attachment (id=128539) [edit]
app-crypt/heimdal/files/configs/heimdal-kcm

Created an attachment (id=128540) [edit]
app-crypt/heimdal/files/configs/heimdal-kdc

Created an attachment (id=128541) [edit]
app-crypt/heimdal/files/configs/heimdal-kpasswdd

Created an attachment (id=128543) [edit]
app-crypt/heimdal/files/configs/krb5.conf

Created an attachment (id=128544) [edit]
app-crypt/heimdal/files/configs/krb5-kdc.schema

Thanks a lot, your ebuild worked for me. Where did the heimdal maintainer go?
The last ebuild in the tree is extremely old...

Created an attachment (id=131346) [edit]
heimdal-1.0.1-r1.ebuild

Dmitry S. Kulyabov's 1.0.1 ebuild had built well for me, but then I ran into
problems with dependent packages.

Unfortunately I didn't report the problem immediately neither made notes, and
by now I've forgotten which ebuild crashed then during compilation and what was
the error report. In case nobody else obtains such information I'll have to
find time for further experiments and reproduce the error once again.

For now, I use this ebuild, heavily based on Bryan Jacobs's work (my few
additions, derived mostly from Harald Barth's work, actually converging further
to Bryan Jacobs's 1.0 ebuild). It uses Bryan Jacobs's 1.0 patchset, just
renamed to heimdal-1.0.1-gentoo-patches-0.1.tar.bz2 Until now it seems to work
for me -- that is everything I've tried to upgrade or recompile has built well.
(I guess that unmodified Bryan Jacobs's 1.0 ebuild, just renamed to 1.0.1,
would work as well.)

Unfortunately I don't understand programming much and kerberos at all, so I'm
unable to actually compare Bryan Jacobs's and Dmitry S. Kulyabov's works, not
to speak of combining the best of both worlds into something ready to push into
the portage tree (which needs upgrade desperately).

Yeah look, we need heimdal maintainers.  There are none.  I used to maintain
this, but I have no boxes with it on anymore, nor do I have the knowledge. 
And, I'm retiring soon, anyway.  So, if someone would like to step up, I'll
happily mentor that person before my depar