[02:20:36] dude when i saw [[Fundraiser/Ads]] i was confused 😭 [02:20:36] https://meta.miraheze.org/wiki/Fundraiser/Ads [02:20:37]

[02:20:44] like i thought that there were ads in miraheze 💀 [02:33:52] That would be a funny April fools [02:33:55] Oops! All ads [02:49:10] The shocking truth about aerosols that aerosol companies DO NOT want you to know! [02:50:09] But it's too late for April Fools 🤔 [02:50:34] We should make a May Fools and make ads the joke [03:02:12] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> Hey uhh I need some urgent help! [03:02:28] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> Remember Chace from earlier? [03:03:17] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> Well...he just ranked like half the god dang wiki to admin, including making a steward-blocked user into a bureaucrat. [03:03:31] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> And I am powerless in this situation, please help [03:10:10] Please make a post on the stewards' noticeboard. @Stewards , see above, temporarily promoted user (chace) is engaged in borderline vandal behavior on dreamlogoswiki [03:11:45] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> Where do I put it on the noticeboard? [03:12:02] In the permissions section [03:13:00] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> Ok! I don't know if it was by malicious intent or so but he definitly had no business ranking a blocked user. [03:14:03] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> And while your at it, may you change SMG4Rocks block back from indefinite to 6 months. he blocked him for indefinite for no apparent reason [03:14:09] For future reference, don't give out bureaucrat even on a temporary basis if you're not comfortable with them keeping it. [03:14:36] Because that's essentially co-owner permissions and a mess to remove. [03:18:29] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> Ok I put in the request [03:18:51] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> And yes, I have learned my lesson from doing this again. Thank you [03:19:21] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> God that was so stupid of me. I am so sorry for the hassle I caused today Miraheze. I promise I won't do this again. [03:21:57] Well, live and learn. 🙂 [03:22:33] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> Exactly. :) [03:33:58] Yeah, that right there is why I became very conscious of what I give out too. [03:39:48] @𝕮𝖍𝖆𝖗𝖑𝖎e your request is malformed [03:39:59] it's at the top of the section and doesn't have the wiki field filled out correctly [03:49:05] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> Ok I fixed it [03:49:25] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> oh wait [03:49:51] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> something is glitched it wont let me fix it [03:51:41] I believe on the ones besides status you need to get rid of the `` around the text. [03:53:52] Yep, those make it comment out anything between those marks [03:53:54] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> Oh it worked thx [04:26:33] Hi everybody, My name is Renato and My Miraheze account is called RENATO THE CRACK OFICIAL [04:27:32] I'm from Wiki Polandball Hispana (An Spanish-language wiki) [06:21:32] Why does this show up when logged out on the Stewards Noticeboard? "Western liberal democracies enshrine in a citizen's fundamental, constitutionally-enshrined legal rights the right to know and face one's accuser, and Miraheze is no different." [06:21:43] That does not make any sense at all. [06:33:27] Dmehus wrote it [06:33:30] ¯\(ツ)/¯ [06:34:54] Hmm [06:35:10] maybe i can ask him about it once he's online [08:17:43] Collei: please stop noindexing things [08:33:45] where did that wiki go lmao [08:34:35] nvmd figured it out [11:44:56] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> Hi happy easter [13:42:24] Can private wiki be redacted by two people? [13:44:34] I’m not sure what you mean by that [13:46:19] you want to have only two editors while the rest members can only read? [13:47:02] yes, you can remove edit rights from *, user and member groups and pretty much have yourself and another editor as sysop (admin) [13:55:45] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> Hey uhh [13:56:49] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> My request for permission thing got accepted, but everyone in the situation still has the rights they were unauthorizedly given. Everyone except Chace [14:01:18] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> The only ranked people on the wiki as of now is supposed to be me and formal bureaucrat Duc4Wikimedia [14:26:34] they're all bureaus too? or just admins (sysop)? [14:44:30] would have thought for unauthorized, stewards would have also reversed all of that... [15:00:15] @Stewards , more to do on Charlie's request. Charlie, please update your request on the noticeboard [15:18:17] Hey all, I am running into an obstacle enabling HotCat on a wiki. Is this the channel to ask? [15:18:33] Goodnight! [15:19:02] TurtleAndRabbit: Sure. [15:21:28] I have followed the instructions on the meta for HotCat (discord blocks my link), but the gadget tab in preferences doesnt show up or anything [15:22:04] Can you share a link to your wiki? [15:22:29] Anterra [15:22:50] (I am not the owner) [15:25:13] Discord not liking me sharing links [15:25:17] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132, replying to NotAracham#0009> oh what do I update [15:25:32] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> do I just add the users who still have the rights? [15:32:22] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132> Ok I have updated the request [15:33:20] TurtleAndRabbit: Well we kinda need the link, just the name isn't enough [15:33:49] Discord is blocking my links tho [15:34:00] I have tried [15:34:11] you should /auth [15:34:17] to post links here [15:35:35] ach so [15:35:36] https://anterra.miraheze.org [15:35:54] yay [15:40:44] Hmmm, you should no longer be blocked as a verified user... [15:41:12] Oh, good job discord, pulled new messages 6 minutes late. 😄 [16:04:07] TurtleAndRabbit: If you've followed the instructions at https://meta.miraheze.org/wiki/Gadgets/HotCat everything should work [16:04:19] I think it's because the gadgets extension isn't enabled: https://anterra.miraheze.org/wiki/Special:Version [16:04:52] You can enable it at ManageWiki [16:07:19] Lol at the advertisements on the fundraiser page [16:10:27] I need to know what the aerosol companies know [16:11:16] I'll contact the admin, I cannot see the option for it with my role [16:17:17] They have enabled gadgets [16:20:22] I have turned it on in my preferences, but it still doesnt show up ? [16:20:25] weird [16:21:13] nevermind [16:21:26] it works now! Thank you Orange Star!!\ [16:58:08] So, just to make sure I understand, both cargo and smw require a survival request to enable? [17:53:48] Yeah [17:59:10] people on Sagan 4 keep asking why various random Cargo-dependent things are broken 😔 [18:00:15] smw on sagan4alpha and sagan4beta still has not been done [18:02:23] [1/2] Wow I must be visually impaired; for the longest time I thought the stewards noticeboard was all h2 and just my request at the bottom of the page [18:02:24] [2/2] In hindsight I shoulda just used edit section lol [18:13:11] It was for a while but requests were inefficient [18:13:30] now it's easier for Stewards to handle requests now that they have easy links to handle reqs [18:13:42] but for SMW, a sysadmin has to enable it and I guess no one's had time to clerk it [18:35:14] Where do I make that request? [18:39:11] Stewards' Noticeboard, restricted features [18:39:46] https://meta.miraheze.org/wiki/Stewards%27noticeboard#Restrictedsettingchangerequests [19:09:46] @florigon#5751 yeah, the advertisements thing on the fundraiser page is funny lmao [19:17:19] see announcements, cargo is disabled due to security concerns [19:19:54] They are very much aware; it's just that readers (or editors even) might not understand [19:27:20] <𝕮𝖍𝖆𝖗𝖑𝖎e#1132, replying to NotAracham#0009> Hey I updated my request thing and the users in the squabble haven't been ranked back yet. I understand that you stewards are very busy people so I'll be out of your hairs of probably the rest of the day. Just needed to let you guys know [19:27:24] I know [19:27:53] I was venting about our users complaining about things being broken [19:28:54] Sagan 4 Mason was switched to using smw in direct response but the request for the other two Sagan 4 wikis is taking longer [19:30:37] I know things are broken, but a few broken wikis are better than every Miraheze user being hacked. [19:33:48] I wonder how non-miraheze wikis are dealing with this [19:34:27] i don't know how many wikis use cargo, but it's a good question [19:36:41] Collei: every user being hacked is a bit misleading. Passwords are hashed + salted. [19:36:52] You still have to crack them [19:37:05] Oh, I see. [19:37:18] Yeah, that's a good point, but hashed passwords are still a concern. [19:38:04] Collei: it’s a risk [19:38:06] yea [19:41:03] Yaron did advise for separate databases, can't really hack much of anyone if the user table can't be reached and simply setting into read only seems good enough if the data being available is required [19:41:47] Yes, we’re planning that [19:45:50] hm, is there an eta on that? originally requested smw since there hasn't been any updates on the cargo situation [19:46:04] What's the exact reason of disabling cargo? [19:46:16] would prefer to not have to bother y'all to undo smw [19:46:20] given there are probably a good number of wikis using cargo, its going to take time to migrate to a better solution [19:46:23] Some kind of very serious exploit that affect non cargo wikis? [19:46:30] max20091#7318 i believe so [19:46:40] meant to @ [19:46:51] it would let attackers view database passwords or something [19:46:59] a security patch was apparently reverted after the mailing list announcement [19:47:09] Oof [19:47:33] yeah, high risk security issue involving database. best that can be done is move to separate and set into read only mode [19:48:43] not locating the patch reversed, though I did notice TK-999 [fandom] having submitted a patch that was later reverted by author [19:49:34] maybe the author left a 0 day vulnerability in there so they could sell it to the CIA or something /j [19:50:22] Also any URL to the patch? [19:50:44] Want to look at the code [19:52:41] [[extension:cargo]] [19:52:41] https://meta.miraheze.org/wiki/extension:cargo [19:52:42]

