[Pkg-mediawiki-devel] Fwd: Re: MediaWiki patches in Debian.

[Max Semenik]

On 12.06.2012, 11:16 Thorsten wrote:

>> With a significant number of subpages available, this patch would
>> allow to DoS a wiki with simple F5 being constantly pressed.

> DoS is doable much more easily, so that’s no concern here,
> but ok, then this is not upstreamable.

Not only it's not upstreamable, but it's also completely unacceptable
for any web-facing piece of software. Ask any DBA if you don't believe
me - SELECT ... LIMIT 30000 should not be possible to trigger with a
simple HTTP request.


>> >> +    - includes/DefaultSettings.php: add webdavs:// and file: support
>> 
>> Apparently, NEVER EDIT THIS FILE at the top of DefaultSettings is not
>> enough? All such changes kill people's ability to painlessly switch to
>> tarball

> These are the local patches I added in our company’s APT repository,
> where “people” means “the sysadmins”, and that’s, in the case of
> wikis, me. So this is no point.

> Also, a packager is bound to change files. Even if this were not a
> local patch, I’d say, “so what? only packages are supported”. (But
> please, let’s not go there. I just wanted to present the few local
> changes I have for possible inclusion.)

>> give them. Or if packages are broken.

> Fix the packages, then.

Hey, and who of us is a packager? :D

What I want is:
1) To see as few people asking for support and getting help like
"throw away your package and use tarball".
2) To make migration of existing MW installations as painless as
possible. Every custom patch in a package means another problem for
mortals who want to change their host. Especially when settings
suddenly change when they shouldn't: DefaultSettings specifies
MediaWiki's _default_ behaviour, while LocalSettings defines _local_
overrides. People expect that settings related to their installations
continue working when they, e.g. upgrade from 1.5 to 1.20. Things
change when they change their host and discover that some stuff that
was set in DefaultSettings got lost.

I can, however, see the problem with other changes having to be made
to DefaultSettings while they are more suitable for LocalSettings, and
going to add some extensibility features to our installer that would
make it easy for packagers to alter the installation process without
having to hack the MediaWiki core.

For example, at the bottom of LocalSettings:

if ( strpos( 'debian', $wgVersion ) !== false ) {
   require_once( '/etc/somewhere/debian-overrides.php' );
}

This setup would make any transitions smooth: if you're not using a
particular package, all configuration settings related to it (such as
texvc or ImageMagick paths) get seamlessly reset to defaults. And even
then I would recommend against adding stuff like support for random
protocols.

>> Also, I strongly doubt about these protocols' support across different
>> browsers and platforms (especially file:), which means more nice ways
>> to shoot yourself on the foot.

> Konqueror (standard browser on KDE environments) supports them, and
> our document management software is usable best via WebDAV. This is
> a case of “Wikipedia” thinking vs. “Wiki used inside a specific en‐
> vironment, such as a company” thinking. And if one of these links
> does not work for a user, that does not matter at all, either. The
> important thing here is that it works for most, and that it should,
> must, be included.

Ehm, know what's Konqueror's current usage share? 0.05%. MediaWiki is
not a desktop software so you can't assume that everyone accessing a
MW installation has your preferred browser. You seem to be interested
mostly in enterprise use while a lot more people run MW on public
sites.

>> >> +  * debian/control: prefer PostgreSQL over MySQL in Depends/Recommends
>> 
>> PG is currently third DB in terms on MW support, significant number of
>> extensions don't support it. If we recommend MySQL for MW, pretty

> MySQL is not a database, and the MW installations in FusionForge use
> the same database as the forge itself, just a different schema (one
> per project). Why do you try to force your limited world view on
> everyone?

> Honestly, if MW does not work with PostgreSQL, either that’s going
> to be fixed or MW is abandoned.

Want better PG support in MediaWiki? Patches are welcome. So far
everything had been self-regulated: most developers use MySQL - hence
it has best support. A lot of developers (including me) use SQLite -
hence it's considered second in terms of support. A lot fewer
developers use PG and not so many users are interested in running
wikis on it, so even though MediaWiki core is mostly bug free in
regards of PG support, not so many extensions support it properly and
people whom you convinced to use PG might want to migrate to something
else later. Not because PostgreSQL is inferior to MySQL or vice versa
but because they want something that doesn't support PG.

>  Performance is impossible
> with a PHP web application, anyway, already. Again, your reply
> shows trying to force your limited world view upon everyone. I
> personally don’t mix well with that (strictly not speaking for
> FF, Debian, or my employer).

PHP being allegedly slow (slower than what? Wikipedia and Facebook use
it with their extreme load) is not a reason for making a hole that
allows DB load two orders of magnitude higher. These things are not
related and there are other means of doing what you want.



-- 
Best regards,
  Max Semenik ([[User:MaxSem]])