[Mailman-Developers] How to downgrade from mailman 2.1a2 ?
and some of my problems
Mon, 02 Jul 2001 20:25:40 -0400
At 07:45 PM 7/2/01 -0400, you wrote:
>Yes, because MM2.0.x used crypt to encrypt the passwords, but MM2.1
>uses sha since it's much more reliably built into Python. This needs
>to get prominent notice in the release notes because there is no
>automatic way for Mailman to fix these passwords (the plain text
>cannot be programmatically extracted).
You know, I'd seen this before, and it hadn't sunk in.. I expect this'll be a *big* loose for many existing sites. Hell, I don't actually know the list passwords to... Hmm. *Any* of my lists. Once I generated them for their owners, I didn't save the initial password, and encouraged them to change it anyway. And for the lists I run, I habitually use the site password to trump them out, since it's just easier that way. (Hell, I barely remember my personal list password on the lists :-)).
I dread having to contact all the owners and arrange to get them a new
password. (Note, having a tool that just emails out new random passwords to all the contacts isn't perfect, since I have people listed on a few lists that don't have the password, they just have the responsibility of answering the damn mail that comes in.) Or am I safe, because I'm not using crypt now? Doesn't it fall back to sha in that case? Or is they way 2.0 and 2.1 use it incompatible with each other? I already upgraded my 2.1 test system,
and don't know the damn passwords there anyway :-).
It might be worth considering another point release, to include a password recovery module for migration. Once installed, as each list admin authenticates, it checks to see if sha is already around. If so, it either
just stashes the new format for later use in the config.db, or possibly goes ahead and migrates to using the new format. Come 2.1, most of the lists will be good to go already, and the admin page could easily include a signal that a particularly lists password was, or was not, valid anymore. (Hell, the login page could realistically include a note that "Your list has not finished conversion to the new software release. Please contact the site administrator to have your password reactivated."
Similarly, 2.1 could include a fallback mechanism; if the password fails, and if crypt is available to load, try again with crypt, and if that works, convert the password and store it in the new format.
With the two combined, you'd likely eliminate 90% of the migration difficulties (more, if it takes a while for 2.1 to come out). The ones worst impacted will be the ones who don't keep up to date, but they'll have multiple concerns anyway.