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

Reply via email to