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 (51 w, 3 d)
Availability
Available
LDAP User
Unknown
MediaWiki User
Alexis Jazz [ Global Accounts ]

Recent Activity

Tue, Feb 12

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.
Tue, Feb 12, 9:21 PM · Community-consensus-needed, WikibaseMediaInfo, Wikidata, SDC Engineering, MediaWiki-extensions-Babel

Thu, Feb 7

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!

Thu, Feb 7, 11:07 PM · Patch-For-Review, Security, Multimedia, MediaWiki-Uploading

Mon, Feb 4

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.

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

Sun, Feb 3

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

Fri, Feb 1

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.

Fri, Feb 1, 10:38 PM · Patch-For-Review, 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.

Fri, Feb 1, 10:18 PM · Patch-For-Review, Security, Multimedia, MediaWiki-Uploading
AlexisJazz updated the task description for T215067: SVG renderer only supports fixed-point values in gradientTransform.
Fri, Feb 1, 1:59 PM · Wikimedia-SVG-rendering
AlexisJazz updated the task description for T215067: SVG renderer only supports fixed-point values in gradientTransform.
Fri, Feb 1, 1:59 PM · Wikimedia-SVG-rendering
AlexisJazz created T215067: SVG renderer only supports fixed-point values in gradientTransform.
Fri, Feb 1, 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.

Fri, Feb 1, 1:53 PM · Patch-For-Review, Security, Multimedia, MediaWiki-Uploading

Thu, Jan 31

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.

Thu, Jan 31, 5:50 PM · Patch-For-Review, Security, Multimedia, MediaWiki-Uploading

Wed, Jan 30

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.

Wed, Jan 30, 2:19 PM · Patch-For-Review, Security, Multimedia, MediaWiki-Uploading
AlexisJazz added a comment to T27707: Allow "html" in exif tags.
Wed, Jan 30, 10:15 AM · Patch-For-Review, 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]

Wed, Jan 30, 9:46 AM · Patch-For-Review, 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).

Wed, Jan 30, 8:10 AM · Patch-For-Review, 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.
Wed, Jan 30, 7:52 AM · Patch-For-Review, Security, Multimedia, MediaWiki-Uploading

Mon, Jan 28

AlexisJazz closed T214853: GifTagger's public logs timeout as Invalid.
Mon, Jan 28, 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
Mon, Jan 28, 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.

Mon, Jan 28, 4:07 PM · Patch-For-Review, Security, Multimedia, MediaWiki-Uploading
AlexisJazz created T214853: GifTagger's public logs timeout.
Mon, Jan 28, 3:48 PM · Commons

Fri, Jan 25

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".

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

Thu, Jan 24

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?

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

Wed, Jan 23

AlexisJazz created T214464: Method of generating a list of headings for a page.
Wed, Jan 23, 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.

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

Tue, Jan 22

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?

Tue, Jan 22, 1:03 AM · Community-consensus-needed, WikibaseMediaInfo, Wikidata, SDC 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.

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

Sun, Jan 20

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).
Sun, Jan 20, 8:30 PM · Community-consensus-needed, WikibaseMediaInfo, Wikidata, SDC 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.

Sun, Jan 20, 8:28 PM · Community-consensus-needed, WikibaseMediaInfo, Wikidata, SDC 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 · Community-consensus-needed, WikibaseMediaInfo, Wikidata, SDC 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 · Community-consensus-needed, WikibaseMediaInfo, Wikidata, SDC 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 · Community-consensus-needed, WikibaseMediaInfo, Wikidata, SDC 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, UploadWizard, Multimedia
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, UploadWizard, Multimedia
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, UploadWizard, Multimedia
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, UploadWizard, Multimedia
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, UploadWizard, Multimedia
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, UploadWizard, Multimedia

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 · Community-consensus-needed, WikibaseMediaInfo, Wikidata, SDC 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 · Community-consensus-needed, WikibaseMediaInfo, Wikidata, SDC 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 · Community-consensus-needed, WikibaseMediaInfo, Wikidata, SDC 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 · Community-consensus-needed, WikibaseMediaInfo, Wikidata, SDC 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 · Community-consensus-needed, WikibaseMediaInfo, Wikidata, SDC 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 · Community-consensus-needed, WikibaseMediaInfo, Wikidata, SDC 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 · MediaWiki-Uploading, Multimedia, 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 · MediaWiki-Uploading, Multimedia, 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 · Patch-For-Review, 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

Dec 29 2018

AlexisJazz updated the task description for T212693: Remove or escape HTML code in the EXIF when uploading files (Currently uploading is not possible).
Dec 29 2018, 10:22 PM · MediaWiki-Uploading, Multimedia, Commons
AlexisJazz created T212693: Remove or escape HTML code in the EXIF when uploading files (Currently uploading is not possible).
Dec 29 2018, 10:21 PM · MediaWiki-Uploading, Multimedia, Commons

Dec 12 2018

