Some preliminary notes regarding an implementation:

• includes/media/JpegHandler.php swapICCProfile already implements invoking exiftool
• exiftool supports removing all GPS tags via -gps:all= -- https://www.exiftool.org/geotag.html
• to be figured out: how to invoke JpegHandler from UploadBase (there's also TransformationalImageHandler.doTransform, but it seems to be related to thumbnail generation)

the external code loading was removed

Instead of waiting, I've gone ahead and removed this, as this seemed like a big security risk (someone could buy the domain http://maps.wikivoyage-ev.org)
https://fr.wikivoyage.org/w/index.php?title=MediaWiki%3ACommon.js&diff=566274&oldid=497402

I see that user isn't very active any longer. @VIGNERON sometimes ventures to fr.wikivoyage and they have some experience. Maybe they can help find people who can assist cleaning up all the years of neglect in the scripts and styling there.

I can also confirm that https://diff.wikimedia.org/wp-json/ and a few of the other, specific api endpoints under that url now seem disabled.

In T290493#9754259, @CKoerner_WMF wrote:

We've restricted access to the WP API on Diff with a recent update. Can someone please confirm if this issue is resolved according to the description?

We've restricted access to the WP API on Diff with a recent update. Can someone please confirm if this issue is resolved according to the description?

This results in a slightly annoying (although probably harmless) Error with Permissions-Policy header: Origin trial controlled feature not enabled: 'browsing-topics'. console error, at least when using the Beta channel release of Chrome.
Not sure what's happening - there doesn't seem to be any ongoing origin trial for topics, it shows up (and is enabled) in my settings. But the chrome://flags/#privacy-sandbox-ads-apis feature flag seems to be disabled by default.

The easiest thing to do here would be to make sure the end user knows that they should strip location data before uploading. Apparently we already do this in UploadWizard but not other upload workflows. This is very much a case of patch-welcome if somebody wants to do that. It could be a warning box or note on the uploading workflow (perhaps during the upload itself "This contains location data are you sure you want to upload it?" for example.

There was some discussion about this in the Wikipedia weekly Facebook channel. I'm summarizing the conversation here so it's not lost so please don't shoot the messenger :-). I've anonymized all this feedback - but if you want me to credit you for any of this please drop me a note in Facebook:

Yes , the special WikiVoyage nearby feature got deprecated and the code removed T332785: Remove custom old nearby functionality for Wikivoyage from Kartographer. So this ticket should be invalid now.

The special WikiVoyage nearby feature got deprecated and the code removed T332785: Remove custom old nearby functionality for Wikivoyage from Kartographer. So this ticket should be invalid now.

Another point to debate is if the relation of temporary and permanent account is not public, should it be available infinitely? Temporary account itself does not contain PII as long as IPs are removed after 90 days, but there are some edge cases: temporary user session may be somehow preserved after creation of permanent account, either due to (1) having a temporary session in one wiki and regular one on another due to failure of central login, or (2) replicaton of session (e.g. by some backup/sync feature of browser), so IPs would be available until 90 days of last temporary account action, which may be more than 90 days after regular account creation if we do not invalidate the temporary account after creation of a permanent one.

Note: currently temporary and permanent account are connected publicly. cf T357498: Temp account creations do not appear in Special:Log

The privacy policy is being added with the patch for https://phabricator.wikimedia.org/T351137

Just to close the loop on this 2+ year old incident and hopefully resolve it reasonably well enough:

1. It looks like the earliest we started doing anything at gitlab.wikimedia.org was June of 2021 or so? And most of that work was experimentation/testing, so that environment isn't implicated at all, given the date of the codecov incident. And there isn't any obvious usage of codecov based upon trivial searches.
2. As noted above, gerrit/jenkins should not be implicated at all given their configuration, and even with the trivial search mentioned within the task description, there's no immediate evidence that codecov's bash uploader was even used within a canonical gerrit repository.
3. As for github:
   1. There are at least a few repos which currently make use of codecov's bash uploader, but save pywikibot (which was ruled not vulnerable in T281750#7054720 - and the newer codecov bash upload integration appears to be from 2023) these all appear to be more external repos that are not used directly within Wikimedia production.
   2. Some Travis CI deployment stages were disabled by @Ladsgroup in T281750#7055735 and remain disabled. I don't believe these repos were ever vulnerable to this specific codecov issue, even though those repos use codecov, but I suppose this was done out of an abundance of caution in case any relevant environment variable might have been leaked.
   3. Performing various searches (codecov.io/bash, Codecov-bash, Codecov-action, Codecov-circleci-orb, Codecov-bitrise-step) for potentially relevant, vulnerable code under github.com/wikimedia currently yields no true positive results.
   4. As an extra effort, I wrote a script to also find canonical github.com/wikimedia repos, clone them and search git log for the aforementioned, potentially problematic codecov strings. This produced:
      1. https://github.com/wikimedia/edx-platform (0f29b144dd)
      2. https://github.com/wikimedia/docker-library-images (22c68d5eca)
      3. https://github.com/wikimedia/apps-android-commons (707c52c768)

+1, we need a solution for this. It's been 10 years, and in my opinion, it should not be considered a low priority. Privacy is paramount, and asking to manually remove GPS metadata is counterproductive

Privacy policy to link to https://foundation.wikimedia.org/wiki/Special:MyLanguage/Policy:Non-wiki_privacy_policy

Change 835252 abandoned by Samtar:

[operations/mediawiki-config@master] InitialiseSettings.php: Add oathauth-verify-user to default bureaucrat

Reason:

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