forgive my ignorance, but couldn't you just avoid making people a sysop if they didn't have a verified email? Or is the intent here to remove fumble-fingered mistakes?

rd232 wrote:

There's relatively little benefit to making people provide a verified email address at one point time. On long-lasting wikis, verification might have been 5-10 years ago. The aim of this bug is to make user rights dependent on a verified email address *on an ongoing basis*. So for example if the user removes the email address, or replaces it with another but doesn't verify it, the user rights associated with their user group are automatically suspended, until a verified email address is provided, when they're automatically re-enabled. This would be more useful if there are situations where the "verified" status of an existing email address can be automatically revoked (eg if emails to the user bounce); I'm not sure if that's the case but if it isn't that's a separate issue.

I should note that this bug is partly because of a desire to use email notifications to enhance security, which is obviously dependent on a current email address. (A "verified" email address may not be current, but it's the best proxy available at the moment.) See also Bug 26227 - "Notify user by email when password changed"; Bug 29856 - "Email notification when verified email address is changed or removed"; and Bug 29857 - "Welcome back email notification after renewed account activity".

happy.melon.wiki wrote:

I believe we already have an 'emailconfirmed' implicit usergroup. The simplest way of implementing this would be to implement the opposite, an 'emailunconfirmed' group. Then $wgRevokePermissions['emailunconfirmed'][<perm>] revokes the right when the user is unverified. This also seems to have the best aesthetic of fine-grained control over which permissions are affected by the feature.

rd232 wrote:

That sounds good, but it should be "noemailconfirmed", since we're not just interested in cases of "email address exists, but isn't confirmed" but also "no email address given".

For autopromote the condition APCOND_EMAILCONFIRMED is available.

rd232 wrote:

(In reply to comment #5)

For autopromote the condition APCOND_EMAILCONFIRMED is available.

Yes, I think that does the requested feature for autoconfirmed users, because of the way autoconfirmed status is checked every time user rights are verified (http://www.mediawiki.org/wiki/Manual:$wgAutopromote). So that's something. But that's special to that pseudo-group and can't easily be extended to others.

A year later...

How relevant is this problem today? How good is the solution proposed? How complex the potential solution?

I think the implementation of this should be similar to T150562: Be able to force OATHAuth for certain user groups. If having a confirmed email is a requirement for group membership, you lose that membership when your email becomes unconfirmed (manual removal, BounceHandler, etc.) and you automatically regain it when your email is confirmed again.

Due to the inaction on this task for many years and the strong likelihood no further work will be accomplished, the Security-Team proposes that we decline this task as part of Security backlog cleanup efforts. We would like to take some action regarding this task one month from now, on 2025-02-13.