Upon checking your GitHub profile again, I can now see an email address. I'll send you an email so you can reach out to me directly if needed.

Have you contacted your mentors already? Yes

@Andrew We are done with the project so the floating IP can be reclaimed now. Thanks!

Hi, I am one of Amal's mentors for his GSoC project. I am also one of the primary developers and the chief architect of Canasta. Thank you all for your help with this so far.

Ack, Abhinav, thanks!

Ack, thanks!

Would you be interested if we decided to write the CLI in Rust rather than Python?

Feel free to use our GitHub Issues page https://github.com/WikiWorks/Canasta/issues

Please note: thank you everyone else for your interest in this project. We have received many qualified applicants at this point and would like to begin selecting among our current applicants, so applications are now closed. We hope you will find a GSoC project for this summer and thank you for your time.

Hi Abhinav,

We just had a wiki run into this same issue. Has this been merged into core yet?

I should note that the creation of this task is partly inspired by a recent case where a public wiki with significant traffic had their LocalSettings.php publicly accessible. The upgrade key was visible to the world. The prompt asking for an upgrade key would have been futile against a bad actor who could then proceed to use the web installer on a production wiki. In my opinion, the upgrade key feature is confusing and nearly useless.

@Aklapper I have updated the description to clarify my proposal.

But from memory, doesn't that actually get blocked from use once the localsettings file is place? and you need to quote a random fingerprint reference from the localsettings file to re-run the web installer or change a config in it

@Samwilson I don't have any specific security risks identified at the moment. I thought I did, but it was actually just a misleading, scary-sounding message that this article mentions. It says if you visit /mw-config/index.php?page=Restart, you get this:

Would it perhaps be better to say to upgrade to the latest version of the branch? REL1_35 users should stay on REL1_35, and this works just fine on the latest version of the REL1_35 branch.

Huh, I have no idea why this didn't work before (job queue was empty) but I guess that resolves it. Very surprised, as I haven't changed anything since then, and I guess now it works. Maybe my search query was an edge case, no idea, can't remember it now. I'll try my best to be more descriptive in the future with the repro steps, appreciate your diligent help!

@dcausse Hi, thanks for looking into this! I should've been more clear with my reproduction steps, and I'll update these. I can confirm that both are enabled, otherwise I think it would be obvious that the page with the transclusion doesn't render properly. Did you try with a template or with a regular wiki page like my example?

Sorry, I read too fast. I'll update the description with the template.

@KTC That's all I needed to hear. I would've appreciated if the comment were addressed back in May rather than now when the new criteria have already been promulgated.

@Carlojoseph14 Hello, thanks for the response. Please see my comment at https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation_elections/2021#Reconsideration_of_eligibility_criteria_for_technical_contributions_in_election that I made on May 7.

What kind of data will be shared with StopForumSpam if someone were to install it? Would it send PII?

@KCVelaga, under these new rules, they still would not satisfy cases like me where I have contributed several MediaWiki extensions but still do not meet any of the requirements. I am disappointed that my comment was overlooked and nobody had at least followed up with me, explaining why my proposal might've been too broad.

Thank you for clarifying what I meant to say, but I would like for someone to actually confirm this problem has been fixed on MediaWiki. I cannot do so because I am still not able to get CirrusSearch working on AWS Elasticsearch.

Is this fixed now, since 6.8.1 has been released?

Am I eligible to vote?

Actually, this was already fixed. Was looking at an out-of-date version of the code, my apologies. https://github.com/wikimedia/mediawiki-extensions-ConfirmAccount/blob/master/includes/frontend/ConfirmAccountUI.hooks.php#L31

Ok, I've removed it https://www.mediawiki.org/w/index.php?title=Extension%3AConfirmAccount&type=revision&diff=4645599

That's correct. It can be removed.

This error might occur on 1.35, see T276854 for more details

Sorry if this is the wrong venue to voice this: so, for $wgWhitelistRead, what will be the phase-out process look like? Is there a proposed name for it like $wgAllowlistRead? And I would assume $wgWhitelistRead would be deprecated for a few versions of MediaWiki too. Same question goes for the rest of the LocalSettings.php config options which aren't simple internal core fixes.

One of the problems is that the request is sending withCredentials marked true in the actual XHR. Is there a way to disable it?

This issue still hasn't been resolved. The fallback to img tag is a very reasonable request.

This remains an issue today. Is there any progress made on this?

Since this is a priority for MyWikis, I have written the first (very temporary) patch fixes for hCaptcha only (since it is the most effective captcha currently publicly available). It's not pretty but it'll do the job for anyone who needs to secure their wiki immediately.

Looks like there's no code in Special:RequestAccount to even handle the checking of captchas. Furthermore ConfirmAccount doesn't expose any hooks, so it's difficult for ConfirmEdit to extend ConfirmAccount. I'm working on a temporary stopgap solution for hCaptcha since that is our priority need right now at MyWikis, but hope this is some useful food for thought.

I understand this has been a bug for 4 years. It's kind of alarming because this makes wikis still susceptible to spambot attacks that target Special:RequestAccount. Some spambots on our wikis have already started to take advantage of this. Before they do, this needs to be fixed or lots of wikis relying on this extension will fall prey to spambots. I understand that humans can filter through the spam accounts, but this extension doesn't offer a mass-reject tool. Furthermore, for those using SES for email on their wikis, this can drive up bounce rates to a dangerous point where they might risk being booted off of SES. Has any other work been done on this so far?

Interesting, thanks @Porplemontage for the insight. Notwithstanding the confusing implementation of TextExtracts, I removed the line exintro: true from Popups/src/gateway/mediawiki.js and since I do not know how to compile the frontend JS into the resources/dist/index.js file, I manually removed it from there and it fixed this issue. Now the only issue is it won't stop at the intro (like in this API call it includes the headers and stuff: https://learn.winona.edu/w/api.php?action=query&format=json&prop=info%7Cextracts%7Cpageimages%7Crevisions%7Cinfo&formatversion=2&redirects=true&exchars=525&explaintext=true&piprop=thumbnail&pithumbsize=320&pilicense=any&rvprop=timestamp&inprop=url&titles=Join_a_Zoom_meeting_as_a_participant&smaxage=300&maxage=300&uselang=content), but that's better than nondeterministic "..." and should satisfy our client enough at this point. Hopefully someone can do some more detailed debugging and see why this is the case.

Thank you @ppelberg!

Adding appropriate subproject.

Upon further inspection, this seems to be an aspect of StructuredDiscussions taken from VisualEditor. Adding VisualEditor to this bug.