[19:53:07] [[extension:Cargo]] [19:53:07] https://meta.miraheze.org/wiki/extension:Cargo [19:53:17] crap [19:53:26] [[mw:Extension:Cargo]] [19:53:26] https://www.mediawiki.org/wiki/Extension:Cargo [19:53:29] there you go [19:55:12] no link showed up [19:59:10] https://www.mediawiki.org/wiki/Extension:Cargo [19:59:10] oh [19:59:34] The extension suffers from issues with SQL Injection [19:59:54] What the [20:00:06] Collei: wm-bot isn’t relayed [20:00:08] that's the most obvious vuln that every dev should know about [20:00:19] Collei: it’s Yaron [20:00:25] and RhinosF1: i see [20:00:28] also idk who yaron is [20:00:31] Widgets was an RCE and him [20:00:47] Collei: the developer of a few major issues [20:00:49] i see [20:00:57] new rule: no yaron extensions /j [20:01:31] I wouldn’t joke [20:02:07] as in its not funny or as in yaron extensions are so bad we should stop supporting them? [20:02:54] is it really that hard to fix? (in this case) [20:02:56] only asking because the Phabricator ticket is private [20:03:00] He is likely to come under scrutiny [20:03:08] All security issues are private [20:03:27] i see [20:03:27] It was accidentally made public due to an administrative error for a short time [20:05:42] Miraheze SRE detected and disclosed that to WMF staff and took quick action to protect users [20:06:00] WMF Security’s extension releases are poorly co-ordinated [20:07:09] i see [20:08:31] this appears to be the 3rd time cargo had a security issue [20:08:39] https://phabricator.wikimedia.org/T91893 [20:08:39] https://phabricator.wikimedia.org/T194726 [20:15:16] most MediaWiki extensions use high-level methods like `$dbw->select()` that make SQL injections nearly impossible [20:15:17] this method is not sufficient for Cargo. Cargo needs to construct SQL queries of greater compexity than this interface allows [20:16:48] yeah i know why that is, but i still think that *three* separate SQL injection vulnerabilities since the extesion was released is more than a dev just making a mistake because of the complexity of the code [20:17:26] because it was initially not written carefully enough [20:17:47] it appears to still not be written carefully enough after all these years [20:18:07] I don't see jumping at the developer as a constructive thing to do right now [20:18:13] Building off an unfortunate foundation is what it is. Seconded. [20:18:28] any extension that stores data or modifies data can have issues...I almost wonder if some of the routine extension given patches should take cargo's approach of separate database with limited privileges [20:18:45] AF, CU commonly have patches [20:18:47] we just need to fix it, but alas, with the Phabricator ticket being private, I don't know where the problem is [20:19:04] fixing it can't possibly be more difficult than several weeks of migrating off Cargo [20:27:05] well as RhinosF1 said, Miraheze SRE did spot the task so maybe they have an idea and could at least patch for Miraheze if possible [20:27:52] checkuser has multiple items patched. same for abusefilter. many extensions are used without knowledge of security issues [20:38:34] @Edward Chernenko if you want access, speak to Reedy or Scott [20:38:52] @M3w we are aware of ways we can mitigate [20:39:20] Lots of extensions have issues, we have to accept some risks @M3w - we assess that to a degree when installing extensions [20:39:31] We unfortunately do sometimes miss serious issues though [20:39:37] Like with widgets & cargo [20:39:50] But more professional reviews are far too expensive [21:25:03] Cargo was written by one of the most prolific MediaWiki developers that don't work for WMF, so the guy knows what he's doing anyway, and just missed some points of failure. [21:32:01] yes, you already mentioned. was simply chatting with Edwards [21:51:34] in any case, I mention af and cu because those are regularly patched [21:53:40] Doesn’t widgets also have security concerns? [21:54:03] Which is also a yar on extension. [22:00:36] Couldn't a security unintentionally be introduced or missed by any developer at some point? [22:00:48] *a secruity concern, I meant [22:01:27] It could. But it seems a recurrence with Yaron’s extensions. [22:02:52] We have cargo configured to run on a separate db on our independent, as is recommended in the config I think. [22:04:09] Not sure exactly what that means tb, but I thought it might limit the availability of what can be accessed, and of potential security concerns? [22:05:18] My (very limited understanding and) impression was, that configuring on separate database proposed to prevent such? [22:06:23] [22:07:14] For that reason, we followed that recommendation. Am hoping this indeed limits potential issues as was suggested there^? [22:09:27] If the potential for such bugs was included in the installation setup suggestions/options, it would seem the author acknowledges publicly that such issues may exist now and then (perhaps as at any point in time, one developer, vs a team might be a challenge to stay on top of things)? [22:10:31] [1/2] placing cargo on separate database keeps it away from user/actor tables which prevents compromise or hijack of user accounts, all that would remain is sql injection again the cargo database. with it on separate db, you could just lock out modifying of existing data while allowing it to remain enabled for the time being [22:10:31] [2/2] its one person maintaining thus possible for a dev to miss it and Yaron is running it through the usual checks, perhaps those are not enough [22:11:05] not sure if that is a good solution [22:11:50] Compromise and/or hijacking/accessing user accounts was our primary concern, and reason for separating the db as suggested/indicated was possible. [22:12:37] No idea how that might work/operate on a farm, though. [22:12:56] Works fine for us. [22:13:02] (On independent wiki) [22:14:25] At least, so far lol [22:14:48] it wouldn't be too much to separate for wikifarm, just that configuring it for every wiki on wikifarm would be more SRE work [22:15:10] I mean you would need a dedicated db server just for cargo, which may not be available [22:15:45] if you wanted to be super careful otherwise a separate database is plenty [22:15:47] Good point, I could see why, that'd create a bit of a maintenance burden/overhead. [22:17:45] I seriously feel based on similar amount of patches to abusefilter and checkuser...maybe its time to move those to separate databases with some way of remotely fetching user/actor ids. might be worth considering for WMF given how often patches are issued, this time was 3 separate issues for CU [22:18:10] 3 patches for CU is a lot [22:19:21] 3 patches in what duration of time? [22:19:36] 3 patches in its entire lifetime, not that bad [22:19:43] 3 patches in a month, then yeah [22:20:24] this recent announcement was 3 [22:20:38] I do think the Cargo author disclosing such publicly in his manual, was more than enough acknowledgement security issues may exist. That appears reasonably forthright. [22:21:51] Providing an in-the-meantime or just-in-case config solution was also appreciated. 🤷‍♀️ I do get irked a little sometimes about how long it takes things to get fixed... but, I have a hard time begrudging any developer for being busy. [22:22:29] Though ideally, a certain level of continuity of support would be nice, in a perfect world. [22:23:32] It is what it is, any extension is appreciated. [22:31:56] [1/2] Bawolff suggested a restricted separate database [22:31:56] [2/2] - note that cargo should use separate db and have separate db user with restricted privileges. main mediawiki db user should not have cross db access to cargo to avoid user/actor compromise/hijack [22:32:13] It'd be great going forward, if a mistake or issue in someone's work wasn't assessed as a personal character flaw or failing. Divorcing ourselves from that kind of thinking is the most mature and reasonable way forward. A consideration that anyone (including ourselves) would likely appreciate, when directed at us. [22:33:14] I.e., Treat others how you would like to be treated--is an awesome professional skill. [22:34:09] All humans are human, all humans make mistakes. Always remember the human. [22:34:58] It's too easy to think of people like avatars, divorced from the human. One day this will (hopefully) be part of being a digital citizen. [22:36:00] *It's too easy to think of, and treat, people like avatars, divorced from the human. Remembering the human will (hopefully) one day be an important part of being a "digital citizen", even if we're not there yet. [22:37:02] I was hoping to have had more work done on this already, but have had a bit too much to do on personal matters. Soonest I'll be able to start working on Cargo again is tomorrow. [22:37:14] No worries Void. [22:37:28] Take the time you need! [22:40:01] The biggest difficulty is that for our setup we will need a separate cargo database for every wiki. This adds some complexity to wiki management such as renaming a wiki database and deleting a wiki. [22:40:14] Apologies in advance (am Canadian) if I'm too verbose on this topic, as EdTech is one of my areas of study (grad school), which includes finding a way forward to educate in digital citizenship. Could see how this could be irritating for others tho lol. 😆 [22:40:58] Understandable. [22:40:59] No no, I think it's a good attitude to have :) [22:44:06]