Page MenuHomePhabricator

Create a checkuser entry for global rename requests
Open, MediumPublicBUG REPORT

Description

Currently global rename requests aren't logged by checkuser while they might be exploited in various fashions for abusing.

Event Timeline

We can probably do this in a similar manner to how AbuseFilter does it...

Special:GlobalRenameRequest can be used from any wiki, and feeds into the queue on meta. Should the CU entries be logged on the wiki where the user made the request? Or should it be logged to a central wiki (metawiki)?

And should the CU logs be updated during the rename? Or should they forever point to the username that made the request?

Special:GlobalRenameRequest can be used from any wiki, and feeds into the queue on meta. Should the CU entries be logged on the wiki where the user made the request? Or should it be logged to a central wiki (metawiki)?

I'd say that, if possible, should log to both.

And should the CU logs be updated during the rename?

IMHO yes, to allow better searching in the CU-log instead of having to
remember if this or that user were once renamed.

In order to counter increased abuse of this feature, I'd ask for some eyes in this task if at all possible. Thank you.

And should the CU logs be updated during the rename?

IMHO yes, to allow better searching in the CU-log instead of having to
remember if this or that user were once renamed.

I am afraid this is not currently possible, until T145265 is resolved.

@Huji Can at least the first part (creating a CU log entry) be actioned? Thanks.

Per T131207#2164035, it looks like this is how AF does it:

if ( ExtensionRegistry::getInstance()->isLoaded( 'CheckUser' )
      && strpos( $wgAbuseFilterNotifications, 'rc' ) === false
) {
      $rc = $entry->getRecentChange();
      CheckUserHooks::updateCheckUserData( $rc );
}

I'm guessing the relevant place to do something similar in CA is probably in GlobalRenameUser.php around here, since there's a ManualLogEntry there where we could call getRecentChange() as the rename was processed. Or at least this seems the simplest way to do the CU logging piece without getting more advanced as discussed in T131207#2212568.

Huji raised the priority of this task from High to Needs Triage.Jun 15 2020, 10:58 PM

The task is not claimed and priority was set several years ago. Unprioritizing.

Niharika subscribed.

This was brought to my attention by @drochford. Anti-Harassment Tools can do a technical investigation into this ticket in the next few weeks. Sorry, I can't be more specific around timelines - there is a fair amount of SecurePoll work on the team at the moment.
Noting that this ticket is for adding an entry to the CU database for global renames. There will need to be follow-up tasks for displaying these entries, unless that can be achieved automatically.

Any update from Anti-Harrassment as to whether they would take this on (@Niharika)? Just don't want to trample on your current work if it's being worked on / going to be soon.

Working on this. Currently I have written code to do this but have not added tests yet. It will require a change to both CentralAuth and CheckUser.

My current changes would add a cu entry for the wiki used to make the request and the central wiki (if this is different to the wiki used to make the request). It would use the text "username requested a global rename" with the username replaced by the user who made the request. @MarcoAurelio what do you feel about that amount of info? Is it too much or too little? I didn't want to add much more without checking as it may be something that only centralauth-rename users should have access to. One thing to note is that due to current limitations with CheckUser any info included in that message is static and cannot be updated. This means that clearly specifying old username -> new username may be better so that in future it's clear how the chain went. If you have any ideas please detail them.

An example with the current message is shown below:

image.png (57×1 px, 19 KB)

Likely to have lost the patch by now. Will look at this later.

Aklapper changed the subtype of this task from "Task" to "Bug Report".Nov 21 2022, 2:52 PM