On Mon, 19 Nov 2001, Ken Murchison wrote:
> The biggest (only?) downside for existing installations is that any
> secrets stored in sasldb would have to migrated to the new format. This
> will require resetting all of the users passwords because they can not
> be extracted from the old sasldb (unless you have been using my APOP
> patch). As stated above, this will eventually have to be done, so why
> not now?
Actually, this isn't exactly the case. SASLv2 has a converter program
similar to the dbconverters that were included in previous versions of
SASL whenever the format changed. The mechanisms essentially "cheat" off
of the old format secrets until the passwords are changed.
So, it's imperfect (new mechanisms can't used the password stored), but
since there are no new mechanisms currently bundled this isn't a big deal.
What I heard rumors that Ken was experementing with was actually holding
both v1 and v2 secrets in the same database. This was an unintended
"feature" and I haven't fully thought out the ramifications of sharing a
sasldb between v1 and v2 implementations of SASL yet. (for example, I
know that resetting passwords would be, at best, "interesting"), but
there's no reason that I can currently think of that the database file
cannot be shared in a read-only enviornment.
-Rob
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Cyert Hall 235 * 412-CMU-TREK
| Cyrus SASL Developer, /usr/contributed Gatekeeper
