Last modified: 2011-04-06 18:23:30 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T30306, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 28306 - RevDel: Suppressed username in file history is leaked in case of file transclusion (InstantCommons / $wgForeignFileRepos)
RevDel: Suppressed username in file history is leaked in case of file transcl...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.17.x
All All
: Normal major (vote)
: ---
Assigned To: Brion Vibber
: patch
Depends on:
Blocks: revdel
  Show dependency treegraph
 
Reported: 2011-03-29 14:07 UTC by Raimond Spekking
Modified: 2011-04-06 18:23 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
inverse isDeleted/local check (979 bytes, patch)
2011-04-01 20:06 UTC, Umherirrender
Details

Description Raimond Spekking 2011-03-29 14:07:16 UTC
Suppressed username in file history is leaked in case of file transclusion using InstantCommons / $wgForeignFileRepos

The username of the first file revision in this testcase is shown on the foreign wiki:

http://commons.wikimedia.org/wiki/File:Example_file_for_a_RevDel_bug.jpg

http://de.wikipedia.org/wiki/Datei:Example_file_for_a_RevDel_bug.jpg
Comment 1 Umherirrender 2011-04-01 20:06:28 UTC
Created attachment 8360 [details]
inverse isDeleted/local check

File::isDeleted( File::DELETED_USER ) is only checked for local files in ImagePage::imageHistoryLine. The attachment inverse the checks for isDeleted and for local files. That should fix this bug.
Comment 2 Brion Vibber 2011-04-06 18:23:30 UTC
Patch looks good; didn't apply (whitespace?) but doing the same switcharoo seems to do the job in my local testing, using ForeignDBRepo (same as the local configuration for Commons on the other Wikimedia sites).

ForeignAPIRepo doesn't expose the suppressed info through the API, so folks using the InstantCommons setup won't be affected.

Committed on trunk in r85555; should be merged down to 1.17 and production deployment as well.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links