[03:37:55] Ah thanks for the reminder. Doesn't hurt to put it up on MH Monthly imo. Lots of people aren't on discord but hang out on meta's community portal. [03:42:05] [1/2] LdapAuthentication has been archived several months ago, but we are still using it in https://github.com/miraheze/mediawiki-repos/blob/fe2b659090f909ebc0298eb9dce9242f26673408/mediawiki-repos.yaml#L592 [03:42:05] [2/2] The replacement seems to be https://www.mediawiki.org/wiki/Extension:LDAPAuthentication2 [03:46:52] im not entirely sure we use that sometimes ngl [03:56:58] [1/2] This seems to be the only place that references the extension. [03:56:59] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1394890529493352488/image.png?ex=6878748a&is=6877230a&hm=b4099719383741e2b417df06b3b9f8176414112e01b1eccd4921555e5fbb523d& [04:02:25] https://issue-tracker.miraheze.org/T10825 [05:06:04] Thanks. I removed it from the extension testing list. [05:08:06] because I told reception it should to see if we should go global with it first. We can't unrestrict till I finally get around to launching a new os (very soon I promise lol) and also fixing it so removing it restores legacy search. [05:27:37] [1/3] Can I get the steward user group on mirabeta so that I can test restricted extensions? Or do I have to sign some documents promising that I won't checkuser everyone. [05:27:38] [2/3] Alternatively, maybe a user group with just `managewiki-restricted` can be created and assigned? [05:27:38] [3/3] I'm planning to enable Cargo, Replace Text, External Data, and Semantic MediaWiki. I might repeat the enable/disable cycle a few times especially since Cargo is incompatible with SMW. [05:29:38] LinkTitles is also a restricted extension, though I only see [1 public active wiki using it](https://yourcreatures.miraheze.org/wiki/Special:Version). Not feeling too much motivation TBH. [05:34:23] That's not what the RfF mostly asked though [05:35:19] It did ask that though. It just also asked if it should be unrestricted as the alternative. [05:36:19] Anyway not worried about it. Maybe it didn't need to ask the unrestricted bit at all but its already done. [05:48:51] It doesn't, unrestrcting has been made the primary goal of the RfF and it doesn't it clarify we're not ready to it immediately [05:48:57] It's extremely misleading [05:50:50] That wasn't the purpose I wanted it for. I wanted to know if we should make it global or just unrestrict it. Making it global would have been the easiest from a technical standpoint too. So we don't have to worry about removal breaking search and restoring legacy search. [05:51:27] That's understandable [05:51:34] I get what you intend [05:51:44] What's been presented to users is not that [05:52:17] the proposal to make it global only got like 1 support lol [05:53:37] Fair enough. I dont know if we should correct that with a clarification or just go with unrestricting though. [05:54:15] Unrestricting it doesn't need an RfF so we can start thinking about it [05:54:23] But I'd declare that RfF null & void [05:54:31] Yeah I really think we missed the ball on that which made it really confusing on what that would actually mean. Most of the current issues with CirrusSearch stem from the fact it isn't global. [05:54:35] And represent the global question properly clarifying it [05:58:13] Yeah... anything user facing should have an RfF (well besides procedural stuff like doing each upgrade which has already been made clear is done) but to things we actually control (our own extensions etc... or user facing config changes) need an RfF... anything else doesn't. Unrestricting is not a user facing chanhe that most users notice anyway. [06:00:12] This RfF probably should have left out tbe unrestricting bit entirly and focused on explaining what making it global would actually mean. [06:00:25] Yes [06:00:33] Hence it being null & void [06:00:49] It leaves out most of the useful information [06:03:33] request for failure 😔 [06:04:26] what if we switched to questycaptcha, and generated dynamic questions and answers according to rfc 9402 /j [06:06:51] i think claire is trying to make more catgirls and we should definitely support that [06:21:40] lol I looked up RFC 9402... [06:22:57] the only RFC numbers I know by memory is 2549 lol [06:23:27] well and its predecessor 1149 [08:25:19] @posix_memalign need me to do any patches for extensions btw? [08:26:09] its 230AM and I randomly got this urge to do some Gerrit patches lol [08:26:22] commentstreams is broken on 1.44, possibly from being on that old commot [08:26:55] You can reclone it manually to update it if needed [08:27:30] out and about currently but can do [08:28:32] anything broken should be in p554 (if i remembered the number right; it's linked in the 1.44 ext testing ticket) [08:32:34] no rush. Its possible we will have to remove it tbh. They rewrote it and made it largely blustacks dependent. They did the same thing to SimpleBlogPage. Everything they messed with suddenly had problems and well vulnerabilities. So to reenable CommentStreams on the updated version I'd even want a new review. [08:33:53] aching to ping claire already but will have to see if it even works [08:35:06] if its wanted or used enough by wikis we could maintain a fork too [08:35:26] But if its not used enough we will remove if it doesn't work. [08:36:58] what are we going to do about EmbedSpotify? The maintainer is active on gh but doesn't seem to care about the repo https://github.com/NessunKim/mediawiki-embed-spotify/pulls [08:37:16] No commits in 4 years [08:37:30] Is it used by more than say a few hundred wikis? [08:38:22] 677 [08:38:46] Those not on gerrit or our repos are more heavily scrutinized for this reason. I want to factor some of them out as they stop working. May not be worth maintaining a fork. We should audit actual usage other than those who just enable it and never use it too... [08:39:34] I guess I could put that one on Gerrit [08:39:37] it's basically a single file so I wouldn't mind forking it [08:39:42] or that [08:40:18] I will do that tomorrow. I like it on Gerrit so we dont have to actual maintain it (or the CI for it too) much and can be done more in thr Wikimedia community as needed. [08:41:16] Yeah, that's a good idea, thx [08:42:36] If you find others like that we can do the same for them also... [08:42:51] Just let me know. [08:44:15] hey gotta turn off my VPN to do it lol. The VPN block apparently even affects logged in [08:45:13] @abaddriverlol after its imported I will apply your patch too btw [08:49:57] adhd haver 🫵 [08:50:03] <-- absolutely unproductive for the past week [08:50:15] bluestacks? the android emulator? [08:55:39] lol that was autocorrect for ya [08:55:46] bluestacks [08:55:53] ugh bluespice lol [08:55:56] OHHHHH [08:56:03] i was like "wait, how the hell is bluestacks involved??" [08:56:16] and bleh, thanks bluespice [08:58:52] yeah lol not bluespice [08:58:59] ugh what the he'll autocorrect [08:59:01] lol [08:59:13] not blustacks, bluespice. [08:59:33] my autocorrect flipped and is now trying to autocorrect blustacks as bluespice lol [08:59:49] it doesn't know what its doing [09:02:09] redspice when [09:10:10] respite [12:31:33] OldSpice. [13:53:31] IceSpice [14:04:54] AirSpice [16:29:25] That was 4:30am for me lol. I used to be awake around that time, but have adopted slightly healthier sleeping habits. [16:29:48] I was up till 6:30 last night lol [16:30:23] I need to adopt healthier sleep habits... [18:24:29] [1/3] Is there a mechanism for notifying wikis that an extension they use will be disabled? It shouldn't be too hard to code a bot that automatically leaves a message on the talk page of local bureaucrats/sysops (and fall back to the talk page on meta if the bot cannot edit locally). I'm not sure what would happen if I attach `PetraMagnaBot` on thousands of [18:24:30] [2/3] wikis, though. [18:24:30] [3/3] Alternatively, an announcement page can be made and everyone who needs to know about it will be pinged. With Echo's limit (around 20 pings per edit?), there will need to be lots of edits to notify everyone, though. [18:29:55] A more efficient solution that doesn't require thousands of web requests would probably be to use ToggleExtension.php and modify it to leave a message on all wikis where the extension is disabled [18:30:05] Yeah [18:32:11] Or it could create an echo notification [19:05:51] I think echo notification sounds more promising. I typically only think of frontend solutions because I don't know much about php, so I won't be able to implement the solution myself. [19:07:29] i barely know any php either lol [19:07:43] 99% of the time I'm just looking up whatever those before me have cooked up [19:12:38] i'm sure your non-php skills would translate well if you ever feeling like stringing up the magic words to make mediawiki do what you want on the backend [19:19:45] <.labster> I'm pretty much the same on PHP. Honestly I keep on assuming it works like Perl and then getting into trouble because PHP's worse. [19:24:37] [1/2] I did ask an LLM to write a MW extension (the first commit in [this repository](https://github.com/lihaohong6/ImgTag)) and then gradually morphed it to something that resembles other extensions with similar functionality (e.g. poem). It feels insecure, though, because I don't really know what I'm doing. Writing parser tests helps somewhat but there's [19:24:37] [2/2] still a sense of uncertainty. [19:25:27] you'll know for sure when claire and random make a combined 13 CVEs lol [19:26:23] I think I reviewed that extension once for fun when you sent it in a channel [19:27:12] Back then I didn't find any obvious security issues though [19:28:16] [1/4] only minor things like [19:28:16] [2/4] * rawElement used without any contents [19:28:16] [3/4] * `Use of MediaWiki\Parser\Sanitizer::validateAttributes with sequential array was deprecated in MediaWiki 1.35` [19:28:17] [4/4] * messages should be displayed in the content language instead of the language of the current user [19:29:46] ^ (don't take my word for it though, I only skimmed over the code) [19:30:00] kinda impressive that you didn't have the LLM create (obvious) security issues with something like this [19:30:56] nvm pretty sure I found a vulnerability [19:31:33] ok lmao there we go [19:31:55] Ah thanks! I think I need a code review more since asking other LLMs to do code review was the only option available. I can probably deal with 2 and 3, but I'm not sure how to handle 1 since `img` is supposed to be self-closing. [19:32:19] nvm I didn't [19:32:20] I don't think this extension is deployed in any production system, so maybe it can be shared publicly? [19:32:40] Messages aren’t escaped 😛 [19:32:51] they wanna be free :( [19:32:53] I think those are returned as wikitext though [19:33:42] https://cdn.discordapp.com/attachments/1006789349498699827/1395126264687366376/image.png?ex=68795015&is=6877fe95&hm=8d7ba31e013b84ff453abee1b781a855edf18672964c7776e8312ef88cb31693& [19:34:26] Interesting [19:34:33] I saw in the documentation that `wfMessage` are just examples and shouldn't be used, and I never did it properly... [19:35:01] [1/2] This htmlspecialchars call is unnecessary since rawElement sanitizes attributes anyways (and so does element(), which could be used here instead) [19:35:02] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1395126598356959342/image.png?ex=68795065&is=6877fee5&hm=b409868dafae467836a9a6ec439454efcedbe3d60a1861f26a7e53a167aa3db5& [19:35:05] wfMessage is fine to use if you don’t have access to a message instance [19:36:30] ^ Actually if you don't specify any output mode and just concatenate the message object with strings, I think escaped() is used [19:37:09] [1/2] parse()* [19:37:09] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1395127134908846240/image.png?ex=687950e5&is=6877ff65&hm=56d74c2ef2888f2c9216256d7e3823caeaeb1424c66a97f1407c30ac82b43e7f& [19:37:23] I think you probably want -> text though? Since its going through the parser which will strip out any tags mediawiki doesnt like [19:37:32] You don't want ->text() [19:37:33] That would be an XSS [19:37:47] https://cdn.discordapp.com/attachments/1006789349498699827/1395127292061286420/IMG_7513.png?ex=6879510a&is=6877ff8a&hm=f5f77516cf3d1773f611ea3bf0bc81189dcf60e6e4cc5f7dedd45eed977503ab& [19:37:52] Ah I think that's the remnant of a line of LLM code. It survived multiple rounds of rewrites because I didn't know whether it is needed: the inevitable consequence of using LLMs on unfamiliar systems. [19:37:53] It's outputting HTML though [19:38:39] this is why we have 8 hour documentation deep-dives only to realize you've been looking in the wrong place the whole time [19:39:10] but im pretty sure after the ParserFirstCallInit hook, once the value is returned from that, it goes through the parser again and mediawiki will remove any ambiguous tags iirc? [19:39:31] Ambiguous probably isnt the word i want there [19:40:07] [1/2] https://cdn.discordapp.com/attachments/1006789349498699827/1395127879498465471/image.png?ex=68795196&is=68780016&hm=2c89e235c028e8bfca67330766fc3ebb15f015196805a2ae7c4dd349a76d96a1& [19:40:07] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1395127879754584124/image.png?ex=68795196&is=68780016&hm=2332dea3e41fb6c39731910c3614acdbaa9272cafaf4cebc818361a423a731ec& [19:40:26] vibe check [19:40:30] Interesting [19:40:44] extension tags return HTML by default, parser functions wikitext I think [19:41:06] I wonder what i did for ProgressTableTracking to alleviate this [19:41:44] https://github.com/Telepedia/TableProgressTracking/blob/0a14d1142041b6e6f4e0f6728f0277567884276e/includes/ProgressTableProcessor.php#L413 oh i used good ol trusty htmlspecialchars [19:42:10] no ENT_QUOTES... [19:42:26] But that's irrelevant in this case because of the PHP requirement implied by MW 1.43 [19:42:32] Also it's not in an attribute+ [20:12:48] [1/2] :Sweat: [20:12:48] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1395136106818965555/v.png?ex=68795940&is=687807c0&hm=b322de0cd5bf195aa9ce869226ec6c3057841bd37b6c41ac3b83168e8ce39c0f& [20:13:09] finally put on a toolforge job myself... [21:50:06] toolfops