Sounds good to me. Even as far as timing attacks this is extremely minor (read impossible) as its only comparing the entered password not actual. But i think its good to use hash_equals for any comparison involving a password just in case

One thing that was confusing me was why timeout in limit.sh wasnt killing the process eventually. But after reading docs i guess that is because it didnt have a -k flag

Can you link to which image is being returned as webp?

So looking in the logs, it seems like a log event is generated for importing the key into gpg, but there is no log event for actually encrypting the voting record (The next step after importing the key). This makes me wonder if its an issue with shelling out to gpg.

As an aside, telling x-wikimedia-debug to send me to a php7 seemed to make it work, so definitely seems hhvm related.

In T209802#4756914, @Huji wrote:

I had a feeling it is related to FastCGI as well (just like the other two mentioned above). Sadly, I have no knowledge of FastCGI troubleshooting. I will quietly monitor this thread. Positively surprised that this did not happen during T207560.

In T208668#4756567, @deryckchan wrote:

Depending on the specifics of "reauthentication", this may be a duplicate of T203256.

From what I understand (This is bit beyond my expertise), for things like watchlist where a large number of rows are potentially scanned, its important to keep the tables narrow, so that more of it fits into a page of memory. (Assuming that's true... Which i have no idea. This is beyond my db knowledge) perhaps it makes sense to instead of adding more fields to the watchlist table, instead have a watchlist_info table in a 1:1 relationship which can have more information field (also move wl_notificationtimestamp over there).

Those two patches, well good things, probably dont fix whatever is causing fastCGI to explode.

Fwiw: im of the opinion that date magic words should reduce varnish cache to at least 24 hours, maybe six hours. Im doubtful that super long cache times for all pages in varnish are really that worth it...

In T119366#4754971, @kruusamagi wrote:

For me, it seems that the issue has grown even bigger in time. The delay with Estonian Wikipedia is often like 3 weeks (!!!), that means not-logged-in-users hardly ever see up-to-the-date info when they visit the main page. Could it please be fixed somehow?

Good work :)

[You should probably include the name of the mailing list in the task title]

[Making public is blocks work again]

Definitely sounds partial block related. Cc'ing some AHT people.

Oh i found some varnish/apache errors:

I don't see anything obvious in logstash logs for votewiki. A bunch of:

Can you include the date and full url accessed? (To narrow it down in log files)

Its kind of unclear to me if just earnings should be copied over, or if it should loop through all the returned data and copy everything there over

This task already is public.

Well that's odd. My test change didn't trigger any errors: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/SecurePoll/+/473726/

Did https://gerrit.wikimedia.org/r/#/c/integration/config/+/473724 to make it non-voting until kinks are worked out

The api-auth one is likely because the mime type is not text/html but the script still thinks it is (Thought i already suppressed that)

Wait, so how can oauth create a user with no password? Should this sort of thing require a password reset via email instead?

In T28508#4749602, @MaxBioHazard wrote:

I updated Chrome to version 70.0.3538.102 and this doesn't happen now.

@Bawolff where you see dl.metabar.com on my screenshots? I want to know what of my userscripts accesses this URL.

In T208188#4748329, @daniel wrote:

Looks like I put this under "request IRC meeting" by mistake last week. @Bawolff, do you think this would benefit from a public IRC meeting soon?

@MaxBioHazard CSP is in test only mode - which means it puts errors in the console, but doesn't actually do anything (yet). Any issues you are having is not caused by the CSP warnings.

Done - https://commons.wikimedia.org/wiki/File:Opening_ceremony_of_First_accusation_protest_against_presumption_of_guilt_of_judicial_branch.webm

If I go to html source view-source:https://meta.wikimedia.org/wiki/Special:Log?type=&user=Bawolff&page=&wpdate=0000-00-00&tagfilter=

Looks like @Legoktm fixed the server side part of this in f198154d76782 / T201411 but the client side error is still present.

In T207560#4742653, @Huji wrote:

@4nn1l2 there is no way for us to know if the election was encrypted or not (because our election admin access was removed, appropriately, prior to the election being finalized). But I assume that ALL elections are encrypted by Joe or James. Once the election is complete, they can run the tallies for us.

Language change is not a priority; it is just the right thing to do, and there is no reason to delay it :)

Ok looks good. thanks for your patience on this, I know i was a bit delayed.

Can we add to the "and in addition must" criteria, something along the lines of, have someone responsible for fixing any security issues that come up. Particularly for things we make ourselves, they don't just need to pass security review now, there also needs to be someone responsible for responding to security issues over the long-term, possibly long after development is done. (Things like the lack of response on T207222 are making me concerned about this point)

I've split out the stuff i feel are valid bugs to separate tasks

This could potentially be a good Google-Code-in-2018 task once we figure out how we actually want to do it.

https://codein.withgoogle.com/dashboard/tasks/4619079760478208/

So i guess everyone who updated who didnt get the constraint error now have messed up link tables. That's pretty unfortunate, although i guess at least its slowly self-correcting.

In T209285#4740255, @Aklapper wrote:

Thanks! Closing as per last comment --- see also https://www.mediawiki.org/wiki/Project:Support_desk for support requests.

[If i actually treat this more as a bug report asking for better error handling than a support request]:

[Technically this is not a bug but a support request].

submitted as https://codein.withgoogle.com/dashboard/tasks/6603809146011648/

In T209228#4739497, @Anomie wrote:

It wouldn't hurt to return an error for unexpected verbs, probably somewhere near the check for POST being required.

I'm a bit on the fence over whether it should return 405 as proposed or if it should match how the API currently handles when GET is used with an action that requires a POST. Leaning towards the former though.

This is more a political issue than a technical one. Phabricator is the place to discuss technical bugs not political/social problems.

I'm not really sure what the expected usecase is for this feature. If it is expected that the majority of people who consume this data using spreadsheets, than I agree that CSV may make sense, regardless of my distaste for it as a data interchange format.

In T209217#4737220, @Aklapper wrote:

Proposing to decline this task: Users would get no toolbar at all without the WikiEditor extension, but if users don't have the WikIEditor extension then it is because their administrators actively removed/disabled WikiEditor.

nevermind, i misunderstood

If we must use csv, please be careful about issues like https://www.owasp.org/index.php/CSV_Injection

FYI (per request): bot source is at https://www.mediawiki.org/wiki/User:Bawolff_bot/source

Not sure what happened with the bot, but i tried just running it manually, and it seemed to work.

Special:RecentChanges filtered to JS pages