Re: Interest in packaging GNU Shishi and GNU Generic Security Service?
Russ Allbery <firstname.lastname@example.org> writes:
> Simon Josefsson <email@example.com> writes:
>> Having you as a co-maintainer would be great.
>> I expect the initial packaging to be simple, it is just a './configure
>> && make install' package. Part of the 'make install' procedure should
>> be duplicated in the apt install scripts, for the KDC side, but that
>> part is not important. I think it is more important to simply get the
>> library and binaries packaged. How to better co-exist with MIT and
>> Heimdal is something that will need to be figured out along the way.
> There is an open bug against MIT Kerberos (#213316) asking that it use the
> alternatives system. Originally this was for Java packages, which
> thankfully have stopped using alternatives to manage their broken version
> of kinit, but it's still appealing to coexist with Heimdal. I don't want
> to add it only in MIT Kerberos, but if the Heimdal folks are also
> interested, I think it would be worthwhile.
> I don't know if Shishi conflicts with any binary names in Heimdal or MIT
> Kerberos; I haven't checked yet. If so, alternatives looks even more
> The dev packages for Heimdal and MIT Kerberos conflict and that can't
> really be fixed. Whether Shishi would also conflict is an interesting
> question. I expect that the GSSAPI dev package would.
> Are you implementing the same API as MIT Kerberos, the same API as
> Heimdal, or something else yet again?
Shishi can co-exist with either of MIT or Heimdal. It doesn't use a
similar API at all. The library has a clean name space (shishi_*).
The tools doesn't conflict with any (to me) known tools.
I don't think the GSSAPI dev package would conflict; it places header
files in $prefix/include/gss/ and the library is called libgss to
avoid conflicting. However, as it implement the standard GSS API, the
namespace do conflict, so you can't link directly to more than one
GSS-library at the same time.
I'm carefully avoiding conflicting with any existing Kerberos
implementation, but I'm considering adding functions to read the
MIT/Heimdal configuration file, to simplify things for the user. I'm
not sure more compatibility than that is useful.