Page MenuHomePhabricator

AlexisJazz
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Thursday

  • Clear sailing ahead.

User Details

User Since
Feb 23 2018, 10:35 PM (86 w, 3 d)
Availability
Available
LDAP User
Unknown
MediaWiki User
Alexis Jazz [ Global Accounts ]

Recent Activity

Sat, Oct 19

AlexisJazz updated subscribers of T43025: Track file usage history.

@Majora I want this.

Sat, Oct 19, 1:39 AM · Commons, Multimedia, MediaWiki-File-management
Restricted Application added a project to T43025: Track file usage history: Commons.
Sat, Oct 19, 1:32 AM · Commons, Multimedia, MediaWiki-File-management
AlexisJazz awarded T43025: Track file usage history a Evil Spooky Haunted Tree token.
Sat, Oct 19, 1:32 AM · Commons, Multimedia, MediaWiki-File-management

Wed, Oct 16

AlexisJazz added a comment to T234192: Automatic upload comments by Upload Wizard are unhelpful, make them more informative.

One minor thing to note, that sometimes this description is used to run stats on how popular different upload methods are. However, that would be a silly reason to keep it the way it is. I've always been kind of annoyed by the lack of descriptive description.

Wed, Oct 16, 3:48 AM · UploadWizard, Commons

Sun, Oct 13

AlexisJazz added a comment to T234192: Automatic upload comments by Upload Wizard are unhelpful, make them more informative.

@Masumrezarock100: I don't see general agreement yet how exactly to fix this task (there are several suggestions in the task description), so I don't think this task is ready to receive a patch yet...? I might misinterpret though.

Sun, Oct 13, 3:54 PM · UploadWizard, Commons

Sat, Oct 12

AlexisJazz added a comment to T124101: Specific revisions of multiple files missing from Swift - 404 Not Found returned.

https://commons.wikimedia.org/wiki/File:Busan_tower_by_night.jpg First four revisions missing!

Sat, Oct 12, 4:49 PM · User-Josve05a, Operations, Multimedia, SRE-swift-storage, Commons
AlexisJazz created T235329: When adding depict statements on Commons, include more information in the edit summary.
Sat, Oct 12, 1:19 PM · StructuredDataOnCommons, Commons

Fri, Oct 11

AlexisJazz added a comment to T235188: Some revisions' contents are incorrect in the cache - wrong contents shown in history & diffs.

I haven't read all this, but could https://commons.wikimedia.org/w/index.php?title=Commons:Administrators%27_noticeboard&oldid=370199209#A_contribution_has_been_deleted?_(that,_or_database_error?) be related?

Fri, Oct 11, 2:59 PM · MW-1.35-notes (1.35.0-wmf.2; 2019-10-15), Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Language-Team (Language-2019-October-December), Patch-For-Review, MediaWiki-General, affects-translatewiki.net

Thu, Oct 3

AlexisJazz updated subscribers of T234192: Automatic upload comments by Upload Wizard are unhelpful, make them more informative.

@DannyS712 perhaps you could make the example above into something that would actually work? Also, @Fae asked if it would be possible to add information from the EXIF.

Thu, Oct 3, 5:55 PM · UploadWizard, Commons

Wed, Oct 2

Masumrezarock100 awarded T234192: Automatic upload comments by Upload Wizard are unhelpful, make them more informative a Love token.
Wed, Oct 2, 1:01 AM · UploadWizard, Commons

Mon, Sep 30

AlexisJazz added a comment to T234192: Automatic upload comments by Upload Wizard are unhelpful, make them more informative.

I did not say that "community consensus is required". I referred to some consensus / feedback which specific changes make sense and should be made. :)

Mon, Sep 30, 11:05 AM · UploadWizard, Commons
AlexisJazz added a comment to T234192: Automatic upload comments by Upload Wizard are unhelpful, make them more informative.
Mon, Sep 30, 10:35 AM · UploadWizard, Commons
AlexisJazz renamed T234192: Automatic upload comments by Upload Wizard are unhelpful, make them more informative from User created page with UploadWizard" upload comments are unhelpful, make them more informative. to "User created page with UploadWizard" upload comments are unhelpful, make them more informative..
Mon, Sep 30, 10:03 AM · UploadWizard, Commons
AlexisJazz renamed T234192: Automatic upload comments by Upload Wizard are unhelpful, make them more informative from Make upload comments more informative to User created page with UploadWizard" upload comments are unhelpful, make them more informative..
Mon, Sep 30, 10:03 AM · UploadWizard, Commons
AlexisJazz updated the task description for T234192: Automatic upload comments by Upload Wizard are unhelpful, make them more informative.
Mon, Sep 30, 10:02 AM · UploadWizard, Commons
AlexisJazz renamed T234192: Automatic upload comments by Upload Wizard are unhelpful, make them more informative from "User created page with UploadWizard" upload comments are unhelpful, make them more informative to Make upload comments more informative.
Mon, Sep 30, 10:01 AM · UploadWizard, Commons
AlexisJazz updated the task description for T234192: Automatic upload comments by Upload Wizard are unhelpful, make them more informative.
Mon, Sep 30, 9:57 AM · UploadWizard, Commons
AlexisJazz updated the task description for T234192: Automatic upload comments by Upload Wizard are unhelpful, make them more informative.
Mon, Sep 30, 9:57 AM · UploadWizard, Commons
AlexisJazz updated the task description for T234192: Automatic upload comments by Upload Wizard are unhelpful, make them more informative.
Mon, Sep 30, 9:55 AM · UploadWizard, Commons
AlexisJazz created T234192: Automatic upload comments by Upload Wizard are unhelpful, make them more informative.
Mon, Sep 30, 9:53 AM · UploadWizard, Commons
AlexisJazz added a comment to T225566: Unknown warning: "duplicateversions" when trying to upload a file with UploadWizard that already exists as an old revision; no warning with Special:Upload.

