--On Monday, November 19, 2001 03:49:59 PM -0500 Ken Murchison <[EMAIL PROTECTED]> 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? >> >> Aarrgghhh. That's a definate stumbling block. Especially if you have >> other applications sharing the sasldb; but not ready to shift to v2. > > Maybe I wasn't clear. You do NOT have to change the existing sasldb in > any way. You have to set the users' passwords in the new sasldb. Right. Which means that they will be duplicated and must be kept in sync for as long as you have apps using both versions. Changing your password in either database won't automatically change it in the other. >> How much can be done to ease the transition? Is there a tool to >> extract PLAIN passwords from the v1 sasldb and store them in the >> new format? (That would at least handle the common case where all >> of the mechanisms actually used the same password for a given user.) > > No. The PLAIN passwords were not stored in a plaintext format in v1.5. > If you are running with my APOP patch (which stored a plaintext > password), then there is a conversion tool available. I have multiple virtual hosts, each with some number of virtual users and several services that require authentication. Without some sort of automation, the transition sounds like a huge pain. 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. 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. -Pat
msg04554/pgp00000.pgp
Description: PGP signature
