Re: Interest in packaging GNU Shishi and GNU Generic Security Service?
Russ Allbery <firstname.lastname@example.org> writes:
> The software area in which you're writing code is fairly mature and even
> standardized. Pretty much everything that does SASL uses Cyrus SASL.
It is not even that good, plenty of applications implement their own
SASL code. A quick ldd $bin|grep sasl suggest Kmail, Korn, Evolution
(Camel), Mozilla, Fetchmail, Exim, Gnus...
> But the situation from a distribution standpoint is much different.
> It's a huge amount of work (and work that's generally not worth the
> effort) for Debian to build all Kerberos-using packages against
> multiple libraries, and it's confusing for our users to have to
> choose between different packages. It's also proven in practice to
> not be horribly maintainable.
I think that is a problem that should be improved regardless of
whether Shishi is added or not. Using a meta-gss library, that would
dlopen other GSS-API implementations based on configuration files,
appear to be a feasible solution. Then all Debian packages can easily
enable GSS support, linking to that small meta-GSS library, and don't
care about distributing multiple packages for Heimdal, MIT or Shishi.
This also solve the problem if someone want GSS-API _and_ TLS support,
right now some packages exist in *-gssapi and *-openssl3 versions. So
I don't think adding Shishi to this mix complicate matter, rather it
may prod people into actually solving the original problem.
> On top of that, since this is authentication software, it often goes
> through a much tighter change management process and is handled far more
> conservatively. For instance, there's no way that I'd deploy Shishi as
> the KDC for stanford.edu for at least another five years, just because
> Shishi isn't mature in the way that MIT Kerberos is. This is nothing
> against the quality of the code, which I've not even looked at, but comes
> from a very conservative attitude towards changes to the core
> authentication infrastructure. Large sites aren't going to want to be the
> sites that encounter the interesting problems.
I hear you.