cyrus-sasl2: use Heimdal instead of MIT Kerberos on Lion and later

[lpsinger (Leo Singer)]

I co-maintain a port (nds2-client) that uses Kerberos authentication via SASL. In Lion, Apple switched their Kerberos implementation from MIT Kerberos to Heimdal. However, MacPorts' /opt/local/bin/kinit is still MIT Kerberos. As a result, keys created by /opt/local/bin/kinit are not visible by /usr/bin/klist, whereas keys created by /usr/bin/kinit are not visible by /opt/local/bin/klist.

In order to smooth Kerberos authentication, I propose that cyrus-sasl2 depend on the Heimdal port on Lion and later. This will make it so that MacPorts programs can use the same credentials cache as Apple's kerberos utilities.

My proposal would consist of three patches:

1. heimdal: change prefix from ${prefix}/libexec/heimdal to ${prefix} and add a conflict with kerberos5
2. kerberos5: add a conflict with heimdal
3. cyrus-sasl2: kerberos variant depends on kerberos5 on darwin <= 10, and heimdal on all other platforms

As I have conceived them, these three patches would have to go through at the same time. Right now, I will attach just the cyrus-sasl2 patch. I would appreciate instructions on whether to attach the heimdal and kerberos5 patches here or to open separate cross-referenced bug reports for them.

[lpsinger (Leo Singer)]

proposed patch for cyrus-sasl2

[ryandesign (Ryan Carsten Schmidt)]

Wouldn't we have to make similar changes to all ports that have a dependency on kerberos5? This is the list, as far as I can tell:

• cclient
• cyrus-sasl2
• fetchmail
• freeradius
• kdelibs4
• mailx
• nds2-client
• openssh
• py-pykerberos
• remctl
• samba3
• yafc

There's no particular need to change heimdal's prefix and make it conflict with kerberos5, is there? That would seem to be a step backwards.

[lpsinger (Leo Singer)]

Replying to ryandesign@…:

Wouldn't we have to make similar changes to all ports that have a dependency on kerberos5? This is the list, as far as I can tell:

• cclient
• cyrus-sasl2
• fetchmail
• freeradius
• kdelibs4
• mailx
• nds2-client
• openssh
• py-pykerberos
• remctl
• samba3
• yafc

Yes, that's right, there are some other ports that would need changes similar to cyrus-sasl2.

Of the ports that you listed:

• nds2-client: I maintain this port, and its developers say that cyrus-sasl2 is preferred over the kerberos5 gssapi library. So nds2-client does not need a direct dependency on kerberos5 or cyrus-sasl2.
• yafc: has a heimdal variant, and it is enabled by default

There's no particular need to change heimdal's prefix and make it conflict with kerberos5, is there? That would seem to be a step backwards.

Leaving heimdal in an alternative prefix would not represent a complete solution. The problem is that ${prefix}/bin/kinit is currently always provided by the kerberos5 port (MIT Kerberos). As a result, when a MacPorts user runs kinit, the tickets created by it are not compatible with Apple's own key store on Lion and Mountain Lion.

If we let heimdal use the main MacPorts installation prefix, have it conflict with kerberos5, and have ports that need Kerberos support use kerberos5 on pre-Lion systems and heimdal on post-Lion systems, then MacPorts applications should work with Apple's key store on all systems.

[ryandesign (Ryan Carsten Schmidt)]

Replying to aronnax@…:

• nds2-client: I maintain this port, and its developers say that cyrus-sasl2 is preferred over the kerberos5 gssapi library. So nds2-client does not need a direct dependency on kerberos5 or cyrus-sasl2.

Ports that install programs that link with a library need a library dependency on the port that provides that library. Most of the programs and libraries installed by the nds2-client port do link with libgssapi_krb5.2.2.dylib so they do require a library dependency on kerberos5 (or heimdal, if that would also work).

• yafc: has a heimdal variant, and it is enabled by default

