So this is a bit of a grey area of if this change is within the realm of things that a community can request. The foundation may feel it wants a consistent feel to all the projects that it hosts.

FYI, these tests should already be run via CI (as part of composer tests)

yeah, its tied pretty heavily to phan 0.8, which in turn is tied to php 7. There's an upcoming goal to move it the plugin to a modern version of phan.

Reading https://meta.wikimedia.org/w/api.php?action=help&modules=shortenurl - doesn't seem to require a CSRF token, so I'm not sure that CORS is needed here? (more specifically, you can use the generic origin=* I think).

I'm not sure how to say this without coming off as a dick, so I'm just going to go ahead: Jeroen De Dauw already has 2 failed requests for +2 in mediawiki/core 1 2. Admittedly this was a long time ago, but the last time he did anything non-trivial in MW core was in 2013. I feel like this is sort of a backdoor around previous community consensus.

I think this should be explicitly announced on wikitech-l, and not just buried in a techcom update

Overall: Looks good - Extension passes security review. There are a couple very small things though I would like to see changed.

This sounds like a bad idea. Administrators probably shouldn't normally be able to do that, without someone literally going into MySQL etc.

Ok, I tried to make a more restrictive group called VandalFighters, which i added WMFOffice to (And removed WMFOffice from Administrators). It has the ability to abandon patches, delete patches (Note there is no undo, so be careful with the delete button), mark patches -2, flush caches, and adjust accounts (in particular mark an account "inactive" which is like block).

Done. User is now in Administrator group

In T217361#5007405, @revi wrote:

Following users have been resigned or did not pass annual confirmation: @MBisanz, @Mentifisto, and @MF-Warburg. I've removed them from acl*stewards but if they are in Security, please process them.

Sorry, but we're not going to review this unless there is definite interest in using production.

In T28508#5001266, @Rillke wrote:

API returns warnings about Unrecognized parameters at Wikimedia Commons.

{"warnings":{"main":{"*":"Unrecognized parameters: {\"csp-report\":{\"blocked-uri\":\"https://tools_wmflabs_org/convert/svg2png_php\",\"document-uri\":\"https://commons_wikimedia_org/w/index_php?title, withJS."}},"cspreport":"success"}

The warning message indicates the title and withJS parameters are unknown?

In T217423#4995007, @TheROFL98 wrote:

It appears it's now giving me a new error.

[574140f4f18921f47a1b9566] /w/index.php?title=User:Therofl98 InvalidArgumentException from line 336 of /var/www/html/wiki/w/includes/CommentStore.php: $row does not contain fields needed for comment rc_comment

Backtrace:

#0 /var/www/html/wiki/w/includes/CommentStore.php(413): CommentStore->getCommentInternal(NULL, string, array, boolean)
#1 /var/www/html/wiki/w/extensions/SocialProfile/UserActivity/includes/UserActivity.php(140): CommentStore->getComment(string, stdClass)
#2 /var/www/html/wiki/w/extensions/SocialProfile/UserActivity/includes/UserActivity.php(1011): UserActivity->setEdits()
#3 /var/www/html/wiki/w/extensions/SocialProfile/UserProfile/includes/UserProfilePage.php(1330): UserActivity->getActivityList()
#4 /var/www/html/wiki/w/extensions/SocialProfile/UserProfile/includes/UserProfilePage.php(151): UserProfilePage->getActivity()
#5 /var/www/html/wiki/w/includes/actions/ViewAction.php(68): UserProfilePage->view()
#6 /var/www/html/wiki/w/includes/MediaWiki.php(501): ViewAction->show()
#7 /var/www/html/wiki/w/includes/MediaWiki.php(294): MediaWiki->performAction(UserProfilePage, Title)
#8 /var/www/html/wiki/w/includes/MediaWiki.php(867): MediaWiki->performRequest()
#9 /var/www/html/wiki/w/includes/MediaWiki.php(517): MediaWiki->main()
#10 /var/www/html/wiki/w/index.php(42): MediaWiki->run()
#11 {main}

I've already run the update.php file to update the database.

I'm going to call this declined for now, but feel free to reopen if/when there is more consensus on doing this.

In T215046#4974744, @Aklapper wrote:

In T215046#4972989, @chasemp wrote:

I have not encountered anyone who has told me that our account creation process or requiring an account is preventing them from participating.

