On Mon, 19 Nov 2001, Ken Murchison wrote:
> > The v1 sasl library supported an auto-transition for plaintext
> > logins where the login was authenticated against some external
> > mechanism (e.g., /etc/passwd) and then used to create the entries
> > in the sasldb. A similar auto-transition, even requiring a single
> > plaintext login, would make make the switchover much easier.
>
> This might be possible. I'd be curious how Rob and Larry feel about
> this.
As I said before, the database can be fully and automatically converted
all at once, so such a program is unnecessary.
> > Easier yet would be if the v2 library would support using the old
> > v1 sasldb as a fallback if it doesn't find an entry in the new db.
> > New entries and password updates would go into the new one. Eventually
> > the old db would be completely shadowed and could be removed.
>
> Hmm. I'll defer to Rob on this, but I don't think we want legacy
> setpass() code floating around in the v2 library (each plugin used to
> set its own password, but now its handled globally because they all
> share the same plaintext password).
We definately don't want legacy code floating around the library, as it
is, having to be backwards compatible with the older style secrets is
imperfect at best.
As far as setpass() specifically, each plugin is still allowed to maintain
its own database of secrets if necessary. There is no requirement that
any mechanism plugin use sasldb for authentication (e.g. KERBEROS_V4).
For the record, saslpasswd makes all appropriate setpass() calls, though
the supplied mechanisms do not make use of it (except possibly OTP at
this point, but I'm not sure).
-Rob
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Cyert Hall 235 * 412-CMU-TREK
| Cyrus SASL Developer, /usr/contributed Gatekeeper