When uploading the first revision of https://commons.wikimedia.org/wiki/File:Stek5.jpg (not deleted, just overwritten), I now get no error.

Mon, Sep 30, 9:22 AM · Multimedia, UploadWizard, Commons

Tue, Sep 24

AlexisJazz added a comment to T191802: [Epic] Determine a strategy to store files between 5 and 100 Gb.

With 4K video becoming more and more commonplace, 4GB isn't always enough. https://commons.wikimedia.org/wiki/File:Politparade.webm and https://commons.wikimedia.org/wiki/File:Genderwahn.webm are encoded to fit within MediaWiki's limit, which isn't a good sign. And 9 Mbps for 4K.. Well.. Could be worse, but.. not ideal. And they lack 1440p and 2160p transcodes, presumably due to the file size limit.

Tue, Sep 24, 2:43 PM · SRE-swift-storage, Multimedia
AlexisJazz merged T233721: Increase the 4GB file size upload limit into T191802: [Epic] Determine a strategy to store files between 5 and 100 Gb.
Tue, Sep 24, 2:42 PM · SRE-swift-storage, Multimedia
AlexisJazz merged task T233721: Increase the 4GB file size upload limit into T191802: [Epic] Determine a strategy to store files between 5 and 100 Gb.
Tue, Sep 24, 2:42 PM · Multimedia
AlexisJazz created T233721: Increase the 4GB file size upload limit.
Tue, Sep 24, 2:15 PM · Multimedia

Sep 16 2019

AlexisJazz added a comment to T20112: Retain URL as metadata on upload-by-url.

It would probably be good in general to have an additional structured metadata area for this sort of thing... and license info... :P

Sep 16 2019, 6:25 PM · Commons, Multimedia, MediaWiki-Uploading

Sep 12 2019

AlexisJazz added a comment to T232756: Automatically remove confirmed user right when eligible for autoconfirmed.

As written, this is not a MediaWiki core issue: the "confirmed" group is a Wikimedia configuration.
https://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php

// Confirmed can do anything autoconfirmed can.
// T213003: this should happen after all the extensions had been loaded, but
// before their extension functions in case they're relying on permissions.
array_unshift( $wgExtensionFunctions, function () {
	global $wgGroupPermissions;
	$wgGroupPermissions['confirmed'] = $wgGroupPermissions['autoconfirmed'];
	$wgGroupPermissions['confirmed']['skipcaptcha'] = true;
} );

If the request is to add a variable like $wgAutodemoteOnce with additional possibilities beyond those of https://www.mediawiki.org/wiki/Manual:$wgAutopromoteOnce , we may need a stronger use case.

Sep 12 2019, 9:51 PM · MediaWiki-User-management
AlexisJazz created T232756: Automatically remove confirmed user right when eligible for autoconfirmed.
Sep 12 2019, 4:21 PM · MediaWiki-User-management

Sep 11 2019

AlexisJazz created T232657: Increase the rate limit for moves on Commons for autopatrollers to 32/minute.
Sep 11 2019, 7:19 PM · Wikimedia-Site-requests, Commons
AlexisJazz added a comment to T214230: Temporary switch crosswiki uploads off across all wikis.

Enabling a feature that causes this much of a mess is not a solution for anything.

Please try to see this from a casual user's PoV: with this feature they doesn't need to worry about where is the picture, how to upload it, how to come back from commons to the article etc. They have a seamless workflow, hopefully in their native language, that makes the picture instantly usable in their article. If we disable it, they'll have to go through another help page explaining how to upload pictures etc. which would decrease the chance of a successful edit even more. This is the problem for which cross-wiki uploads are the solution.
I'm not denying this creates problems for wiki maintainers, and I encourage all of you to log bugs and feature requests against it and push for them to be prioritized, but disabling the whole thing is not the right step forward for our projects.

Sep 11 2019, 7:10 PM · Patch-For-Review, Africa-Wikimedia-Developers, Wikimedia-Site-requests, Crosswiki, Commons
AlexisJazz added a comment to T214230: Temporary switch crosswiki uploads off across all wikis.

