mailman import21 passwords
Hi,
On https://docs.mailman3.org/en/latest/faq-migration.html it says "Mailman 3 has a completely new account management system, none of the passwords from Mailman 2 will work with Mailman 3. Each user needs to sign up in Postorius for a new account to manage their memberships on all lists on a single instance."
"Each user needs to sign up in Postorius for a new account"
I am (personally) satisfied with this answer.
However others at the company are asking for a detailed explanation.
Consider that -
- Mailman2 has access to password information.
- Import scripts such as "import21" are able to import list information.
- It seems that scripts such as "import21" could also generate new user accounts and passwords based on the previous ones.
Why can't passwords be imported from mailman2 to mailman3? How difficult would it be to do?
(is there a link to where this is already explained? )
Thanks
On 9/16/24 16:25, Sam Darwin via Mailman-users wrote:
Why can't passwords be imported from mailman2 to mailman3? How difficult would it be to do? (is there a link to where this is already explained? )
Mailman 3 users have a _password attribute which isn't actually used for anything. The importer used to set this from the MM 2.1 member's password, but this was dropped by <https://gitlab.com/mailman/mailman/-/merge_requests/565>. See <https://mail.python.org/archives/list/mailman-developers@python.org/thread/4...> for a discussion of this. Also note that since member passwords were stored in plain text in MM 2.1 and periodically emailed, those passwords are inherently not secure and have possibly been exposed so setting that password, even though encrypted in MM 3, is not a good idea.
As far as creating a Django user for an imported member, whether or not with the member's MM 2.1 password, it is at least as expensive as just encrypting the password and would result in poor performance.
Further, and perhaps more importantly, Mailman 3 is modular. There is no guarantee that any Mailman Core installation into which a MM 2.1 list is imported actually also supports Django users for Postorius and/or HyperKitty.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
There is no guarantee that any Mailman Core installation into which a MM 2.1 list is imported actually also supports Django users for Postorius and/or HyperKitty.
There is no guarantee that a mailman-core installation also includes Postorius and/or HyperKitty. However we can imagine that the vast majority do utilize all those components. If you've installed mailman3, you are probably installing Postorius and HyperKitty. To account for the fact that it's not 100% guaranteed, the import script could require a flag such as --django-accounts. Or it could even be another script entirely. So, the step wouldn't be automatic, but at least it would be an option.
inherently not secure
The passwords were good enough for mailman2. If a mailman2 instance has been in production for 20 years and users aren't complaining about security, maybe it's not a show stopper. The point is to make the upgrade seamless. That means... being able to say that everyone gets to keep their user account and password. To be able to easily tell the users "Your account is still the same. Just log in. Change your password when you like."
In the current context, passwords are associated with django accounts rather than mailman-core accounts. So this is about creating django users.
creating a django user is "expensive". "poor performance"
I didn't follow what that means. What is expensive? What is poor performance? Creating new django accounts en masse would be a one-time operation. It doesn't matter if it's slow, or expensive, since it only happens once.
And it would be optional. With the --django-accounts flag. Or another separate script. Then you can tell users "Your account is the same as before. A transparent upgrade. Just log in".
On 9/16/24 18:18, Sam Darwin via Mailman-users wrote:
inherently not secure
The passwords were good enough for mailman2. If a mailman2 instance has been in production for 20 years and users aren't complaining about security, maybe it's not a show stopper
There are regular complaints dating back at least to <https://bugs.launchpad.net/mailman/+bug/265179> about passwords mailed in the clear.
The point is to make the upgrade seamless. That means... being able to say that everyone gets to keep their user account and password. To be able to easily tell the users "Your account is still the same. Just log in. Change your password when you like."
But is it "the same"? What about an import of two lists with members which are the same person, but with possibly separate email addresses and/or passwords? Do we really want to create multiple Django users, or let the user create one Django user with multiple addresses?
In the current context, passwords are associated with django accounts rather than mailman-core accounts. So this is about creating django users.
creating a django user is "expensive". "poor performance"
I didn't follow what that means. What is expensive? What is poor performance?
I pointed to <https://mail.python.org/archives/list/mailman-developers@python.org/thread/4...> which discusses the performance issue as a reason for dropping the import of MM 2.1 passwords.
Creating new django accounts en masse would be a one-time operation. It doesn't matter if it's slow, or expensive, since it only happens once.
While probably not typical, mail.python.org currently has (still) 209 MM 2.1 lists with 40261 unique member addresses. Creating 40261 Django users, even just one time would probably be painful.
And it would be optional. With the --django-accounts flag. Or another separate script. Then you can tell users "Your account is the same as before. A transparent upgrade. Just log in".
I really don't understand why telling the user that she has an account and she can just log in with one of the N MM 2.1 passwords she had on the N MM 2.1 lists or get a reset email if she doesn't know or remember the password(s) is any easier for the user than telling her to go to ... and sign up.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hello,
I agree with Mark. However, as I run an IPS on Mailman3 login, I changed the login HTML template to warn the users clearly that they MUST create an account as long as they didn't since the migration date.
So far (migrated end of June) I only had one user locked out because of the IPS and one complaint from a list admin who did not remember the real email adress used to manage the list.
Interesting.
As far as slow import times that should be left to the discretion of the user. If they are willing to opt-in to a passwords step, and spend hours on it, then why not...
This is a relevant drawback: "What about an import of two lists with members which are the same person, but with possibly separate email addresses and/or passwords?" What if it's the same email but different passwords
On 2024-09-17 11:59:00 -0000 (-0000), Sam Darwin via Mailman-users wrote: [...]
What if it's the same email but different passwords
This precisely. MM2 did let users specify a password, but by default it simply assigned them a new randomly-generated one for each list at time of subscription.
In the case of one environment I migrated to MM3, we actually also had multiple list domains with many of our users subscribing to lists on more than one domain. MM3's proper multi-tenancy allowed us to combine the lists for all those domains into a single deployment, with a side effect being that if a user creates a login for one domain they'll reuse that same login for every other domain in the same environment. So at least for me, the answer is that MM2 had per-list subscriber passwords, while MM3's Django user backend gets you cross-domain accounts.
Another aspect of this is RBAC. A user may be a list subscriber, moderator and owner. Instead of separate moderator and owner passwords shared by multiple individuals, the user's unique password can get them access to all the roles they've been granted (and can also be individually reset or revoked without having to communicate a new password to every moderator). It's not just a matter of security, but also operational efficiency.
Jeremy Stanley
participants (4)
-
Jeremy Stanley -
Marc SCHAEFER -
Mark Sapiro -
Sam Darwin