AlexisJazz added a comment to T211745: Automatically convert .heic image format files to .jpg or .webp.

@Aklapper okay, sorry, I didn't know how to tag this as a feature request. Can the mobile app convert it? (I guess that would only help for Android, which is maybe more likely to use .webp anyway..) Can it be converted with JavaScript? Could a project an Wikimedia Toolforge handle it?

Dec 12 2018, 5:26 PM · Multimedia, MediaWiki-Uploading, Commons
AlexisJazz created T211745: Automatically convert .heic image format files to .jpg or .webp.
Dec 12 2018, 5:11 AM · Multimedia, MediaWiki-Uploading, Commons

Dec 11 2018

AlexisJazz added a comment to T100062: Do not put "verified" template on UploadWizard Flicker uploads if user isn't trusted.

"It should still be fine to add FlickrVerifiedByUploadWizard if the account is trusted, however (for example administrators)."

Dec 11 2018, 2:45 AM · MW-1.33-notes (1.33.0-wmf.16; 2019-02-05), Technical-Debt, Notice, Patch-For-Review, UploadWizard, Multimedia, Commons

Dec 7 2018

AlexisJazz updated subscribers of T89131: Server side flickr review.

@Slowking4 is not actually in the extended uploaders group. I suspect he has the "Share images from Flickr" button because he is in the "GWToolset users" group.

Dec 7 2018, 12:23 AM · Patch-For-Review, Commons, UploadWizard, Multimedia

Dec 6 2018

AlexisJazz merged T210339: UploadWizard spits "no permission" error when using sharing images from Flickr into T100062: Do not put "verified" template on UploadWizard Flicker uploads if user isn't trusted.
Dec 6 2018, 3:43 AM · MW-1.33-notes (1.33.0-wmf.16; 2019-02-05), Technical-Debt, Notice, Patch-For-Review, UploadWizard, Multimedia, Commons
AlexisJazz merged task T210339: UploadWizard spits "no permission" error when using sharing images from Flickr into T100062: Do not put "verified" template on UploadWizard Flicker uploads if user isn't trusted.
Dec 6 2018, 3:43 AM · Multimedia, UploadWizard
AlexisJazz updated the task description for T100062: Do not put "verified" template on UploadWizard Flicker uploads if user isn't trusted.
Dec 6 2018, 3:40 AM · MW-1.33-notes (1.33.0-wmf.16; 2019-02-05), Technical-Debt, Notice, Patch-For-Review, UploadWizard, Multimedia, Commons
AlexisJazz added a comment to T100062: Do not put "verified" template on UploadWizard Flicker uploads if user isn't trusted.

@kaldari no problem, here it is, with free patch!! T210339

Dec 6 2018, 3:37 AM · MW-1.33-notes (1.33.0-wmf.16; 2019-02-05), Technical-Debt, Notice, Patch-For-Review, UploadWizard, Multimedia, Commons

Dec 1 2018

AlexisJazz added a comment to T210859: 404 Error for redirected image: Cache for pages using an image is not purged after rename.

@AlexisJazz: I'm looking at https://nl.wikipedia.org/w/index.php?title=Overleg:Theo_van_Gogh_(kunsthandelaar)&oldid=52708637 but which exact "image on the talk page" do you refer to? Not sure how to see the problem... :-(

Dec 1 2018, 5:11 PM · MediaWiki-File-management, Multimedia, MediaWiki-Cache, Commons

Nov 30 2018

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

But the things that take me hours could be done in seconds with shell access.

How do you think that would happen? If you have specific steps in mind, maybe we could expose those to power users. I can't think of any investigation that would be much more complicated without shell access though.

Nov 30 2018, 6:24 PM · User-Josve05a, Operations, Multimedia, media-storage, Commons
AlexisJazz added a comment to T124101: Specific revisions of multiple files missing from Swift - 404 Not Found returned.

@Incnis_Mrsi at T198177 I also found some missing revisions. But the things that take me hours could be done in seconds with shell access.

Nov 30 2018, 5:29 PM · User-Josve05a, Operations, Multimedia, media-storage, Commons
AlexisJazz added a comment to T198177: Due to PHP fatal, a new version upload overwrote a file (the original is gone).

I'm de-prioritising this as it's unrecoverable and the general comments are valid but not new.

Nov 30 2018, 5:26 PM · Multimedia, Wikimedia-production-error, media-storage, Commons
AlexisJazz created T210859: 404 Error for redirected image: Cache for pages using an image is not purged after rename.
Nov 30 2018, 4:42 PM · MediaWiki-File-management, Multimedia, MediaWiki-Cache, Commons

Nov 25 2018

AlexisJazz created T210339: UploadWizard spits "no permission" error when using sharing images from Flickr.
Nov 25 2018, 2:32 AM · Multimedia, UploadWizard

Nov 22 2018

AlexisJazz created T210201: UploadWizard doesn't warn properly when overwriting an image.
Nov 22 2018, 7:56 PM · Multimedia, UploadWizard