There's no particular need to change heimdal's prefix and make it conflict with kerberos5, is there? That would seem to be a step backwards.

Leaving heimdal in an alternative prefix would not represent a complete solution. The problem is that ${prefix}/bin/kinit is currently always provided by the kerberos5 port (MIT Kerberos). As a result, when a MacPorts user runs kinit, the tickets created by it are not compatible with Apple's own key store on Lion and Mountain Lion.

If we let heimdal use the main MacPorts installation prefix, have it conflict with kerberos5, and have ports that need Kerberos support use kerberos5 on pre-Lion systems and heimdal on post-Lion systems, then MacPorts applications should work with Apple's key store on all systems.

There are two courses of action that would work:

1. Do as you suggested initially, and require kerberos5 on Snow Leopard and earlier and heimdal on Lion and later. Modify all ports that use kerberos5 or heimdal to abide by this edict. Do not offer any variants to select the kerberos implementation. If it is desirable to make the kerberos5 and heimdal ports conflicting, then that would be fine. The kerberos5 and heimdal ports could even be modified so that they refuse to install on OS X versions not designed for their use. But since many users of Lion and Mountain Lion do have kerberos5 installed today, and probably some users of Snow Leopard and earlier have heimdal installed, there must be a seamless upgrade path that will result in the old port being deactivated and the new port activated (the "deactivate hack" that we've used in some other ports).
2. Allow the user to select which kerberos implementation they want. Offer variants wherever possible. The ports may not be made to conflict in this case.

[lpsinger (Leo Singer)]

Replying to ryandesign@…:

There are two courses of action that would work:

1. Do as you suggested initially, and require kerberos5 on Snow Leopard and earlier and heimdal on Lion and later. Modify all ports that use kerberos5 or heimdal to abide by this edict. Do not offer any variants to select the kerberos implementation. If it is desirable to make the kerberos5 and heimdal ports conflicting, then that would be fine. The kerberos5 and heimdal ports could even be modified so that they refuse to install on OS X versions not designed for their use. But since many users of Lion and Mountain Lion do have kerberos5 installed today, and probably some users of Snow Leopard and earlier have heimdal installed, there must be a seamless upgrade path that will result in the old port being deactivated and the new port activated (the "deactivate hack" that we've used in some other ports).

I was reading about how to do that by looking at r95305 as an example. In this case, would the deactivate hack have to be applied to kerberos5 and heimdal, or to the ports that depend on them? On what test would the registry_deactivate_composite be conditioned?

2. Allow the user to select which kerberos implementation they want. Offer variants wherever possible. The ports may not be made to conflict in this case.

In option 2, is there a way to have ${prefix}/bin/kinit map to heimdal's kinit or kerberos5's kinit at the user's discretion? Is this within the scope of 'port select'?

[ryandesign (Ryan Carsten Schmidt)]

Note that wireshark and wireshark-devel are now among the ports that depend on kerberos5.

Replying to aronnax@…:

Replying to ryandesign@…:

there must be a seamless upgrade path that will result in the old port being deactivated and the new port activated (the "deactivate hack" that we've used in some other ports).

I was reading about how to do that by looking at r95305 as an example. In this case, would the deactivate hack have to be applied to kerberos5 and heimdal, or to the ports that depend on them? On what test would the registry_deactivate_composite be conditioned?

I was thinking something like the following pseudocode:

Port kerberos5:

platform darwin {
  if os.major is 10 or earlier {
    pre-activate {
      if heimdal is installed and active {
        deactivate heimdal
      }
    }
  } else {
    pre-fetch {
      tell the user to install heimdal instead
    }
  }
}

Port heimdal:

platform darwin {
  if os.major is 11 or later {
    pre-activate {
      if kerberos5 is installed and active {
        deactivate kerberos5
      }
    }
  } else {
    pre-fetch {
      tell the user to install kerberos5 instead
    }
  }
}

2. Allow the user to select which kerberos implementation they want. Offer variants wherever possible. The ports may not be made to conflict in this case.

In option 2, is there a way to have ${prefix}/bin/kinit map to heimdal's kinit or kerberos5's kinit at the user's discretion? Is this within the scope of 'port select'?

Maybe. I was also thinking about whether there should be a metaport which just installs ${prefix}/bin/kinit as a symlink to either heimdal's or kerberos5's kinit, depending on the OS version.

It would be nice if that metaport could install symlinks to all the relevant libraries and headers, every port that needs kerberos could just depend on that metaport and be done with it, but I fear it won't be that easy; for example yafc applies different patches depending on the kerberos implementation.

[lpsinger (Leo Singer)]

Well, there's another problem. /opt/local/libexec/heimdal/bin/klist does see tickets created with /usr/bin/kinit, but on my system /opt/local/libexec/heimdal/bin/kinit segfaults if you ask it to use the default credentials cache. I will open another ticket for that.

[raimue (Rainer Müller)]

Cc Me!

[quentinmit (Quentin Smith)]

Cc Me!

[mmpestorich (Mike M Pestorich)]

Cc Me!

[NicosPavlov]

Cc Me!

[kenh@…]

Am I the only one who has noticed that the MacPorts own FAQ says:

You may find some ports that link with some system libraries. Some of these are intentional, such as in cases where the MacPorts version is missing some crucial functionality (e.g. ports that need Kerberos support use the Mac OS X-supplied library, not the MacPorts one).

If cyrus-sasl2 went back to simply not linking against the MacPorts Kerberos (you know, like the FAQ says that it's not supposed to) then this wouldn't be a problem anymore.

[dualityim@…]

Cc Me!

[dom.heussi@…]

You may find some ports that link with some system libraries. Some of these are intentional, such as in cases where the MacPorts version is missing some crucial functionality (e.g. ports that need Kerberos support use the Mac OS X-supplied library, not the MacPorts one).

If cyrus-sasl2 went back to simply not linking against the MacPorts Kerberos (you know, like the FAQ says that it's not supposed to) then this wouldn't be a problem anymore.

I totally agree. There seems also to be a major problem when using open afs (installed binary from their webpage) that depends on the Mac OS X-supplied library and does not work with the kerberos that is "forced" by cyrus-sasl2 automatically. Thus I install cyrus-sasl2 with -kerberos. As I heavily depend on afs for work, but also on other macports tools (svn) that are build against kerberos (via cyrus-sasl2), I am in the situation to not being able to have both. This is a nuisance. So, why is there no way to build cyrus-sasl2 against the Mac OS X-supplied kerberos as suggested by the FAQ ? This would resolve my problem easily...

[jpenney (Jason Penney)]

Cc Me!

[mmpestorich (Mike M Pestorich)]

Replying to dom.heussi@…:

So, why is there no way to build cyrus-sasl2 against the Mac OS X-supplied kerberos as suggested by the FAQ ? This would resolve my problem easily...

Here is a patch to the cyrus-sasl2 port that makes it build against the os x supplied kerberos on darwin >= 11. When configuring cyrus-sasl2 on darwin >= 11, you must still set --with-gss_impl=mit. Kerberos and GSSAPI libraries found in /usr on seem to follow naming conventions normally used by mit kerberos even though they are really heimdal versions.

This patch is a work around for any ports dependent on cyrus-sasl2 (for those that don't want to wait for these other issues to be resolved). By linking cryus-sasl2 against the system kerberos libs (in /usr), ports dependent on cyrus-sasl2 will work properly with the system managed credential cache (/usr/bin/{kinit, klist, kdestroy}). I don't believe that this a the proper long term solution. This does nothing to address any issues that currently exist for ports that link directly against kerberos. I believe that once #36811 is resolved, then all kerberos dependent ports (including cyrus-sasl2) need to be setup to link against the proper version of kerberos for any given host system as outlined in the description of this ticket.

[john_macports@…]

Cc Me!

[mf2k (Frank Schima)]

Cc Me!