(In FY2017-2018 @srishakatux sent out four survey to all new developers in a quarter who put a changeset into Wikimedia Gerrit. https://www.mediawiki.org/wiki/New_Developers/Quarterly#Summary_of_key_findings states that "New developers continue to struggle with the code contribution process" but I do not know if we had explicit "Why did I have to set up a separate account in times of OAuth" replies; maybe Srishti knows.)

In T216790#4974514, @Reke wrote:

Creating account on another wiki is also limited. :-(

The examples at https://en.wikipedia.org/wiki/Uname suggest i686 is somewhat common

Note: I didn't encounter this myself. Report was from irc. There was also a second report at https://www.mediawiki.org/wiki/Topic:Sqeu40egi1wa49a9 . Given there were two separate reports, I assumed it wasn't the one guy doing something weird (That would be my initial assumption for such an odd error message) but the general error condition that happens when running on wrong architecture.

I should emphasize of course, that quarry has a very low risk profile, so its really not worth worrying too much (As much as I love better security for security's sake). Worse case scenario (that i can think of) is someone uses an XSS in quarry as part of a phising scheme, or someone tries to make queries with naughy content under someone else's name. Neither are particularly high impact threats.

P.S. @Bawolff I might be wrong, but I think at the time of first Graphoid version, pageprops were always in sync with the canonical view, until a bit later when some things moved to jobque.

Argon2 is a new-generation key derivation algorithm that was designed to resist side-channel (i variants) and GPU brute force (d variants), unlike our current PBKDF2. Now that we have Argon2 support in core, we should talk about protecting our users with it.

The graphoid service fetches the graph from the mediawiki API using essentially mediawiki pages as a data store. However to identify the required graph it requires knowing the identity of the graph which is essentially the hash of the graph.

In T203158#4968945, @Bawolff wrote:

So at first glance, it looks like (IcuCollation.php line 397):

// Primary collision (two characters with the same sort position).
// Keep whichever one sorts first in the main collator.
$comp = $this->mainCollator->compare( $letter, $letterMap[$key] );

Has the comparison reversed, since lowercase comes before uppercase.

So at first glance, it looks like (IcuCollation.php line 397):

Just to make sure I understand correctly (Since I don't speak Turkish).

Is the end goal to deploy in wikimedia production eventually?

Hi David,

Deployment-prep, also known as the beta cluster, is a Cloud VPS project originally created by technical volunteers {{cn}}

So summarizing a discussion I had with @Isarra on irc [I am not a skin expert. I may have misunderstood some of the finer points here. If I make mistakes or say something stupid here, that's my bad]:

Arguably, the read only error message for this situation could probably be improved.

After doing some poking, looks like the master db (deployment-db03) might be down.

For e1160113 & ae2938b765 - They were backported but didn't trigger a security release, because they were considered a hardening patch, and not a vulnerability fix. The thing they fix is not a security vulnerability per-se but only preventing the user from doing a behaviour that's a bad idea.

Thanks.

The reason the change started failing is the patch got rebased without taking in account that mediawiki/mediawiki-codesniffer has meanwhile been upgraded in the branch.

I kind of feel like it would be nice to include the log message from the account lock in this message, but that's kind of complex to do.

In T212911#4960533, @daniel wrote:

@Aklapper As far as I understand, the ultimate authority on who should have access to which of our repos is the CTO. Relevant angles on the issue can probably be provided by community engagement, legal, and HR. No idea what the best venue for discussion is, sorry...

Note, this bug partially overlaps with a secret bug T184012

Be aware, this extension is probably going to be removed from Wikimedia production soon (T187716) and then presumably archived as nobody else uses it or would reasonably want to use it.

rm tag phan-taint-check tag - That tag is only for the XSS detector part of phan

It currently has a hard dependency on php7.0

Personally, I think all tasks not explicitly marked private, should be "maybe-public", and it is primarily the responsibility of the bug closer to make security bugs public (yeah I know, lots of bugs get missed)

Standard threat analysis involves an estimation of likelihood, value to the attacker, and potential damage. A major company abusing their identity API to gain access under a false identity to a Wikimedia account would be massively unethical, a PR catastrophe for them, and almost certainly illegal in the US under the CFAA. It would be of no value whatsoever to the external provider or for an employee there abusing their authority. The damage for us would be minimal, some annoying vandalism maybe. I continue to see this as a complete non-issue.

A few of us (Reedy, Btongminh, myself, and others..) actually use this to have old SVN commits associated with our GitHub profiles. (I wonder what GitHub does if multiple accounts do this, maybe oldest wins?)

This is offtopic. Please file a separate bug.

I deleted the key.

In T215115#4926869, @hashar wrote:

We had CSP issues on T155794 (declined). Jenkins LTS 1.625.3 introduced the CSP, the documentation being at https://wiki.jenkins.io/display/JENKINS/Configuring+Content+Security+Policy . According to that documentation the default rule is:

sandbox; default-src 'none'; img-src 'self'; style-src 'self';

This rule set results in the following:

No JavaScript allowed at all
No plugins (object/embed) allowed
No inline CSS, or CSS from other sites allowed
No images from other sites allowed
No frames allowed
No web fonts allowed
No XHR/AJAX allowed
etc.

If we want to adjust it, we need to pass a system property when starting Jenkins (that is done via puppet configuration):

java -Dhudson.model.DirectoryBrowserSupport.CSP= -jar jenkins.war

But I cant tell about the security implications if we change the rules.

Which url is this? AFAIK we haven't enabled CSP on doc.wikimedia.org yet (T213223).

Perhaps the real solution should be to rename all these users so that they actually start with an uppercase letter like they should.

So are all these from wiktionary back when lowercase first letter usernames were allowed? If not, where are these coming from (Just curious)

So i figured out the cause.

In T27707#4918032, @AlexisJazz wrote:

In T27707#4918013, @Bawolff wrote:

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.

Imported as https://commons.wikimedia.org/wiki/File:116th_United_States_Congress_House_Floor-2019-01-03.webm

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?

The other thing to consider is IE7 on vista is old. AFAICT its been out of support at least since 2016. There are probably other security vulnerabilities its subject to (Some googling is suggestive that CVE-2018-8653 might be an example, but its really unclear)