Disabling cross-wiki uploads instead of working on new tools to help curate and cleanup those files is a huge step backwards for the good faith newbies who want to contribute pictures to articles.
I am aware of the discussions regarding the lack of ownership - wiki admins do not see the file and Commons admins are overworked, but the solution is to develop new tools to curate these uploads rather than just disabling them.
Very likely, temporarily would be for years in this case.

Sep 11 2019, 10:44 AM · Patch-For-Review, Africa-Wikimedia-Developers, Wikimedia-Site-requests, Crosswiki, Commons

Jul 22 2019

AlexisJazz added a comment to T214230: Temporary switch crosswiki uploads off across all wikis.

Disabling crosswiki uploads permanently would be a relief..

Jul 22 2019, 3:52 PM · Patch-For-Review, Africa-Wikimedia-Developers, Wikimedia-Site-requests, Crosswiki, Commons

Jul 21 2019

AlexisJazz added a comment to T228317: Increase the rate limit for moves on Commons for file movers to 100/minute.

@Urbanecm Arjoopy got an error message about 900 edits per 180 seconds.

Jul 21 2019, 8:33 PM · Community-consensus-needed, User-DannyS712, Wikimedia-Site-requests, Commons
AlexisJazz added a comment to T228317: Increase the rate limit for moves on Commons for file movers to 100/minute.

I don't know if I even support this myself anymore.. The only thing that should be fixed is the error message. @DannyS712, did you already create a task for that?

Jul 21 2019, 2:31 PM · Community-consensus-needed, User-DannyS712, Wikimedia-Site-requests, Commons

Jul 20 2019

Multichill awarded T228317: Increase the rate limit for moves on Commons for file movers to 100/minute a Dislike token.
Jul 20 2019, 9:58 PM · Community-consensus-needed, User-DannyS712, Wikimedia-Site-requests, Commons

Jul 18 2019

AlexisJazz added a comment to T228317: Increase the rate limit for moves on Commons for file movers to 100/minute.

(this would be in addition to 100 moves/minute for file movers)

Jul 18 2019, 8:29 PM · Community-consensus-needed, User-DannyS712, Wikimedia-Site-requests, Commons

Jul 17 2019

AlexisJazz added a comment to T228317: Increase the rate limit for moves on Commons for file movers to 100/minute.

@DannyS712 no, currently not. But the rate limit has one purpose: to curb vandalism without limiting any ordinary use. Limiting vetted users to the degree that it hampers their work means it's not configured correctly.

This is not entirely true. The main purpose is to maintain the stability of the servers, with the (very welcome but) secondary purpose of inhibiting vandalism until a sysop can block them. That means that well-meaning community members may from time to time bump into one of these limits.

Jul 17 2019, 7:25 PM · Community-consensus-needed, User-DannyS712, Wikimedia-Site-requests, Commons
AlexisJazz updated the task description for T228317: Increase the rate limit for moves on Commons for file movers to 100/minute.
Jul 17 2019, 6:48 PM · Community-consensus-needed, User-DannyS712, Wikimedia-Site-requests, Commons
AlexisJazz added a comment to T228317: Increase the rate limit for moves on Commons for file movers to 100/minute.

@Urbanecm Thanks, I understand it now, the configuration is on top of the defaults.

Jul 17 2019, 6:23 PM · Community-consensus-needed, User-DannyS712, Wikimedia-Site-requests, Commons
AlexisJazz added a comment to T228317: Increase the rate limit for moves on Commons for file movers to 100/minute.

@DannyS712 that's on top of the MediaWiki defaults? MediaWiki default is 8 moves per minute AFAIK, which would seem plausible if the system was counting Arjoopy's moves over 2 minutes.

Jul 17 2019, 6:06 PM · Community-consensus-needed, User-DannyS712, Wikimedia-Site-requests, Commons
AlexisJazz updated subscribers of T228317: Increase the rate limit for moves on Commons for file movers to 100/minute.
Jul 17 2019, 6:02 PM · Community-consensus-needed, User-DannyS712, Wikimedia-Site-requests, Commons
AlexisJazz added a comment to T228317: Increase the rate limit for moves on Commons for file movers to 100/minute.

@DannyS712 no, currently not. But the rate limit has one purpose: to curb vandalism without limiting any ordinary use. Limiting vetted users to the degree that it hampers their work means it's not configured correctly.

Jul 17 2019, 5:59 PM · Community-consensus-needed, User-DannyS712, Wikimedia-Site-requests, Commons
AlexisJazz updated the task description for T228317: Increase the rate limit for moves on Commons for file movers to 100/minute.
Jul 17 2019, 5:43 PM · Community-consensus-needed, User-DannyS712, Wikimedia-Site-requests, Commons
AlexisJazz created T228317: Increase the rate limit for moves on Commons for file movers to 100/minute.
Jul 17 2019, 5:38 PM · Community-consensus-needed, User-DannyS712, Wikimedia-Site-requests, Commons

Jul 16 2019

AlexisJazz added a comment to T227957: "API request failed (readonly): The wiki is currently in read-only mode." error for 3 in 5035 edits.

