Russ Allbery <[EMAIL PROTECTED]> 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. Thanks, Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
