In T101631#5171643, @Bstorm wrote:

If I can get a thumbs up from @Bawolff, perhaps?

The current logic expressly filters rev_len on deleted revisions: if(rev_deleted&1,null,rev_len) as rev_len. I don't know if that's just for consistency or if someone thinks that really should be kept out of the replicas. As stated above, it does seem to be available online, though I'm not sure if that's all versions of the deleted field, since that's an integer, I think.

So I guess this isn't quite ready for a security review given previous comment, but some thoughts

This is old enough now to no longer be relevant.

Ah, that's confusing. Thanks.

The threat model here is kind of debatable. Its unclear what security goals we are trying to accomplish with the displaytitle restrictions, and thus I'm unsure (unsure in the sense of actually do not know, not unsure in the sense of disagreeing) if further restrictions on it are justified.

wikititle:/// is supposed to prevent query paramters from being used, however it could probably be bypassed if they are percent encoded due to T96274 (e.g. https://en.wikipedia.org/wiki/Main_Page%3faction=history%26curid=2120 is interpreted by our servers incorrectly )

In T207246#5160385, @sbassett wrote:

Re: privacy, the sites reference the standard Wikimedia PP. And while most resources seem to come from internal Wikimedia sites, some definitely do not (e.g. images within the Shocking tales from ornithology post on en.planet.wikimedia.org and a few others.)

I think the main things we want to check:

In T222324#5151761, @Jdforrester-WMF wrote:

Yup, triggered on GET to https://commons.wikimedia.org/w/index.php?title=User%3AJdforrester_%28WMF%29%2Fsandbox&action=revisiondelete&type=revision&ids%5B348296966%5D=1:

