Page MenuHomePhabricator

CheckUser: [Proposal] Remove support for storing encrypted recipients of EmailUser emails
Closed, ResolvedPublic1 Estimated Story Points

Description

Summary

CheckUser contains functionality to optionally store the encrypted recipients for emails sent via Special:EmailUser. The encryption mechanism used by this logic is outdated and needs an update, but since the feature appears to be unused, it may be better to completely remove it.

Note that CheckUser currently also stores an MD5 hash (not an encrypted ciphertext) of the recipient's email and user ID plus the MW install's secret key in the private events table. This MD5 hash is then displayed in the CheckUser results and is always enabled. There is no intention to change this functionality.

Background

  • CheckUser contains functionality to optionally store the encrypted recipients for emails sent via Special:EmailUser in the cupe_private column
  • This feature is off by default (including in WMF production), unless the operator set $wgCUPublicKey to a valid RSA public key.
  • The RC4 cipher used by this feature is unavailable on many modern systems, e.g. Fedora and derivatives since 2015,[1] due to security concerns.
  • It's not clear if anyone is actually using this functionality. It was implemented in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/24503 without any BZ reference. There is also no maintenance script or UI where the stored data could be accessed by functionaries.
  • Removing this functionality would allow us to drop the cupe_private column from the cu_private_event table as unused, as it is only used by this feature

[1] https://fedoraproject.org/wiki/Changes/RemoveSSL3andRc4

Acceptance criteria

  • The functionality in CheckUser to store encrypted recipients of emails sent via EmailUser in the cupe_private column is either sunset due to lack of usage, or this task is closed in favor of T384398.
  • CheckUser still keeps a hash of the recipient's email address, user ID and the local install's secret key in the cupe_params field for EmailUser events, like it has been doing.

Event Timeline

JJMC89 subscribed.
On wikitech-l, @mszabo wrote:

It is not enabled in WMF production

Encrypted email recipients are stored in WMF production. CheckUsers use this to see abuse of Special:EmailUser.

There is also no maintenance script or UI where the stored data could be accessed by functionaries.

I believe this is intentional. Seeing the same hash means it is the same recipient.

On wikitech-l, @mszabo wrote:

It is not enabled in WMF production

Encrypted email recipients are stored in WMF production. CheckUsers use this to see abuse of Special:EmailUser.

There is also no maintenance script or UI where the stored data could be accessed by functionaries.

I believe this is intentional. Seeing the same hash means it is the same recipient.

Hey @JJMC89 , thanks for your response!

Sorry, I think my message was unclear—I'll update the ticket body to clarify. CheckUser does currently store an MD5 hash (not an encrypted ciphertext) of the recipient's email and user ID plus the MW install's secret key in the private events table. This is working as you described, and there is no intention to change this functionality.

What we'd like to remove is the functionality to store an RC4-encrypted blob holding the recipient's email address and user ID in a different field in the same table. There's nothing that retrieves this data at the moment, and the configuration variable that'd be used for encryption isn't set in Wikimedia production, so nothing is currently stored there.

Dreamy_Jazz updated the task description. (Show Details)
Dreamy_Jazz updated the task description. (Show Details)

I think this could go forward, as it's been a month without comment.

I think this could go forward, as it's been a month without comment.

I would agree. It would also allowing removing a column from the cu_private_event table, which should reduce the size of the table. Therefore, it would be good to do sooner than later.

Dreamy_Jazz set the point value for this task to 1.Aug 11 2025, 2:15 PM

We have dropped the cupe_private column and the code that was using RC4 to populate this column