@Nirmos "on any Wikimedia project I know of", you don't know Commons, do you? This is normal. According to https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals/Archive/2018/06#Rate_limit_is_at_90_edits_per_minute the ratelimit on Commons is set at 10500 per 3 minutes for patrolled/autopatrolled/image reviewers. (not sure if this is still the current setting.. I thought I ran into it again some time ago)

Jul 16 2019, 5:16 PM · Commons

Jul 13 2019

AlexisJazz added a comment to T227957: "API request failed (readonly): The wiki is currently in read-only mode." error for 3 in 5035 edits.

API request failed (readonly): The wiki is currently in read-only mode. <i>at Sat, 13 Jul 2019 22:21:04 GMT</i> <u>served by mw1284</u> (for https://commons.wikimedia.org/wiki/File:10_Yuan_-_Bank_of_Honan_Province_(1922)_02.jpg )

Jul 13 2019, 10:34 PM · Commons
AlexisJazz created T227957: "API request failed (readonly): The wiki is currently in read-only mode." error for 3 in 5035 edits.
Jul 13 2019, 9:43 PM · Commons

Jul 12 2019

AlexisJazz updated the task description for T227850: Transcode of a video gets turned upside down.
Jul 12 2019, 11:42 AM · TimedMediaHandler-Transcode, Commons, Wikimedia-Video
AlexisJazz created T227850: Transcode of a video gets turned upside down.
Jul 12 2019, 8:19 AM · TimedMediaHandler-Transcode, Commons, Wikimedia-Video

Jul 6 2019

AlexisJazz updated subscribers of T227301: Enable convert-to-DR button (gadget) for everyone on Wikimedia Commons.

Also requested at https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-AjaxQuickDelete.js#Edit_request. @Perhelion, @Rillke ?

Jul 6 2019, 1:20 PM · Commons

Jul 1 2019

AlexisJazz added a comment to T225897: Cannot restore an old version on Commons, only get a comparison.

@Taketa this happens when you try to restore a version with different structured data. (depicts or captions) If no structured data was altered, you get the plain text.

Jul 1 2019, 8:19 AM · CPT Initiatives (MCR), MediaWiki-Revision-backend, Commons
AlexisJazz renamed T225566: Unknown warning: "duplicateversions" when trying to upload a file with UploadWizard that already exists as an old revision; no warning with Special:Upload from Unknown warning: "duplicateversions" when trying to upload a file with UploadWizard that already exists as an old revision; no problem with Special:Upload to Unknown warning: "duplicateversions" when trying to upload a file with UploadWizard that already exists as an old revision; no warning with Special:Upload.
Jul 1 2019, 8:07 AM · Multimedia, UploadWizard, Commons
AlexisJazz added a comment to T225566: Unknown warning: "duplicateversions" when trying to upload a file with UploadWizard that already exists as an old revision; no warning with Special:Upload.

@Aklapper I changed the title again because it turns out to be a general issue.

Jul 1 2019, 8:06 AM · Multimedia, UploadWizard, Commons
AlexisJazz updated the task description for T225566: Unknown warning: "duplicateversions" when trying to upload a file with UploadWizard that already exists as an old revision; no warning with Special:Upload.
Jul 1 2019, 8:05 AM · Multimedia, UploadWizard, Commons
AlexisJazz renamed T225566: Unknown warning: "duplicateversions" when trying to upload a file with UploadWizard that already exists as an old revision; no warning with Special:Upload from Unknown warning: "duplicateversions" when uploading Terence Winter.jpg to Commons; no problem with Special:Upload to Unknown warning: "duplicateversions" when trying to upload a file with UploadWizard that already exists as an old revision; no problem with Special:Upload.
Jul 1 2019, 7:57 AM · Multimedia, UploadWizard, Commons

Jun 28 2019

AlexisJazz added a comment to T226672: File move/ rename tab not working in Commons.
Unable to proceed
You do not have permission to move this page, for the following reason:
Jun 28 2019, 5:54 AM · MW-1.34-notes (1.34.0-wmf.11; 2019-06-26), Wikidata-Campsite (Wikidata-Campsite-Iteration-∞), Multimedia, MediaWiki-File-management, Regression, Commons

Jun 21 2019

AlexisJazz added a comment to T226217: Assign mass-upload flag to autopatrolled users on Commons.

@Urbanecm in spirit, the vote was to determine the maximum allowable number. The outcome of the vote is either "unlimited" or "a finite number" depending on how much support you want. One million is a also a finite number, so it's the same in practice. So if UploadWizard would reliably start supporting a higher number in the future (who knows, could happen), autopatrolled users should get that. (this future-proofs the proposal) I imagine that higher number would be connected to the mass-upload flag anyway. At this moment, the technical limit is 500 so that's what it'll be. Anyone looking to upload more will probably prefer third party tools anyway.

Jun 21 2019, 7:28 PM · User-Urbanecm, User-DannyS712, Wikimedia-Site-requests, Commons
AlexisJazz added a comment to T226217: Assign mass-upload flag to autopatrolled users on Commons.

@DannyS712 thanks for the quick response! Perhaps move the "T214003" comment to the upload_by_url line, but that's just nitpicking.

Jun 21 2019, 1:43 AM · User-Urbanecm, User-DannyS712, Wikimedia-Site-requests, Commons

Jun 20 2019

AlexisJazz updated the task description for T226217: Assign mass-upload flag to autopatrolled users on Commons.
Jun 20 2019, 10:24 PM · User-Urbanecm, User-DannyS712, Wikimedia-Site-requests, Commons
AlexisJazz created T226217: Assign mass-upload flag to autopatrolled users on Commons.
Jun 20 2019, 10:08 PM · User-Urbanecm, User-DannyS712, Wikimedia-Site-requests, Commons

Jun 19 2019

AlexisJazz added a comment to T225566: Unknown warning: "duplicateversions" when trying to upload a file with UploadWizard that already exists as an old revision; no warning with Special:Upload.

I now got the same error when trying to upload https://upload.wikimedia.org/wikipedia/commons/archive/f/f8/20190615181201%21Stek5.jpg with UploadWizard, the first revision of https://commons.wikimedia.org/wiki/File:Stek5.jpg or https://upload.wikimedia.org/wikipedia/commons/archive/6/6e/20190618200102%21Sakuragicho_Station_Name_Board_Pikachu.jpg, the first revision of https://commons.wikimedia.org/wiki/File:Sakuragicho_Station_Name_Board_Pikachu.jpg.

Jun 19 2019, 5:05 PM · Multimedia, UploadWizard, Commons

Jun 16 2019

AlexisJazz updated the task description for T225566: Unknown warning: "duplicateversions" when trying to upload a file with UploadWizard that already exists as an old revision; no warning with Special:Upload.
Jun 16 2019, 6:34 PM · Multimedia, UploadWizard, Commons
AlexisJazz updated the task description for T225566: Unknown warning: "duplicateversions" when trying to upload a file with UploadWizard that already exists as an old revision; no warning with Special:Upload.
Jun 16 2019, 6:32 PM · Multimedia, UploadWizard, Commons

Jun 11 2019

AlexisJazz added a comment to T225566: Unknown warning: "duplicateversions" when trying to upload a file with UploadWizard that already exists as an old revision; no warning with Special:Upload.

The file in question. (unknown if copyvio or not, do not use for purposes other than testing)

Jun 11 2019, 8:39 PM · Multimedia, UploadWizard, Commons
Restricted Application added a project to T225566: Unknown warning: "duplicateversions" when trying to upload a file with UploadWizard that already exists as an old revision; no warning with Special:Upload: Multimedia.
Jun 11 2019, 8:38 PM · Multimedia, UploadWizard, Commons

Jun 10 2019

AlexisJazz added a comment to T124101: Specific revisions of multiple files missing from Swift - 404 Not Found returned.

https://commons.wikimedia.org/wiki/File:President_Lula_and_Marisa.jpg first two revisions missing.

Jun 10 2019, 3:14 PM · User-Josve05a, Operations, Multimedia, SRE-swift-storage, Commons

Jun 7 2019

AlexisJazz added a comment to T27707: Allow "html" in exif tags.

I'll do a more thorough investigation on removing them later on once I've got local XP & Vista instances to test with. Sounds like there may be more inconsistencies in terms of later changes in service packs that makes it hard to confirm in testing!

The Naughty.png exploit works on Windows 2000 SP4 with IE5. (I can't be arsed to install IE6 on it) So does ietest-htmlsig.jpg. ietest64-jpgsig.jpg does not work however, so indeed there may be a difference between jpg and png. This confirms that even Windows XP isn't vulnerable, provided you have SP3. (earlier service packs not tested)

Jun 7 2019, 10:37 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading

Jun 4 2019

AlexisJazz added a comment to T27707: Allow "html" in exif tags.

@brion What's the status? I wanted to upload https://www.flickr.com/photos/boellstiftung/25524909051/ but couldn't.

Jun 4 2019, 1:09 PM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading
AlexisJazz added a comment to T213484: Normalize file extensions (capital vs small letters; jpg vs jpeg) for new uploads on Commons.
Jun 4 2019, 12:38 PM · Multimedia, MediaWiki-Uploading, Commons

Feb 12 2019

Jeff_G awarded T213571: Ignore babel box the user has set to knowing at level 0 on Commons (and so have different behaviour to Wikidata) a Like token.
Feb 12 2019, 9:21 PM · Structured-Data-Backlog, Community-consensus-needed, WikibaseMediaInfo, Wikidata, Structured Data Engineering, MediaWiki-extensions-Babel

Feb 7 2019

AlexisJazz added a comment to T27707: Allow "html" in exif tags.

https://www.flickr.com/photos/tinto/30943950124/ and other photos from this Flickr user.

Perfect! Confirmed that the original file there fails to upload on test.wikipedia.org but uploads intact on my local instance with the patch. :D

I loaded the "naughty.png" on IE6 served as image/png. I see a fox. Perhaps your webserver was misconfigured in 2005?

I assure you I tested quite thoroughly at the time, and several people have independently discovered and reported the same vulnerability over the years. Here's another description, which includes an independently written sample PNG-containing-HTML exploit as well: https://forums.hak5.org/topic/6565-xss-exploit-in-ie-by-design-says-microsoft/
In any case, we can put this part on the back burner since keeping the exact reverse-engineered IE security checks doesn't seem to block JPEG files with exif data the same way the more expansive checks did... I'll do a more thorough investigation on removing them later on once I've got local XP & Vista instances to test with. Sounds like there may be more inconsistencies in terms of later changes in service packs that makes it hard to confirm in testing!

Feb 7 2019, 11:07 PM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading

Feb 4 2019

AlexisJazz added a comment to T215128: Video2Commons fails on a particular video: "ERROR: Signature extraction failed".

I upgraded youtube_dl on all hosts. Could you try again?
Anyhow, this task belongs to https://github.com/toolforge/video2commons/issues, not phabricator.

Feb 4 2019, 6:19 AM · Internet-Archive, video2commons

Feb 3 2019

AlexisJazz updated the task description for T215128: Video2Commons fails on a particular video: "ERROR: Signature extraction failed".
Feb 3 2019, 7:19 PM · Internet-Archive, video2commons
AlexisJazz updated the task description for T215128: Video2Commons fails on a particular video: "ERROR: Signature extraction failed".
Feb 3 2019, 7:16 PM · Internet-Archive, video2commons
AlexisJazz created T215128: Video2Commons fails on a particular video: "ERROR: Signature extraction failed".
Feb 3 2019, 7:15 PM · Internet-Archive, video2commons

Feb 1 2019

AlexisJazz added a comment to T27707: Allow "html" in exif tags.

The above patch https://gerrit.wikimedia.org/r/487527 removes some of the non-scripting tags from the checks in UploadBase::detectScript, and makes the conservative/exact IE heuristics called from UploadBase::verifyMimeType optional (but still on by default). This also deprecates $wgAllowTitleInSVG since <title is no longer looked for.
I think this should get JPEGs and such with links in their EXIF metadata working; are there some samples of files that were tripping up before that we can use to add in test cases? A test file I made locally with Gimp works but also already worked with the existing code because the EXIF data is after the area that got searched.

Feb 1 2019, 10:38 PM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading
AlexisJazz added a comment to T27707: Allow "html" in exif tags.

Though this is not needed to remove this MIME sniffing check (or at the very least, make it optional), as I've shown it can't be exploited unless the webserver is misconfigured. So it doesn't apply to Wikimedia projects.

Can you clarify what you mean by "misconfigured"? No special configuration was required with exploit PNGs when I first tested this in 2005. ISTR that JPEG and GIF were not vulnerable when served with their native Content-Types because they have a different priority than PNG in the type checking.
The original 'naughty.png' sample from my 2005 testing is now available at https://brionv.com/misc/naughty.png -- note the way I embedded the HTML using a custom ancillary chunk might no longer be considered legit as some apps reject it now, but it could likely be retooled using a standard comment chunk. Breakdown of it is like this:


IE 8 on Windows 7 doesn't seem to be vulnerable and displays the image without running the script, but I still don't have an IE 6 or 7 test environment handy.

Feb 1 2019, 10:18 PM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading
AlexisJazz updated the task description for T215067: SVG renderer only supports fixed-point values in gradientTransform.
Feb 1 2019, 1:59 PM · Wikimedia-SVG-rendering
AlexisJazz updated the task description for T215067: SVG renderer only supports fixed-point values in gradientTransform.
Feb 1 2019, 1:59 PM · Wikimedia-SVG-rendering
AlexisJazz created T215067: SVG renderer only supports fixed-point values in gradientTransform.
Feb 1 2019, 1:58 PM · Wikimedia-SVG-rendering
AlexisJazz added a comment to T27707: Allow "html" in exif tags.

Logins should definitely be disabled for those.

This feels off-topic for this task. See https://wikitech.wikimedia.org/wiki/HTTPS/Browser_Recommendations#For_Users_of_Microsoft_Windows etc.

Feb 1 2019, 1:53 PM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading

Jan 31 2019

AlexisJazz added a comment to T27707: Allow "html" in exif tags.
In T27707#4918648, @Tgr wrote:
  • This takes IE 6 off the table entirely.

IIRC we still get a bunch of IE6/7 visits from places which man-in-the-middle SSL connections.

Logins should definitely be disabled for those. That man (the one in the middle) can collect all their passwords. And to simplify things, those 4 users per million using IE7 on Vista should also have logins disabled. So logins can be disabled for all IE6 and IE7 users.

Jan 31 2019, 5:50 PM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading

Jan 30 2019

AlexisJazz added a comment to T27707: Allow "html" in exif tags.

The chance that someone would visit using an old IE version was probably 50% when the code was originally added; IE had a very high marketshare in the early 2000s. However at this point we can't even be accessed in IE 6 as far as I know (due to servers dropping old TLS versions for HTTPS). I think it's pretty fair to change the balance of what we check for.

Jan 30 2019, 2:19 PM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading
AlexisJazz added a comment to T27707: Allow "html" in exif tags.
Jan 30 2019, 10:15 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading
AlexisJazz added a comment to T27707: Allow "html" in exif tags.

As the file extension is restricted to a whitelist, the MIME type beyond the control of the attacker and invalid file signatures are also rejected, we must.. find a way around that I guess?

Usually in this scenario, its assumed file ext is .jpg, and the normal unix mime detection stuff would detect it as JPEG. But IE7 would in theory still treat as html (I think).

Actually no, the article Ghouston linked explains:

With the common GIF, JPEG and PNG formats, the browser ignores the result of MIME sniffing, as long as the filename extension, Content-Type and signature, all indicate the same type. Only if the results are inconsistent will Internet Explorer handle the file as the type identified by MIME sniffing.

So we really need to follow the Zany Scheme to exploit this. The scheme is a joke, but not inaccurate.

I think the microsoft docs say something different then Ghouston does:

If the server-provided MIME type is either known or ambiguous, the buffer is scanned in an attempt to verify or obtain a MIME type from the actual content. If a positive match is found (one of the hard-coded tests succeeded), this MIME type is immediately returned as the final determination, overriding the server-provided MIME type (this type of behavior is necessary to identify a .gif file being sent as text/html). During scanning, it is determined if the buffer is predominantly text or binary. Note In Microsoft Internet Explorer 6 for Windows XP Service Pack 2 (SP2), the MIME type "text/plain" is not ambiguous, and is never rendered as HTML in the restricted zone, even if the content suggests that this is the correct format.

From https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms775147(v=vs.85)
Otherwise, this would basically be a non-issue even at the time [Additional cause for concern is I think IE6 can sometimes take extensions from query parameter part of the url]

Jan 30 2019, 9:46 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading
AlexisJazz added a comment to T27707: Allow "html" in exif tags.

As the file extension is restricted to a whitelist, the MIME type beyond the control of the attacker and invalid file signatures are also rejected, we must.. find a way around that I guess?

Usually in this scenario, its assumed file ext is .jpg, and the normal unix mime detection stuff would detect it as JPEG. But IE7 would in theory still treat as html (I think).

Jan 30 2019, 8:10 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading
AlexisJazz added a comment to T27707: Allow "html" in exif tags.

Double-checking:

  • IE 6 and 7 were both available on Windows XP, which includes TLS 1.0 support but not TLS 1.1 or 1.2. However IE 6-8 on XP fail to work anyway due to lack of SNI.
    • This takes IE 6 off the table entirely.
  • IE 7 on Vista should still work correctly with TLS 1.0, 1.1, or 1.2 -- https://blogs.msdn.microsoft.com/kaushal/2011/10/02/support-for-ssltls-protocols-on-windows/
  • IE8 supports X-Content-Type-Options: nosniff header; if we don't already use it consistently, applying this on all file views would resolve all sniffing issues on IE 8

So the intersection of the danger zone, for Wikimedia sites, is:

  • IE 7 running on Windows Vista, user logged in

(This would be a bad experience for the user with no JS and probably no or broken styles, and it's going to be a very small percentage of people that will hit it ever.)
For small internal sites, I assume you're just not going to have IE 6/7 so it shouldn't be a problem. ;)
I think it's reasonably fair to just drop the anti-sniffing checks at this point, though we might want to consider explicitly disallowing logins on IE 7.

Jan 30 2019, 7:52 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading

Jan 28 2019

AlexisJazz closed T214853: GifTagger's public logs timeout as Invalid.
Jan 28 2019, 5:12 PM · Commons
AlexisJazz added a comment to T214853: GifTagger's public logs timeout.

I tested, works as expected. And in browser and via command line. Can you still reproduce this?

zoranzoki21@zoranzoki21-eMachines-E525:~$ curl -I https://commons.wikimedia.org/wiki/Special:Log/GifTagger
HTTP/2 200 
date: Mon, 28 Jan 2019 16:25:15 GMT
content-type: text/html; charset=UTF-8
server: mw1325.eqiad.wmnet
x-content-type-options: nosniff
p3p: CP="This is not a P3P policy! See https://commons.wikimedia.org/wiki/Special:CentralAutoLogin/P3P for more info."
x-powered-by: HHVM/3.18.6-dev
content-language: en
expires: Thu, 01 Jan 1970 00:00:00 GMT
x-frame-options: DENY
backend-timing: D=284163 t=1548692715609284
vary: Accept-Encoding,Cookie,Authorization,X-Seven
content-encoding: gzip
x-varnish: 500400808, 245907591, 227728396
via: 1.1 varnish (Varnish/5.1), 1.1 varnish (Varnish/5.1), 1.1 varnish (Varnish/5.1)
accept-ranges: bytes
age: 0
x-cache: cp1075 pass, cp3032 pass, cp3040 pass
x-cache-status: pass
server-timing: cache;desc="pass"
strict-transport-security: max-age=106384710; includeSubDomains; preload
set-cookie: WMF-Last-Access=28-Jan-2019;Path=/;HttpOnly;secure;Expires=Fri, 01 Mar 2019 12:00:00 GMT
x-analytics: ns=-1;special=Log;https=1;nocookies=1
x-client-ip: 109.245.111.9
cache-control: private, s-maxage=0, max-age=0, must-revalidate
set-cookie: GeoIP=RS:00:Belgrade:44.82:20.47:v4; Path=/; secure; Domain=.wikimedia.org
Jan 28 2019, 5:09 PM · Commons
AlexisJazz added a comment to T27707: Allow "html" in exif tags.

Editing Exif without potentially breaking something is difficult. A lot of extensions have been added to JPEG over the years, and some of them contain pointers to data outside their own segments. Things like maker notes (proprietary and not fully documented) and Multi-Picture Format (which allows putting multiple images in a single JPEG file). They all need to be unpacked, adjusted, and repacked. The only practical method is probably to use ExifTool, and even that isn't perfect.

Jan 28 2019, 4:07 PM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading
AlexisJazz created T214853: GifTagger's public logs timeout.
Jan 28 2019, 3:48 PM · Commons

Jan 25 2019

AlexisJazz added a comment to T213885: Multilingual Captions: Content isn't clear:both'ed on Files with no captions yet, because it's still wrapped in a mw:mediainfoView tags.

@Jdforrester-WMF I don't really know this stuff, but could it be a problem that you are calling getMediaInfoViewRegex before you've defined it?

Sadly, no, that code file is loaded in one go before processing. The subsequent operations to name the slot clearly take place (otherwise it'd say <mw:mediainfoslotheader /> rather than "Structured data".

Jan 25 2019, 9:33 AM · MW-1.33-notes (1.33.0-wmf.14; 2019-01-22), Structured Data Engineering, Multimedia

Jan 24 2019

AlexisJazz added a comment to T213885: Multilingual Captions: Content isn't clear:both'ed on Files with no captions yet, because it's still wrapped in a mw:mediainfoView tags.

@Jdforrester-WMF I don't really know this stuff, but could it be a problem that you are calling getMediaInfoViewRegex before you've defined it?

Jan 24 2019, 11:50 PM · MW-1.33-notes (1.33.0-wmf.14; 2019-01-22), Structured Data Engineering, Multimedia
AlexisJazz created T214607: Summary header vanishes when a file doesn't have any captions entered.
Jan 24 2019, 5:35 PM · Multimedia, Structured Data Engineering, Wikidata
AlexisJazz updated the task description for T214464: Method of generating a list of headings for a page.
Jan 24 2019, 3:27 AM · MediaWiki-Templates

Jan 23 2019

AlexisJazz created T214464: Method of generating a list of headings for a page.
Jan 23 2019, 8:38 AM · MediaWiki-Templates
AlexisJazz added a comment to T214003: Merge the "extended-uploader" and "autopatrolled" user groups on Commons.

@AlexisJazz If you mean at the exact same time, it's extra work and does not seem necessary. If you mean within a few days of each other, that's doable, sure. I was waiting for a reply on my comment.

As zhuyifei1999 says above, only the order matters. If the group change happens before the UW change, people would see the "Share images from Flickr" button but will be stopped by the abuse filter. Those who decide to ignore the abuse filter (just hit "upload" again) would need their uploads to be manually fixed. Which is doable for a few days, probably, as I've dealt with it before for extended uploaders, but messy and no smooth user experience. Merge the UW change first and everything will be fine.

Jan 23 2019, 12:01 AM · Patch-For-Review, User-Zoranzoki21, Wikimedia-Site-requests, Commons

Jan 22 2019

AlexisJazz added a comment to T213571: Ignore babel box the user has set to knowing at level 0 on Commons (and so have different behaviour to Wikidata).

@Multichill where should I propose a change? It should be changed globally, so I guess somewhere on meta?

Jan 22 2019, 1:03 AM · Structured-Data-Backlog, Community-consensus-needed, WikibaseMediaInfo, Wikidata, Structured Data Engineering, MediaWiki-extensions-Babel
AlexisJazz updated subscribers of T214003: Merge the "extended-uploader" and "autopatrolled" user groups on Commons.

It would be ideal if https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/485487/ (Merge the "extended-uploader" and "autopatrolled" user groups on Commons) and https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/UploadWizard/+/485141/ (mw.FlickrChecker: Use {{flickrreview}}) could be merged at the same time. (or merge the UploadWizard patch first, that'll be fine too)

Jan 22 2019, 12:55 AM · Patch-For-Review, User-Zoranzoki21, Wikimedia-Site-requests, Commons

Jan 20 2019

AlexisJazz updated the task description for T213571: Ignore babel box the user has set to knowing at level 0 on Commons (and so have different behaviour to Wikidata).
Jan 20 2019, 8:30 PM · Structured-Data-Backlog, Community-consensus-needed, WikibaseMediaInfo, Wikidata, Structured Data Engineering, MediaWiki-extensions-Babel