[ [[https://logstash.wikimedia.org/app/kibana#/doc/logstash-*/logstash-2019.05.02/mediawiki?id=AWp2UJLb3aPtkd7P1oBE&_g=()|XMpRwApAMFQAAE8PXE0AAAAQ]] ] 2019-05-02 02:12:33: Fatal exception of type "WMFTimeoutException"

This is on a trivial page (two revisions, one editor); possibly this is caused by actor changes?

Note security did some minor adjustments to the revdel process on tuesday but nothing that should cause this.

My understanding is that the content translation tool is optimized for the use case where the two translations are independent (e.g. between wikis), where E:Translate is optimized for the use case of translating documents where one of the languages are controlling (e.g. Like software translation). Admittedly I don't follow translation stuff very closely, so I may just be mistaken, but assuming that assumption is correct, may I ask what the rationale is for integrating into ContentTranslation over E:Translate is?

For what you are literally asking for: https://tools.wmflabs.org/guc/

so I think we've done everything on our end. See my comment above for my comments on the library - please address those things before using vega 3. Let me know if you have any questions.

In T219728#5126845, @Rxy wrote:

The patch should be deployed to Japanese language sites until May 1 JST..

https://www.ssllabs.com/ssltest/analyze.html?d=gerrit.wikimedia.org&s=2620%3a0%3a861%3a3%3a208%3a80%3a154%3a85&latest suggests ssl3 is already disabled

Hmm, L and K having a hamming distance of 3 - Could this possibly be a memory error that wasn't detectable by ECC as a 3 bit error?

There is no formal definition, but in practice, it means anything that is maintained by WMF staff

In T172938#3894863, @Yurik wrote:

@Bawolff are there any CSP issues with srcdoc? In my example, parent can have a different CSP rules than iframe. This way you can enable unsafe-eval in the frame, without allowing it in the parent.

Screenshot. Note that not a single row of the history page shows up. (Note: My font size may be mildly above normal. Some of us like big letters to help our eyes. Notwithstanding that, I would consider this an unreasonable amount of screen real-estate being taken up).

Just fyi, I would describe half as an underexageration. Screenshot incoming

Note, @RhinosF1 is also complaining about this issue in #mediawiki irc about the site https://thelostjewel.com/index.php?title=Special:Log&dir=prev&type=newusers&user=&page=&wpdate=&tagfilter=

In T220023#5084559, @ASammour wrote:

@Bawolff I will explain how hijri date is calculated.

In hijri date, there are 12 months. Each month has days between 29-30 days. And we can't know whether the number of days are 29, or 30 except if we look to the moon move. So in middle east countries they look to the moon in 28th night to see what is the status of the moon. If it's new moon, then this means that a new month will start.

For example, today is 28 Regeb 1440 (hijri date), and today night each middle eastern country will look at the moon at night (Most countries followed Saudi Arabia decision), and determine if tomorrow will be start of new month, or not. If it's the start of new month then this means that the current hijri month number of days will be 29, else it will be 30 days.

The difference between 29, or 30 cause all the mistakes and the differences. All the tools in the internet depends on mathematical calculations to determine the length of each month (To my knowledge). Except the two websites I've listed before. The advantage of these websites is that it's updated each day, very trusted, and it's operated by special institutions that focus on hijri date calendars, pray times...etc.

The problem with MW is in Language.php file. Specially the tsToHijri function. This is where hijri date is calculated.

Honestly, probably better to use the extension if it still works, uncyclomedia probably doesn't have big enough categories to matter.

@Reedy Unfortunately the website seems that it depends on PHP code. There is no evidence that it depends on JavaScript code to calculate the date. I've made a lot of research about this problem, and The only way in my opinion to solve this problem is by depending on 3rd party website.

The error is only a warning so it doesnt actually block things yet. But will soon. It is a violation of the privacy policy unless the user has specificly opted in.

In T219827#5075597, @Marostegui wrote:

That's not possible cause it would require setting up multi-source replication on all the instances that are not s7 (where centralauth database lives).

We are not supporting multi-source anymore on new deployments for a number of reasons. It is only living on labsdb hosts and we have already communicated to WMCS that long term that doesn't scale and we need to find a way to workaround it.

Sorry :-(

In T219689#5073914, @kchapman wrote:

Going to un-deprecate, though we are in favor of eventually deprecating the User Object. That is a while off.

(e.g. Checking what percentage of enwiki admins have 2FA enabled).

For reference, the english translation of the error seems to be:

Bad username given
Cannot look for contributions without a user or with a user that does not exist.

In T219728#5072818, @Aklapper wrote:

If I understand correctly this will require CLDR 35.1, ICU 64.2 and Unicode 12.1 planned for 2019-05-07.

So reading a bit about client side performance [This is not my area of expertise] - the best thing (all other things being equal) to do is transfer less bytes. But that's easier said then done.

"EventFactory.php" line 144 also seems kind of wrong. Its passing the wiki name to self::getDomain, but the docs for self::getDomain indicate that that parameter is a boolean for whether or not the wiki display name is used, not as a value to pass the wikiid

I think there might be more than one thing going wrong here, but primarily:

So I think we should do some research into how much different CSS footprints affect performance before actually doing anything, but some initial thoughts on CSS in timeless:

Thank you for your detailed response.

I'm cc'ing @Anomie as I'm not 100% sure, but this sounds very much like a regression from the actor migration.

FWIW, given how much press https://arstechnica.com/information-technology/2018/09/50-million-facebook-accounts-breached-by-an-access-token-harvesting-attack/ has been getting, view-as-other-people features make me nervous.

We're a little worried about the ever expanding size of the security group in phabricator. There are very few visual editor related tasks in Security (You should be able to see them all now). For the moment we would like to just add you to the relevant tasks but not to the security group in general (Please ask if there is ever one you need to see that you can't). Please note this is not about you, we just needed to draw the line somewhere lest the security group becomes a total slippery slope.

I don't think there's anything to do here.

In regards to API modules, you may want to consider making it similar to the authmanager login module, as during the normal login process people will be prompted for the 2FA stuff, so it will have to work with that flow anyways.

The user should be able to choose between enabled modules and maybe use them in parallel. But this will be put to the end of the project, as it may require some more work.

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.