User talk:Skizzerz

Please start a new thread by clicking the link below. If you leave a message here, I will respond here (unless you state that I should answer on your talk page).

Archives

Previous page history was archived for backup purposes at User talk:Skizzerz/LQT Archive 1 on 2015-07-10.

As noted on their Phabricator recently, Miraheze is considering retirement of the RegexFunctions extension from their list during their transition to MW 1.40. As Agent Isai (talk · contribs) has pointed out, "This extension has some very long standing security issues which led to be disabled globally over a year ago. Glancing at the git repo...nothing has changed. [It] should thus be undeployed." While porting conlang-dictionary entries from Referata to my MH site, yours truly found out the hard way back then (as documented at length in T8866).

In case you've caught this message now or in the next few days, maybe you could try upgrading it to a level that meets MH's security threshold, or take up the matter to a developer who knows their way around regex. Perhaps Wikimedia's own Phab might be informed next?

To @Bawolff: From here, I'll leave further commentary/ideas/suggestions to you. --Slgrandson (talk) 20:14, 26 May 2023 (UTC)

Nobody has notified me about any security issues with RegexFunctions so I haven’t the slightest idea of what they’re talking about.

I'm not really sure why im pinged here, but is there a public description of the issue? Are we talking about ReDOS or something else?

Nothing pops out to me at a quick glance through the repo. Other than maybe a ReDoS risk, but i don't really think that matters in context to most users, practically speaking.

@Skizzerz: /@Bawolff: Long story short: Per Universal Omega (talk · contribs) last year at T8866, MH Phab:

• "RegexFunctions has been disabled as it's causing OOMs."
• "We do not want to optimize regexes, since we don't control what users use it for, so it is not a suitable option for us."

--Slgrandson (talk) 22:18, 26 May 2023 (UTC)

Pathological regex patterns are not a security issue, they are a configuration issue. PCRE has multiple php.ini settings to control how much backtracking or recursion will be allowed in a regex before it errors out.

Hi!

I just stumbled upon https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SecurePoll/+/1003091

Great work!

My team at Hallo Welt! GmbH was just about to start with this. Now we are a little bit confused about how to move on. Do you plan to finalize this change in the near future? Or would you be okay if we took over? You'd be credited for the change of course.

Best regards, Robert

I'll be doing a patch set to address the review comments later today, and I don't think there's too much else to be done. Still needs some more thorough testing however, if you want to help out with that.

I don't see myself abandoning this change.

Understood, thanks!

I don't believe anything further needs to be said.

Hello, Skizzerz. I have fixed the remaining issues the best I could for the custom GlobalBlocking extension. Thanks for helping me get a working version of this suited to my needs.

Dear interface administrator,

This is Samuel from the Security team and I hope my message finds you well.

There is an ongoing discussion on a proposed policy governing the use of external resources in gadgets and UserJS. The proposed Third-party resources policy aims at making the UserJS and Gadgets landscape a bit safer by encouraging best practices around external resources. After an initial non-public conversation with a small number of interface admins and staff, we've launched a much larger, public consultation to get a wider pool of feedback for improving the policy proposal. Based on the ideas received so far, the proposed policy now includes some of the risks related to user scripts and gadgets loading third-party resources, best practices for gadgets and UserJS developers, and exemptions requirements such as code transparency and inspectability.

As an interface administrator, your feedback and suggestions are warmly welcome until July 17, 2023 on the policy talk page.

Have a great day!

Samuel (WMF), on behalf of the Foundation's Security team 12:08, 10 July 2023 (UTC)

Hello. I hope that this message finds you well. As usual, letting you know that I've started the yearly admin activity review at Topic:Xdac9fsd71grrbup. Users have been notified on their respective talk pages (except for Vogone, which has been notified on Meta because his user talk page here redirects to his user page). I've skipped three users that although inactive are also WMF staff and so may need additional permissions for their work. Best regards.

Hello again. Since there was no reply from the users I notified, nor any objections from the community, I went ahead and removed the users listed as inactive per the global and local policy. Yours sincerely,

Hello, could you check your emails and your talk page on thetestwiki.org? I sent 2 emails on March 20 and I left the message on your talk page on April 9.

I will never respond to email, consider it a one-way communication channel. As for your talk page request, I'm largely unconcerned. The account will be deflagged for inactivity eventually.

OK, thank you for information.

Hi!

You get this message because you are an admin on a Wikimedia wiki.

When someone edits a Wikimedia wiki without being logged in today, we show their IP address. As you may already know, we will not be able to do this in the future. This is a decision by the Wikimedia Foundation Legal department, because norms and regulations for privacy online have changed.

Instead of the IP we will show a masked identity. You as an admin will still be able to access the IP. There will also be a new user right for those who need to see the full IPs of unregistered users to fight vandalism, harassment and spam without being admins. Patrollers will also see part of the IP even without this user right. We are also working on better tools to help.

If you have not seen it before, you can read more on Meta. If you want to make sure you don’t miss technical changes on the Wikimedia wikis, you can subscribe to the weekly technical newsletter.

We have two suggested ways this identity could work. We would appreciate your feedback on which way you think would work best for you and your wiki, now and in the future. You can let us know on the talk page. You can write in your language. The suggestions were posted in October and we will decide after 17 January.

Thank you. /Johan (WMF)

18:17, 4 January 2022 (UTC)

Hello! Happy new year. I hope that this message finds you well. I am about to start the first admin activity review round based on the August RfC. I'll post the list at Project:Current issues and on each affected admin talk page. While we've reviewed the list a couple of times to ensure there's no mistakes, we've identified that a couple of tools seem to be lagging behind (or the replicas). Best regards.

Please check your email box.

I received your email but have some questions; you seem to already have an account here. Which wiki are you asking about?

I`m sorry,I mean your test wiki.

I was wondering if you'd be open to creating a gerrit repo for GTag? That way you would get automatic access to updates and other things.

I'm not interested in putting anything on Gerrit for the time being. The upsides are not worth the downsides in my opinion (that is: lack of ultimate control over what does/doesn't get merged in and the fact Gerrit itself is a gigantic pain in the rear to work with).

I may re-evaluate when/if GitLab happens, but even then the control issue still exists. I have had issues in the past where well-meaning contributors break the compatibility policy with their updates or just outright break the extension in general due to not understanding what it does (and not testing), and someone else who similarly has no understanding and didn't do any testing +2's it.

Understood. I just discovered this and deployed it so I thought I'd ask.