Jehy

safe_mode

For the thumbnailing thing, I removed that part since I didn't quite get what it was saying (you numbered them 1-4, but it seemed that some were steps for the same thing, and others were separate alternatives). If you wish to re-phrase that and wikify it better so that it could be more concise and clear, feel free to add it in.

For the image thumbnailing method that required changing php.ini, I'd leave that out since safe_mode should be set off if you have that sort of access. It does not close any security holes that common sense could prevent from happening in the first place by not running the script. That statement goes not only for MediaWiki (security holes are fixed pretty much as soon as they're discovered, and those are very few and far between), but for other software as well. By exercising common sense, it should be possible to disable safe_mode and still have a secure script and site.

Regarding the put_env, I took that out because it required hacking core files (which isn't recommended at all). Are these put_env errors just notices or actual errors. If it's the latter, feel free to add it back in, but if they're just notices (aka the wiki still works, just has a little notice on top), then perhaps an explanation of how to disable error reporting would be better.

As for the "things that may no longer work", I do not believe that it is possible to prevent deleted files from being saved any more, they just are.

Basically, to sum up the previous few paragraphs, I was being bold in trying to make it more presentable while removing opinionated statements. You can be bold as well in putting things that I removed back in, I won't revert you. I might discuss a specific change on the talk page to see if it could be better worded or something, though :) --Skizzerz 20:31, 6 October 2008 (UTC)

Safemode is neccesary

By exercising common sense, it should be possible to
disable safe_mode and still have a secure script and site.

No way) You see, I've been developing huge web projects for >5 years already and I am very concerned about security issues. Do you really think that developers find ALL security holes and fix them QUICKER then hackers can use them? No way. I was at the role of the hacker too - if you need holes, you will find holes.

And now - just imagine that there are several huge projects on one server. There are many different CMS. You can't be sure that all users upgraded to the latest version of CMS. Also, you can't be sure that all of the latest versions are secure. The only way to separate these project somehow is to use safe mode - only it can act as an iron wall.

Right now, we're hosting more then hundred of different web sites - and I don't want any of them to become a hole which will suck everyone in. Also I can't be sure about even my wiki engine - when I looked through code I found it pretty f#cked up:)

PHP 6, without safe mode, is still in development stage and it will be more then year for it to become stable release. So no way we're going to disable safe mode. --Jehy 20:50, 6 October 2008 (UTC)

You, sir, are very paranoid. Safe_mode is probably one of the worst ways to prevent hackers. The easiest way is to know what you are installing and running and keep up-to-date with security updates. Restricting access to certain features helps as well. Also, I have an account on a shared webhost where there are many people that don't necessarily have the most up-to-date stuff. However, that site has safe_mode off, yet they don't seem to have any sort of security issues. In other words, even if someone can hack through one user's space on a site, that does not mean the entire site is compromised (trust me, I've tried various methods in order to gain shell access, none of them worked. Having a sane list of disabled functions and perhaps installing the Suhoshin PHP extension/patch should keep your site very safe while still keeping safe_mode off). And you say the code is fucked up? Yeah, I'll have to agree with you there. However, it is very secure. Just go ahead and try to find a security hole in a default installation of the latest MediaWiki trunk and/or stable release (without messing with any of the default settings or installing any extensions). If you manage to find one, please let me know that you did (don't tell me what it is -- e-mail security@wikimedia.org regarding that), and maybe then I'll rethink my position. --Skizzerz 20:47, 7 October 2008 (UTC)

put_env

then perhaps an explanation of how to disable error reporting would be better.

Oh, yeah, good note, thanks, somehow forgot about that:). --Jehy 20:53, 6 October 2008 (UTC)

Re: Openid Extension does not work with openid 2.0

I see no evidence that the extension does not work for OpenID 2.0: I logged in to http://wiki.openid.net from two different providers (myOpenID and my own phpMyID-equipped site) without any trouble. If the extension doesn't work exactly the way you'd like it to, then offer improvements or patches to the author, but if the number of well-known wikis that use this extension is any indication, it's clearly not broken or unstable.

—Emufarmers^(T|C) 19:52, 13 November 2008 (UTC)

If the extension works for everybody but you, then the configuration problem is probably on your end. :)

The documentation for the OpenID extension states that not only is OpenID 2.0 supported, it's required.

I'm not sure what the "profile erasing" you mention is; could you point to an example of it occurring? As far as I know, the regular and OpenID login pages are intentionally separate; if they're not supposed to be, then it's more of a feature that's not yet implemented than a bug.

As far as I know, the DOM parser is actually MediaWiki's default. The OpenID extension works well for several large wikis (Wikitravel and wikiHow, among others), and I've installed it myself; I see no reason to scare people away from using it. —Emufarmers^(T|C) 20:51, 13 November 2008 (UTC)

Thank you

Heiya Jehy, thank you for your message! I figured that I could do even better to the extension's page. So I did ... :) Cheers --[[kgh]] (talk) 21:05, 18 September 2012 (UTC)