Page MenuHomePhabricator

AlexisJazz
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Tuesday

  • Clear sailing ahead.

User Details

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

Recent Activity

Mon, Jul 22

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

Disabling crosswiki uploads permanently would be a relief..

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

Sun, Jul 21

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.

Sun, Jul 21, 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?

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

Sat, Jul 20

Multichill awarded T228317: Increase the rate limit for moves on Commons for file movers to 100/minute a Dislike token.
Sat, Jul 20, 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, Patch-For-Review, 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, Patch-For-Review, 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, Patch-For-Review, 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, Patch-For-Review, 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, media-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
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).

@Jdforrester-WMF According to meta, level 0 doesn't understand the language at all. Level 1 can only read. Only level 2 and up are capable or writing in a language. So input fields (which require writing) should only be presented to those who consider themselves level 2 and up.

I appreciate that that random page on Meta that I'd never seen before says that, and made you think that adding dozens of -0 as a talisman to scare off users who speak those languages was a supported way to use the Babel extension, but it isn't and it wasn't.
I would very strongly recommend that you delete the mess of -0 boxes on your user page that mostly highlight your account to people that speak those languages (and disrupt your experience on Meta, with language links on the sides of articles on Wikipedia etc., on Wikidata, and now on Commons).

I would very strongly recommend to make language configuration a preference, which it should have been in the first place.

I agree that it is both surprising and confusing that the Babel extension combines fluff (user boxes) with configuration and does so via user pages. However, that ship sailed eleven years ago in 2008 when it got created, sadly, and changing it now would be very disruptive for users. I'd be in favour of initiating some work to re-evaluate this, probably eventually via a Tech RfC after a wide-ranging investigation into possible uses and improvements, but that's far outwith the scope of the SDC project, and would have to be done in communion with the Language team (as the experts), the Wikidata team (as one of the affected parties), many cross-language editors, and no-doubt other stakeholders.
Also, please don't edit-war over task titles. Making explicit that a task is asking for a deviation in behaviour between similar features is important to set context.

Jan 20 2019, 8:28 PM · Structured-Data-Backlog, Community-consensus-needed, WikibaseMediaInfo, Wikidata, Structured Data Engineering, MediaWiki-extensions-Babel

Jan 18 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 18 2019, 3:29 PM · Structured-Data-Backlog, Community-consensus-needed, WikibaseMediaInfo, Wikidata, Structured Data Engineering, MediaWiki-extensions-Babel
AlexisJazz renamed T213571: Ignore babel box the user has set to knowing at level 0 on Commons (and so have different behaviour to Wikidata) from Ignore babel box the user has set to knowing at level 0 on Commons (and so have different behaviour to Wikidata) to Ignore the babel box for languages the user has set to knowing at level 0.
Jan 18 2019, 3:28 PM · Structured-Data-Backlog, Community-consensus-needed, WikibaseMediaInfo, Wikidata, Structured Data Engineering, MediaWiki-extensions-Babel
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).

@Jdforrester-WMF According to meta, level 0 doesn't understand the language at all. Level 1 can only read. Only level 2 and up are capable or writing in a language. So input fields (which require writing) should only be presented to those who consider themselves level 2 and up.

I appreciate that that random page on Meta that I'd never seen before says that, and made you think that adding dozens of -0 as a talisman to scare off users who speak those languages was a supported way to use the Babel extension, but it isn't and it wasn't.
I would very strongly recommend that you delete the mess of -0 boxes on your user page that mostly highlight your account to people that speak those languages (and disrupt your experience on Meta, with language links on the sides of articles on Wikipedia etc., on Wikidata, and now on Commons).

Jan 18 2019, 3:25 PM · Structured-Data-Backlog, Community-consensus-needed, WikibaseMediaInfo, Wikidata, Structured Data Engineering, MediaWiki-extensions-Babel
AlexisJazz added a comment to T214003: Merge the "extended-uploader" and "autopatrolled" user groups on Commons.

@AlexisJazz Obviously there was some confusion between user groups and user rights which is understandable. I personally don't have a problem with including the patroller user group in this request since, as you said, patroller is an "upgrade" to the autopatrolled group as it is currently defined on Commons. I didn't read your original proposal as meaning "add upload_by_url to every group that has the autopatrol flag" but I guess I could read it that way also. If another RfC is required to grant the flag to the patroller group as well then so be it. But that would be up to the devs who actually make those changes whether or not they want to include the patroller group since it is set up to be an extension of autopatrolled on Commons.

