If you are interested in cleaning up additional remnants:

I have since identified other similar changes that need to be made, and I have opened a new task, T397496, to track them.

Change #1161572 merged by jenkins-bot:

[mediawiki/core@master] Remove obsolete #toolbar fixed height CSS

https://gerrit.wikimedia.org/r/1161572

Change #1161572 had a related patch set uploaded (by Gerrit Patch Uploader; author: Anne Haunime):

[mediawiki/core@master] Remove obsolete #toolbar fixed height CSS

https://gerrit.wikimedia.org/r/1161572

@Od1n you should file a separate task for the changes you are suggesting. That's good practice in general, but particularly useful here when the "main" ticket is long-closed and has lots and lots of discussion unrelated to your suggestion.

Now that https://gerrit.wikimedia.org/r/c/mediawiki/core/+/317079 was merged in 2018 (and in particular, see the changes at the bottom of this page), we should undo https://gerrit.wikimedia.org/r/c/mediawiki/core/+/373403 (which was merged in 2017): its CSS is now useless, as we are no longer inserting empty #toolbar elements.

Change #1049617 had a related patch set uploaded (by Xcollazo; author: Xcollazo):

[mediawiki/core@master] On T207628, as part of performance tuning, WikiExporoter's BATCH_SIZE was set to 50000. There was no decisive benchmarking done to support that size. We have recently seen a lot of database pressure coming from this configuration.

https://gerrit.wikimedia.org/r/1049617

Change 873884 merged by jenkins-bot:

[mediawiki/core@master] Drop img_description from CommentStore temp table list

https://gerrit.wikimedia.org/r/873884

Change 873884 had a related patch set uploaded (by Zabe; author: Zabe):

[mediawiki/core@master] Drop img_description from CommentStore temp table list

https://gerrit.wikimedia.org/r/873884

Change 747225 abandoned by Krinkle:

[mediawiki/core@master] externalstore: Always use 'dbname' if set for an external cluster

Reason:

https://gerrit.wikimedia.org/r/747225

Change 747225 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@master] externalstore: Always use 'dbname' if set for an external cluster

https://gerrit.wikimedia.org/r/747225

Yesterday the zombie apocalypse hit me: T294796 ;)

See T288201: Re-enable var() in inline CSS for plans of re-enabling var().

Assuming this is resolved given patches merged

Change 675120 merged by jenkins-bot:

[mediawiki/core@master] Follow-up 335fabf5f: Don't misuse qc_value in DeadendPages

https://gerrit.wikimedia.org/r/675120

Change 675120 had a related patch set uploaded (by TK-999; author: TK-999):
[mediawiki/core@master] Follow-up I1ef297: Don't misuse qc_value in DeadendPages

Hmm. it appears that chrome already patched this

Multiple patches have been made in the meantime. Here are some I found in close proximity to the code we are talking about:

• https://gerrit.wikimedia.org/r/636063 (T263592)
• https://gerrit.wikimedia.org/r/637035 (T266707)
• https://gerrit.wikimedia.org/r/640249 (T267370, T267587)

In T226751#6823394, @thiemowmde wrote:

There is still code in FormatMetadata.php that assumes GPSAltitude is always a number. I see this error about 50 times in the past 30 days. I'm not going to make a patch for this as it is rare and what we are looking at here appears to be a rabbit hole: there are sooooo many code paths in this file that just assume what they get is an integer or float, when it is most likely a string, and possibly even an empty one. I don't know how to fix this without touching half of the file.

The patch before was about latitude and longitude.

There is still code in FormatMetadata.php that assumes GPSAltitude is always a number. I see this error about 50 times in the past 30 days. I'm not going to make a patch for this as it is rare and what we are looking at here appears to be a rabbit hole: there are sooooo many code paths in this file that just assume what they get is an integer or float, when it is most likely a string, and possibly even an empty one. I don't know how to fix this without touching half of the file.

After carefully analyzing this wish, the Community Tech team has decided to decline this wish. There are two primary reasons why. First, the issue has largely been resolved. Second, the wish conflicts with team policy. You can read our rationale and proposed workarounds for people who are still interested in such support in our 2019 wishlist status update report. Thank you!

In T230402#6483672, @Mitchell.brown.erdc wrote:

This issue of the redirect is affecting my Mediawiki instance. I have updated my instance to MW 1.34.2 hoping that the fix would be automatic, but my user's information is still available with the Special:Redirect/user/# hack. I have searched for how to suppress users, but have so far been unable to figure it out. No where on this issue page have I seen the steps to resolve the issue, only that fixes were made to Mediawiki to somehow prevent this. Can someone point me in the right direction? I've been given until Oct 5 to resolve this vulnerability. Thanks in advance.

Can someone test this in WMF prod/master?

Per comment

This issue of the redirect is affecting my Mediawiki instance. I have updated my instance to MW 1.34.2 hoping that the fix would be automatic, but my user's information is still available with the Special:Redirect/user/# hack. I have searched for how to suppress users, but have so far been unable to figure it out. No where on this issue page have I seen the steps to resolve the issue, only that fixes were made to Mediawiki to somehow prevent this. Can someone point me in the right direction? I've been given until Oct 5 to resolve this vulnerability. Thanks in advance.

This was reopened without further information. Does this happen on the same code? Or was it closed/opened on accident?