Nov 20 2018

AlexisJazz added a comment to T209557: VP9 in Video2Commons fails (due to Opus encoding broken).

@zhuyifei1999 "Thanks. How much bitrate do you think we should use? I'm thinking of 128k"

Nov 20 2018, 1:41 AM · video2commons

Nov 16 2018

AlexisJazz created T209673: Transcodes are not reset for undeleted video file.
Nov 16 2018, 6:29 AM · TimedMediaHandler-Transcode, TimedMediaHandler

Nov 15 2018

AlexisJazz added a comment to T209557: VP9 in Video2Commons fails (due to Opus encoding broken).

@zhuyifei1999 "The problem: opus encoder doesn't seem to allow constant quality,"

Nov 15 2018, 11:02 PM · video2commons
AlexisJazz merged T209154: Video2Commons can't convert these two mp4 videos into T209557: VP9 in Video2Commons fails (due to Opus encoding broken).
Nov 15 2018, 5:27 AM · video2commons
AlexisJazz merged task T209154: Video2Commons can't convert these two mp4 videos into T209557: VP9 in Video2Commons fails (due to Opus encoding broken).
Nov 15 2018, 5:27 AM · video2commons
AlexisJazz created T209560: Mp4 video recorded in portrait (vertical) mode gets rotated and squeezed by mediawiki.
Nov 15 2018, 5:22 AM · Wikimedia-Video
AlexisJazz added a comment to T202208: Mp4 on Commons - since when did we allow it.

@TheDJ I plan to convert some more after T209557 is fixed..

Nov 15 2018, 4:35 AM · MW-1.32-notes (WMF-deploy-2018-08-07 (1.32.0-wmf.16)), Commons, TimedMediaHandler, Wikimedia-Video
AlexisJazz created T209557: VP9 in Video2Commons fails (due to Opus encoding broken).
Nov 15 2018, 3:34 AM · video2commons

Nov 9 2018

AlexisJazz created T209154: Video2Commons can't convert these two mp4 videos.
Nov 9 2018, 2:37 PM · video2commons
AlexisJazz added a comment to T208845: File incorrectly reported as in use on a Commons category page.

Just purged again (5 days after my Wikidata edit), still "in use".

Nov 9 2018, 8:32 AM · MediaWiki-Categories, Commons

Nov 6 2018

AlexisJazz updated the task description for T208845: File incorrectly reported as in use on a Commons category page.
Nov 6 2018, 7:55 PM · MediaWiki-Categories, Commons
AlexisJazz created T208845: File incorrectly reported as in use on a Commons category page.
Nov 6 2018, 12:11 PM · MediaWiki-Categories, Commons

Nov 1 2018

AlexisJazz added a comment to T101716: Support MJPEG & PCM audio as last-ditch fallback output for iOS.

@brion https://meta.wikimedia.org/wiki/Have_the_patents_for_MPEG-4_Visual_expired_yet%3F

Nov 1 2018, 3:58 AM · Patch-For-Review, Multimedia, TimedMediaHandler

Oct 29 2018

AlexisJazz added a comment to T46787: Allow excluding pages from the page links notifications.

I don't know, you tell me?

Oct 29 2018, 12:08 PM · Need-volunteer, Growth-Team, Notifications

Oct 27 2018

AlexisJazz added a comment to T46787: Allow excluding pages from the page links notifications.

I think I'm gonna have a serious problem with this.

Oct 27 2018, 5:18 PM · Need-volunteer, Growth-Team, Notifications

Oct 26 2018

AlexisJazz merged T207883: Feature request: using a different image for thumbnail and full image into T9757: allow cropping images when rendered.
Oct 26 2018, 4:13 AM · Commons, Epic, Multimedia, MediaWiki-File-management
AlexisJazz merged task T207883: Feature request: using a different image for thumbnail and full image into T9757: allow cropping images when rendered.
Oct 26 2018, 4:13 AM · Multimedia, MediaWiki-extensions-MultimediaViewer, MediaWiki-Gallery
AlexisJazz added a comment to T9757: allow cropping images when rendered.

I had opened T207883, unaware of this request.

Oct 26 2018, 4:08 AM · Commons, Epic, Multimedia, MediaWiki-File-management

Oct 24 2018

AlexisJazz updated the task description for T207883: Feature request: using a different image for thumbnail and full image.
Oct 24 2018, 7:34 PM · Multimedia, MediaWiki-extensions-MultimediaViewer, MediaWiki-Gallery
AlexisJazz updated the task description for T207883: Feature request: using a different image for thumbnail and full image.
Oct 24 2018, 7:34 PM · Multimedia, MediaWiki-extensions-MultimediaViewer, MediaWiki-Gallery
AlexisJazz created T207883: Feature request: using a different image for thumbnail and full image.
Oct 24 2018, 7:28 PM · Multimedia, MediaWiki-extensions-MultimediaViewer, MediaWiki-Gallery