Jan 18 2019, 3:17 PM · Patch-For-Review, User-Zoranzoki21, Wikimedia-Site-requests, Commons

Jan 17 2019

AlexisJazz added a comment to T89131: Server side flickr review.
In T89131#4888586, @Tgr wrote:

I hope whoever wrote "If we accept this, T89131 won't take long." in that proposal really meant T100062, because right now it's unclear if anyone is planning to work on this task.

Jan 17 2019, 7:04 PM · Patch-For-Review, Commons, Multimedia, UploadWizard
AlexisJazz added a comment to T214003: Merge the "extended-uploader" and "autopatrolled" user groups on Commons.

@Zoranzoki21 as you claimed this task, do you agree the proposal included all autopatrolled users, so also patrollers and bots? If not, I'll just request for those 687 users to be granted autopatrol.

Jan 17 2019, 6:40 PM · Patch-For-Review, User-Zoranzoki21, Wikimedia-Site-requests, Commons
AlexisJazz added a comment to T214003: Merge the "extended-uploader" and "autopatrolled" user groups on Commons.

Would this then also automatically give these permissions to "patrollers"?

Autopatrol is included in patrol.

That's actually not how that works @AlexisJazz. You have to separate user groups from user rights/flags. Flags are assigned to groups and then the group is granted to editors. Right now both the autopatrolled and patroller groups have the "autopatrol" flag. The discussion and consensus at the pump was to grant the "upload_by_url" flag to the autopatroller group (which would have made the extended uploader group a duplicate). There was no talk of, and no consensus, to add this flag to the patroller group. So to answer @DonTrung, no. The flag will not be granted to patrollers.

Jan 17 2019, 5:30 PM · Patch-For-Review, User-Zoranzoki21, Wikimedia-Site-requests, Commons
AlexisJazz added a comment to T89131: Server side flickr review.

@Aklapper I suspect this change would not be desired outside of Wikimedia projects, perhaps even outside of Wikimedia Commons. I don't know if/how this can be applied only to Commons. Maybe changing the FlickreviewR bot is better, but I'll let zhuyifei1999 comment on that.

Jan 17 2019, 2:46 PM · Patch-For-Review, Commons, Multimedia, UploadWizard
AlexisJazz added a comment to T214003: Merge the "extended-uploader" and "autopatrolled" user groups on Commons.

Would this then also automatically give these permissions to "patrollers"?

Jan 17 2019, 2:36 PM · Patch-For-Review, User-Zoranzoki21, Wikimedia-Site-requests, Commons
AlexisJazz added a comment to T89131: Server side flickr review.

@zhuyifei1999 just in case anyone is going to make a problem out of the above, can you alter FlickreviewR to start chomping on {{FlickrVerifiedByUploadWizard.*}} tags?

Jan 17 2019, 2:28 PM · Patch-For-Review, Commons, Multimedia, UploadWizard
AlexisJazz added a comment to T89131: Server side flickr review.

Here are the changes needed (really, do you need me for this?):

Jan 17 2019, 2:24 PM · Patch-For-Review, Commons, Multimedia, UploadWizard
AlexisJazz added a comment to T90004: Enable Flickr import for all users on Commons.

Also see T214003.

Jan 17 2019, 2:12 PM · Commons, Wikimedia-Hackathon-2015, Multimedia
AlexisJazz added a comment to T214003: Merge the "extended-uploader" and "autopatrolled" user groups on Commons.

Also see T89131, please replace or supplement {{FlickrVerifiedByUploadWizard.*}} with {{flickrreview}}.

Jan 17 2019, 2:04 PM · Patch-For-Review, User-Zoranzoki21, Wikimedia-Site-requests, Commons
AlexisJazz awarded T214003: Merge the "extended-uploader" and "autopatrolled" user groups on Commons a Doubloon token.
Jan 17 2019, 2:02 PM · Patch-For-Review, User-Zoranzoki21, Wikimedia-Site-requests, Commons
AlexisJazz lowered the priority of T89131: Server side flickr review from High to Low.

@Aklapper I'm not aware of your conventions.

Jan 17 2019, 1:58 PM · Patch-For-Review, Commons, Multimedia, UploadWizard
AlexisJazz raised the priority of T89131: Server side flickr review from Low to High.

Since it is causing issues (e. g. here) we should probably replace "{{FlickrVerifiedByUploadWizard.*}}" with "{{flickrreview}}" in the code. OR we simply add {{flickrreview}} for a additionally check (then we can remove the FlickrVerifiedByUploadWizard from AbuseFilter). I actually have no idea for a onwiki-only solution here. But both changes are trivial.

https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals#Give_autopatrolled_users_more_upload_options was passed.

Jan 17 2019, 1:48 PM · Patch-For-Review, Commons, Multimedia, UploadWizard

Jan 12 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 You didn't answer my question. If you add en-0 to your babel it reads "This user has no knowledge of English (or understands it with considerable difficulty)". Several languages even bold the "no knowledge" part. The user has no knowledge. Why should those users be presented with input fields for languages they don't know?

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

@Multichill : I'm puzzled.

Jan 12 2019, 11:57 AM · Structured-Data-Backlog, Community-consensus-needed, WikibaseMediaInfo, Wikidata, Structured Data Engineering, MediaWiki-extensions-Babel

Jan 11 2019

Multichill awarded T213571: Ignore babel box the user has set to knowing at level 0 on Commons (and so have different behaviour to Wikidata) a Dislike token.
Jan 11 2019, 11:51 PM · Structured-Data-Backlog, Community-consensus-needed, WikibaseMediaInfo, Wikidata, Structured Data Engineering, MediaWiki-extensions-Babel
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).

It was not forgotten. It is an intentional feature on Wikidata.

Jan 11 2019, 9:19 PM · Structured-Data-Backlog, Community-consensus-needed, WikibaseMediaInfo, Wikidata, Structured Data Engineering, MediaWiki-extensions-Babel
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).

It should stay like it is for standard Wikibase at least. People use it.

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

Jan 10 2019

AlexisJazz updated the task description for T213484: Normalize file extensions (capital vs small letters; jpg vs jpeg) for new uploads on Commons.
Jan 10 2019, 9:00 PM · Multimedia, MediaWiki-Uploading, Commons
AlexisJazz created T213484: Normalize file extensions (capital vs small letters; jpg vs jpeg) for new uploads on Commons.
Jan 10 2019, 8:58 PM · Multimedia, MediaWiki-Uploading, Commons

Dec 31 2018

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

According to @matmarex this is an issue in IE5-7. MS dropped support for IE7 entirely in April 2016. IE8 was released in 2009. According to https://en.wikipedia.org/wiki/Internet_Explorer_7, as of May 2012, estimates of IE7's global market share were 1.5-5%. According to netmarketshare.com the market share is now 0.16%.

Dec 31 2018, 3:18 PM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading
AlexisJazz added a comment to T212711: Link notification for a link of a file to itself.

@Ammarpad I still don't see it? The F template is used to link https://commons.wikimedia.org/wiki/File:Full-protection-shackle.svg, not https://commons.wikimedia.org/wiki/File:Full-protection-shackle-double.svg?

Dec 31 2018, 12:28 PM · Commons

Dec 30 2018

AlexisJazz created T212711: Link notification for a link of a file to itself.
Dec 30 2018, 10:19 PM · Commons
AlexisJazz added a comment to T212693: Remove or escape HTML code in the EXIF when uploading files (Currently uploading is not possible).

@Aklapper @Shreyasminocha can't you just remove line 1332 ("'<a href',") from UploadBase.php? Is that Internet Explorer bug still a thing? Otherwise can you check if it's part of the EXIF and ignore it if that's the case?

Dec 30 2018, 3:39 PM · MediaWiki-Uploading, Multimedia, Commons
AlexisJazz updated the task description for T212693: Remove or escape HTML code in the EXIF when uploading files (Currently uploading is not possible).
Dec 30 2018, 12:34 PM · MediaWiki-Uploading, Multimedia, Commons
AlexisJazz added a comment to T212693: Remove or escape HTML code in the EXIF when uploading files (Currently uploading is not possible).

@AlexisJazz: Please include clear steps to reproduce. Which of the many available ways to upload files did you use exactly?
Edit: Ah, I assume the "MediaWiki/UploadWizard" in the last line implies that.

Dec 30 2018, 12:21 PM · MediaWiki-Uploading, Multimedia, Commons