MIT Kerberos 5 status

MIT Kerberos 5 status

[Isaac Dunham]

The issue is now filed as 
[krbdev.mit.edu #7167]
Meanwhile, I figured out that the root issue is Redhat's libverto, now a
hard dependency which Kerberos bundles.  (libverto allows asynchronous
libraries with a caller-specified event loop)
I've poked around, discovering that AIX has no dladdr/dlinfo, but
there's a wrapper for AIX; HP/UX also has no dladdr/dlinfo, so when I
discovered that 1.8.6 can be built (with some issues) for HP/UX, I
grabbed that version. This does mean that nothing using libverto will
work with musl (or HP/UX) without some patching...although not many
packages use libverto, AFAICT.

It looks like they #included sys/errno.h instead
of errno.h, which makes for an FTBFS.
Also bindresvport.c (in src/lib/rpc/) omitted netdb.h (I  guess they
expect IPPORT_RESERVED from <netinet/in.h>) 
But 1.8.6 gets much farther without patching, and builds with those
two issues fixed.

So the status is:
Kerberos 1.10.2 (presumably all 1.10* releases): 
blocked by libverto dependency on dl*
Kerberos 1.9.*: Unknown
Kerberos 1.8.*: 
s|<sys/\(errno\)|<\1|g
add netdb.h to src/lib/rpc/bindresvport.c
1.10.*, 1.9.*, and 1.8.* are all currently maintained.

HTH
Isaac Dunham

Re: MIT Kerberos 5 status

[John Spencer]

On 06/10/2012 11:21 PM, Isaac Dunham wrote:
> The issue is now filed as
> [krbdev.mit.edu #7167]
> Meanwhile, I figured out that the root issue is Redhat's libverto, now a
> hard dependency which Kerberos bundles.
Red Hat using non-portable GNU only stuff is nothing out of the ordinary.

one could even get the impression that their usage of occult stuff like 
M4/autocrap/gnulib etc is part of their business strategy to ensure 
continuous sales of support contracts...

anyway: the usual workaround for this problem is to copy the struct 
DlInfo prototype from glibc,
and put it into a header together with a static dummy dladdr function, 
that simply always returns error.

Re: MIT Kerberos 5 status

[Rich Felker]

On Sun, Jun 10, 2012 at 02:21:06PM -0700, Isaac Dunham wrote:
> grabbed that version. This does mean that nothing using libverto will
> work with musl (or HP/UX) without some patching...although not many
> packages use libverto, AFAICT.

I've looked at the libverto source and as far as I can tell, the only
thing it uses this hackery for is finding the path to its own .so file
so it can munge that name to make a pathname for its own module files
it wants to load from the same path and with the same version suffix.
This of course is utter nonsense. The correct behavior would be to
either:

1. Don't use any explicit pathname; let the same path search procedure
that found the main libverto.so.0 find the modules. For the version
suffix, it's known when the library is built, so this can simply be
hard-coded in the name passed to dlopen (without a path).

OR

2. Simply hard-code all the paths, and don't necessarily put the
modules in the system lib directory (where they're ugly clutter
anywhere) but instead in a verto-specific directory somewhere.

Of course this whole approach is utter madness. It results in library
code that does not work with static linking. The goal, as far as I can
tell, is to avoid pulling lib glib, libevent, etc. dependencies if the
calling application does not use these libs, which is a nice idea from
a packager's standpoint (*cough* Fedora...), but the same thing could
really be accomplished just by putting all the code in the main
library (static or shared), and making all the references to glib,
libevent, etc. into weak references and not explicitly linking to any
of these libraries (so they're only accessible if the main application
already linked them).

In short, the problem arises because the folks at Redhat are doing
some nasty hackery.

Rich