Christopher Wong wrote:
>
> On Monday 19 November 2001 01:54 pm, Ken Murchison wrote:
> > Cyrus users,
> >
> > We are getting close to releasing Cyrus v2.1 (yeah, I know I've said
> > this a bunch of times already) and we are leaning towards making it
> > dependent on SASL v2. We would like to do this for a number of
> > reasons:
> >
> > 1. Take advantage of the benefits of SASL v2 (improvements in memory
> > management, support for additional plugin types, simplified database
> > support, and improved error reporting).
> >
> > 2. Take the lead in SASLv2 migration. Hopefully Sendmail, OpenLDAP,
> > etc would soon follow.
> >
> > 3. SASL v2 and v1.5.x can peacefully co-exist on the same system.
> > I've been running Sendmail 8.12.1/SASL 1.5.24 and Cyrus 2.1 CVS/SASL
> > 2.0.4 CVS for weeks without any problems.
> >
> > 4. We would no longer have to maintain two Cyrus v2.1 source branches
> > (developer benefit).
> >
> > 5. It WILL happen eventually, so why not now?
>
> Regarding #2: as a user on Red Hat, I really would prefer to have the
> distributions "take the lead". I like convenience that binary RPMs
> bring, but dislike having multiple package revisions installed, with
> all the potential dependency headaches. Cyrus-IMAP is a pretty complex
> piece of software to begin with, and I would prefer to limit the number
> of additional packages that I would have to install along with it
> ("don't rock the boat").
Unless I'm not understanding your point, I think you have a
cart-and-horse problem here. RedHat won't have SASLv2 code to package
if developers don't migrate and distribute code based on SASLv2. I
don't think we can expect the Sendmail's and OpenLDAP's of the world to
migrate to v2 if the people that developed the library don't use it
themselves.
> You have sketched out benefits largely from a developer's perspective.
> What benefits would a user see from installing SASL2?
- More mechanisms.
- More security. Because the plaintext verifications methods have been
moved to a separate process (saslauthd) which can run as root, you don't
have to monkey with permissions on /etc/sasldb, /etc/passwd,
/etc/shadow, etc.
- More flexibility. The new API makes adding new plaintext verification
methods, storage methods a lot easier.
- probably something else that I'm missing.
Ken
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp