[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

Russ Allbery <rra@stanford.edu> 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.


Reply to: