robchur wrote:

Surprise, surprise; when people start hacking about with their configuration to
get MediaWiki to do something it was never intended to do, things don't work as
expected.

There is no such thing as a "private page". Blocking all users from reading all
but a few pages is fine, but then not preventing them from editing is obviously
going to yield unwanted results.

Fixing this one requires major changes to the transclusion engine in the parser,
and would make caching far less effective than it is already.

wegge wrote:

Mediawiki does not have private pages. Various patches claims to provide this,
but as they are not part of the mediawiki base, this bug is invalid.

beesley wrote:

Wegge, this isn't about an extension. It's the $wgGroupPermissions setting which
does allow for private pages - all non-whitelisted pages are supposed to made
private with this setting.

$wgGroupPermissions['*']['read'] = false; makes the non-whitelisted pages
private. Only it isn't working since those pages can still be read by
transcluding them in other pages.

http://wikimania2005.wikimedia.org/wiki/Template:Newsflash is not viewable to
unlogged in users, but it appears on the main page. In this case, that's fine
since a registered user chose to put it there, but an unregistered user could do
that with any page if one page was editable.

ayg wrote:

Read whitelists for a private wiki are intended to allow something like reading
the main page (so they can see what the site is about) and Special:Userlogin (so
they can log in). They are not supposed to be used to allow editing of even a
single page, which opens up this vulnerability. As the comment in
DefaultSettings.php says:

• Functionality to make pages inaccessible has not been extensively tested
• for security. Use at your own risk!

This is not a bug. It's a lack of functionality, which is presently deliberate.

There is no support for mixed public/private editing in MediaWiki. Trying to
hack in a patch here will just leave a thousand other holes open.

WONTFIX.