With docs now: https://meta.miraheze.org/wiki/Tech:Graylog

I support this request.

Are there any contributions to MediaWiki core or extensions that can serve as evidence they are familiar with the MediaWiki architecture?

Hi @SamanthaNguyen, welcome! Good to see interest for this position.

I was deploying the ALTERs to the wikis while RottenLinks was disabled (the ALTERs cannot be done live using pt-osc, unfortunately), but I forgot to re-enable RottenLinks. For now, I have enabled RottenLinks. The extension only needs to be disabled again (and the update scripts killed) if you are deploying the schema changes on databases.

Let's keep the extension disabled, following Tim's advice at https://phabricator.wikimedia.org/T257066#6364537. However, a note must be in place.

@John it doesn't look like larger VARCHARs are possible. Even if you don't use the rl_id field, it does seem to be working fine at first glance, without fundamentally changing the schema (the current, old fields can stay). What do you think?

@Cyberpower678 sending 45 requests per second is still a lot. Remember this is a multi-tenant environment with few spare resources. However, if you can give me a combination of source IP and User-Agent to exempt for the rate limit temporarily, I can see how much issues are actually caused in production by the bot. I'm curious.

While the change was committed, the change has not been applied to existing tables.

@Cyberpower678 I can confirm on cp9 (cache proxy) traffic from IABot is being rate limited. However, sending over 40 requests per second (on average) to api.php (and thus requests that bypass the cache, and have to be served by the MediaWiki cluster) is in most cases not acceptable at all. We only send about 70 requests per second to the MediaWiki cluster.

@J-Josyu thank you for the HAR file. That was exactly what I needed.

In T5603#122614, @J-Josyu wrote:

Sure, I'm bad, but which one isn't sincere? Of course, the bad thing is the "volunteers" who don't solve the problem.If you call yourself a volunteer, do what you do.

I see multiple volunteers were involved in fixing a part of this issue and trying to reproduce your other issues. Your attitude does not help solving this task. Please read http://meta.miraheze.org/wiki/Code_of_Conduct and stay civil. Thanks.

Permanent fixes have been implemented for this issue, closing the task. If you still have issues, please reopen this task.

• phabricator
• cache proxies (varnish)
• mediawiki nginx
• ldap server
• icinga nginx
• mariadb <- careful!
• mw services
  • parsoid
  • mathoid
  • restbase
• dovecot
• postfix
• matomo nginx
• roundcubemail nginx
• grafana nginx
• gluster
  • gluster clients: mediawiki
• postgresql

Certificate purchased. Deployment going on.

Waiting for response from @Paladox regarding nginx changes.

Seems resolved.

Contacted Owen for a data processing agreement for the free infra offers.

@Universal_Omega seems fine to me. Welcome. Do you have MFA enabled on your Phabricator? If so, we'll add you to acl*security_reviewers.

Rate limiting implemented on cache proxies, monitoring now.

Good to see interest in this job! I would recommend doing an actual security review of a pending extension, using the checklist from https://www.mediawiki.org/wiki/Security_checklist_for_developers. Note the good (e.g. CSRF tokens used, code being compliant with MediaWiki's standards and thus making the review much easier) and bad points (e.g. a lot of htmlspecialchars usage within echo statements, instead of using the Html functions) of the extension's code, security risks you find (e.g. accessing external resources, thus introducing DoS possibilities, passing user input directly into shell commands). Especially for a somewhat larger extension, that gives me an idea about your review capabilities. If I think you are capable of doing security reviews for real, you may be grant permission to approve extensions without being in a SRE position or similar.

https://wiki.kali-team.cn/ works now.

@Exile I can't reproduce this, the wiki works fine with me with that URL. Please let us know if you still experience issues.

tl.awiki.org works now.

@Zppix and this is a security-sensitive task because...?
(and what are the concrete actions here?)

The only relevant CVE here is the SecureBoot one, which doesn't matter at Miraheze (due to our configuration). Making the task public now. I don't see other fixes important for us either, don't see the need for quickly upgrading (which requires reboots of cloud servers as well).

Not observing now, monitoring phase for now.,

In T5788#117129, @AmandaCath wrote:

@Southparkfan Actually, Nimbus is blocked by Upstream per T5450#108244 (was already reviewed by Sam Wilson)

Nimbus approved, Aether not sure about one thing (P340). Discourse is declined since it's not maintained and I have some doubts about certain strategies used for the skin templating.

Approved.

Looks fine to me as well. Approved.

@Paladox, what was the reason this extension was declined as 'hard/impossible to install'?

Give me a few days to think about it.

One potential finding: https://phabricator.miraheze.org/P339

The bundled version of TinyMCE has various vulnerabilities: https://snyk.io/test/npm/tinymce/4.6.4