Page MenuHomePhabricator

'upload'-only protection does not work for file reversions
Closed, ResolvedPublic

Description

Author: saibotrash

Description:
... only protecting against uploads (and file version reverts) is a low side-effects measure against edit/upload wars. However it doesn't seem to work.

Does somebody know if that is a bug or a feature? http://commons.wikimedia.org/w/index.php?title=File:AaatestSonnepalmenstrand-portrait_new.jpg&action=history The page is upload=sysop protected and it works (I cannot upload with my test account). But the testaccount can revert to another file version. This is pretty stupid since I thought it isn't enough at upload edit wars to upload protect ([[COM:P]] should be adjusted then)... Also that is a bad choice for high-visibility files which have more than one version. Mediawiki displays the reverts as "uploads" - but apparently doesn't apply the protection status. I would have assumed that it protects against that reverts. First because it is useful, second because mediawiki [//commons.wikimedia.org/w/index.php?title=Special:Log&page=File%3AAaatestSonnepalmenstrand-portrait+new.jpg titles the reverts as uploads in the logs] Asked in Wikimedia tech channel on IRC but got no answer.

I tried again at "my" file: [[:File:AaatestSonnepalmenstrand-portrait_new.jpg#filehistory]] Of, course - still the same.

User:Bidgee in [[commons:COM:VP#upload protection doesn't work for reverts]] seemed to agree that this is a bug and not a feature.


Version: 1.18.x
Severity: normal

Details

Reference
bz34209
TitleReferenceAuthorSource BranchDest Branch
kubernetes: add workers with D stuck processes alertrepos/cloud/toolforge/alerts!11dcaroadd_d_processes_alertmain
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:11 AM
bzimport set Reference to bz34209.

Let me make sure I understand this correctly. In order to fully protect an image page, one needs to separately apply restriction on upload, and another restriction on edit. You're making the case that that should be a one step process, correct?

I'd like to get Howie's take on the priority of this.

Testing locally I get:
"You do not have permission to upload this file, for the following reason:

This page has been protected to prevent editing."

...when trying to revert a page with 'upload' protection to 'sysop' as a non-privileged user.

saibotrash wrote:

note: my original title was: "upload protection doesn't work for reverts → edit wars can continue if not also edit protection is used". If you change it please mention that you did. Also my first comment begins with "...".

No, I do not mean this title someone gave this bug.

I mean that if a page if protected with "upload=sysop" then file version reverts should only be possible by sysops. According to my test they are possible also without a sysop bit.

(In reply to comment #2)

Testing locally I get:
"You do not have permission to upload this file, for the following reason:

This page has been protected to prevent editing."

...when trying to revert a page with 'upload' protection to 'sysop' as a
non-privileged user.

Note that this is with no 'edit' nor 'move' protection. I can't reproduce this on my checkout of wmf1.19 as well as trunk. Maybe it's an extension problem?

saibotrash wrote:

Here was so long no comment that I forgot that I used this file as test case here and had unprotected in the meantime - sorry. So the file was not protected at Platonides test file revert. http://commons.wikimedia.org/w/index.php?title=Special:Log&page=File%3AAaatestSonnepalmenstrand-portrait+new.jpg

However, I have tested now again with a non-admin account: now reverting is not possible anymore at this Commons file (Commons runs MW 1.19).

At de.wikipedia (until 2012-03-01 on 1.18) the revert still is possible despite upload protecting. http://de.wikipedia.org/wiki/Datei:Logo_African_Pygmy_Goat.png So that seems to have been silently fixed with 1.19... http://de.wikipedia.org/w/index.php?title=Datei:Logo_African_Pygmy_Goat.png&diff=100231158&oldid=100231137