Another problem is how to enable applications using GSS-API in Debian to use Shishi. The current model, to link applications against either MIT or Heimdal, and in some cases (I think) provided packages built against both MIT and Heimdal, seems several broken to me. There also seem to be both GSS and non-GSS versions of some packages, which also seems broken to me.
I propose that all applications with GSS-API support should be built with the GSS-API support by default, and link to a dummy meta-GSS-library that will dlopen the respectively GSS-API implementation depending on a configuration file. Then, by default, all applications will support GSS-API, and the administrator can decide which GSS-implementation she wish to use, by installing the GSS-library and configure the meta-GSS library. Solaris has something similar: it only has one GSS-library, but it can load mechanisms depending on configurations in /etc/gss.conf (or somewhere). So all applications with GSS support link to the GSS-library by default, but which mechanism is used is chosen at run-time. Thoughts? Supporting this meta-GSS-library approach has been the goal of my GSS library, but I've noticed that there is another library with a similar goal that is in the Debian NEW queue, libgssapi from <http://www.citi.umich.edu/projects/nfsv4/linux/>. I haven't looked at it in detail though, so I'm not sure it actually implements this the way I thought it would. I'm also not sure whether they are interested in working on the things that would be required to make what I'm thinking of happen. There is also a license issue, the libgssapi stuff seem to require export permissions from the USG to be exported from to U.S., and I'm not sure if that permissions is granted for exports anywhere, which I would have a problem with. If that is the case, I'd prefer to improve my GSS library to make it implement this approach. /Simon _______________________________________________ Help-shishi mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-shishi
