Why does Extension:Inline SVG not solve security issues by do the same security checks as did in uploaded SVG files?
Remove protection from MediaWiki 1.17
Hi can you please remove protection from MediaWiki 1.17 this please. Because I doint think it needs to be protected any more nor do I think it is high Visable due to it no longer being supported. And it is not the latest Mediawiki version so please remove protection from it thanks.
مرحبا بك ما إسمك ومن أين أنت؟
Noticed, that you have deleted my extension. The security risk with the extension is intentional! The extension is intentionally made to reveal user's email, so it is not possible to remove the security risk without rendering the extension pointless... Some wikis were using the extension and they need the (possibly updated) extension code to be available in order to restore their installations.
Hope to hear from you very soon as people are waiting! -- Joosep-Georg
Restored, I would also highly recommended getting the extension stored in our git repository if people actually have a desire to use it.
Thanks! Have also made a request now for git access as you suggested.
I'm just testing stuff.
And LQT doesn't like you!
Some WikiLove for you!
|Some WikiLove for you!|
|:> —Emufarmers(T|C) 23:07, 31 March 2013 (UTC)|
Git and Gerrit template
Hi, about a month ago I spent a bunch of hours sorting out the Git/Gerrit in order to declare this bug fixed. One of the things I proposed and nobody opposed was to get rid of the Git and Gerrit template. If you have good reasons to bring it back please discuss at Template talk:Git and Gerrit. Otherwise it would be great if you could revert your changes. I didn't delete just because I thought it would be ok to leave some time until the pages still using it could clean it up, but maybe it will be good to remove it altogether to avoid confusion and extra work. Thank you!
1. Having a logical template (which has the same links as the Gerrit page) personally seems to be a-lot more logical then having a large context-less gerrit logo (Which in most cases linked to the Gerrit page, Although at least once linked Externally to the Gerrit interface) and personally I would view that as helping resolve #36437.
2. Almost all of the terms on that template are directly linked from the Gerrit page anyway and most of those are or will be useful to those that want to look at and learn about Gerrit.
(Moving from email to talk page where it should have gone) Hey; can I ask you to not turn on any more LiquidThreads instances on the talkpages relating to the new Article Feedback Tool and the Zoom interface - and, if possible, to turn the existing ones off? We're trying to get a lot more community members to participate, and many aren't comfortable with LQT, meaning there is another hoop for them to jump through before they get involved.
O.K./Ironholds Community Liason, Product Development Wikimedia Foundation
- I have a talk page where this should have gone in the first place (which is where I've now moved it)
- Consensus (or what we class as consensus for this wiki in the irc channel) for this wiki seems to be we went it used where possible unless utterly broken
- If they aren't comfortable posting in LQT, They most likely wouldn't be in a non LQT page, I can easily tell what Talk:Article feedback would be like without it and that would be even scarier, and that is hardly a loop for them to get involved, because in most cases it's even easier.
- I also know some of the new users that have posted to Talk:Article feedback and they wouldn't have gotten involved if LQT wasn't involved, Which is one of the exact hurdles that LQT is designed to overcome when it comes to editing talkpages because of the mess and wall of text they become in the edit window.
- But if you want to disable it, feel free but it will be up to whoever disables it to copy and paste every one of the comments over to the talk page.
I've forgotten why Extension:SpecialDeleteOldRevisions2 had a security problem.
Warning: The code or configuration described here poses a major security risk.
Site administrators: You are advised against using it until this security issue is resolved.
Problem: Vulnerable to SQL injection attacks, because it passes user input directly into SQL commands. This may lead to user accounts being hijacked, wiki content being compromised, private data being leaked, malware being injected, and the entire wiki content being erased, among other things.
Solution: make proper use of MediaWiki's database class instead of concatenating raw sql
Warning: This extension assumes that only the revisions and archives tables use our text storage. If any extension you have installed makes use of our text storage on its own then this extension will purge all content that is being used by that extension and break it.
Is what was posted on the page.
Hi Peachey88, some time ago you deleted the page for the Extension:FileIndexer and replaced it with a warning saying that the extension has security issues, and that users should use some other equivalent extension. However there is no equivalent extension (to my knowledge), and the security issues are not explained in the talk page, nor in bugzilla, so we developers have no idea how to solve them. Could you please explain them in the talk page, or open a bug report? Thanks.
I've done some digging, and it appears that it could allow arbitrary shell commands to be executed, such as "rm -rf".
It's a shame this got deleted instead of fixed. They did the same thing to the SQL2Wiki extension that I use extensively, in a safe manner. Why does "momma wiki" think we need protection from ourselves? Wasn't the stern warning at the top of these extensions enough?
Because you would think people pay attention when there is a security warning, But like most extension repositories people don't.
If someone was wanting to fix it, They can (I will even un-delete or give them the code sources), But when they were deleted they had the warnings for 12+ months with no action on it.
Thanks for the info. Actually I'am not interested to access the code (except maybe for study purposes :), but I'am thinking about adding access to Gnuplot to my Extension:R. If it is just shell access via the tickmarks then I have similar problem in R and octave too. The solution there could be applied for Gnuplot as well.