[pmwiki-users] Conceptual challenges from ZAPwiki...

[The Editor]

On 6/1/07, Ben Wilson <dausha at gmail.com> wrote:
> On 5/31/07, The Editor <editor at fast.st> wrote:
> > Just wanted to post a follow up regarding the initial beta release of ZAPwiki.
>
> Dan, et al. I'm generally a charitable fellow who likes everybody to
> get along. ZAPWiki is the exception to my rule. First, Dan is clearly
> adverting an alternative solution---a rival product.

Well at least the fork accusation has been cleared up. With code like
this, it clearly couldn't be a derivative from PmWiki. It is authentic
Acme style code. : )

But then again, as noted in my post--I don't see it as a rival to
PmWiki at the software level (at least not as it is now), but rather a
challenge at the conceptual level. Quote:

"ZAPwiki at best is a beta, at worst an experiment... Give it some
time to see if it explodes before trying it on anything important...
I'm especially still researching security issues."

To be fair Ben, this should have been acknowledged. Should ZAPwiki
develop into something that was a viable competitor, my personal
ethics would be plenty reason to keep me from advertising it here.

In the meantime though I do find the conceptual challenges worth
discussing as a contributing member of the PmWiki community. If PmWiki
can't stand up to a few questions about it's underlying assumptions we
have a bigger problem than ZAPwiki. But Pm has never been anything but
fair minded and responsive to questions not only about how it works
but why PmWiki works the way it does. And the community has generally
been open about discussing possibilities for PmWiki even if they never
do pan out.

> Second, he's
> suggesting that his expertise and approach is so radical that Pm
> should consider incorporating its design.

Absolutely wrong on the expertise part. I didn't know a thing about
php before joining PmWiki (as a result of some post I googled written
by you by the way, describing the advantages of PmWiki over Drupal).
And I have nothing but the highest respect for Pm's programming
knowledge and experience. Yet, until some of the conceptual challenges
 are at least addressed I do admit I'm inclined to believe the
"approach" of ZAPwiki has significant advantages.

> Third, the code sucks and
> his design allows _any_ user to subvert the system. Having helped a
> non-profit survive a spam hacker who owned their server for several
> months, I can tell you that the exploits in this code would allow my
> toddler to own ZAPWiki.

Whether this is true or not is irrelevant as what I'm advocating, or
at least exploring, is whether some of the foundational concepts in
ZAPwiki are worth considering for PmWiki. If the argument were over
which wiki you should use, it would be an issue. But if the issue is
whether some of these concepts could benefit PmWiki (a fair question I
think), and ZAPwiki demonstrates however porly the possibilities (ie,
proof of concept), then specific problems in ZAPwiki are irrelevant.

When I suggested a way to reorganize the cookbook using a forum
approach, Pm like the idea, but worked out a much simpler
implementation. When I began tinkering with the ZAP precursor to the
MarkupExpressions concept, Pm completely rewrote the code and now it's
core. In similar ways, I have no delusions Pm would borrow ZAPwiki
code, but it's possible he might make baby steps toward some of it's
concepts. In his own expert, deliberate, and secure way.

So, whether or not the code in ZAPwiki truly sucks, completely ignores
the conceptual challenges ZAPwiki raises. Which was the primary
purpose of my post.

> Having looked at your "barn," I can say I'm quite shocked at how much
> you need to learn about programming. You have multiple functions, all
> of which take no input but immediately incorporate a global variable,
> process that variable, then return that variable.

Could you give me one example. I'm not saying they are not there, but
I think you may be mistaken. In the main engine script for example,
there are only three functions which take no input, and none of them
return a variable. I did not check every function in every script, but
an example or two might be helpful. Unless of course this is just
polemic you are spewing against something you see as threat to PmWiki.
Good grief, I hope not.

> You freely inject raw user data into HTML pages, which violates quite
> a few security standards. (You even use the code to change the
> $_GET['action']) Your code assumes a trusting user, which is like
> putting the keys on the top of your Bentley in Harlem at 9p on a
> Friday night and returning on Monday to expect the car to still be
> there.

Despite the colorful illustration, your lack of specificity or perhaps
my lack of security expertise makes this a meaningless jumble. First,
if you examined the engine you'll notice that all user input is
cleaned before being saving based on the security level of the
individual. (One feature I miss from Drupal, actually). That is,
@admins can indeed put html and php directly into a page, but input
from @guests and @members always have all potentially risky code
escaped. Also, only specially qualified @editors can create ZAP forms
that do anything. There are also many other ways to restrict
privileges based on user or group. So unless you missed how ZAPwiki
works, or I miss your meaning, your cursory glance at ZAPwiki was
incorrect.

As for the line about the GET action, I'd be curious to know what the
security risk is. It's just a shortcut due to my over familiarity with
PmWiki that converts index.php?p=main?action=edit to the more proper
index.php?p=main&action=edit. ZAPwiki has several such shortcuts--it
designed takes seriously making things easier. But you make the risk
of doing this sound extreme!  More polemic? or is there a real
problem? Honestly...

> What makes this more disturbing is that one of those raw user
> variables used during your setup is used to write your index.php:
>
>        $index = "<?php\n\n\$ZAPadmin='$_POST[admin]';\n\ninclude_once('../barn/engine.php');";
>        savePage('index.php', $index, $field . '/');
>
> This is insane. You think the single quotes do some good, but this
> allows me to write my own program within your program. Heck, it would
> be more fun to write a program that would allow me to completely
> overwrite your index.php at will with a user submitted post. Something
> like:
>
> $_POST['admin'] =<<<MALCODE
> ';
> if ($_REQUEST['badboy'] = 'naughty') {
> // Evil Keneval bad code uploading form, which takes a user uploaded
> file. Oh, make user 'badboy' is 'nasty'.
> }
> elseif ($_REQUEST['badboy'] = 'nasty') {
> $index = "<?php\n\n$_REQUEST['badcode']";
>        savePage('index.php', $index, $field . '/');
> }
> MALCODE;

Sure I understand the issue here, I dealt with it earlier when I tried
using eval to execute ZAP plugins. (Long since fixed by the way). But
no, I had no illusions the single quotes would solve anything. They
are just needed for the index page output.

What you fail to mention however is that this line is never run unless
there is also a POST field with the proper password value--a user
defined password, stored on the server and fully encrypted. So yes, if
some hacker could get that password, and they then forged a POST
submission, they could get control of your wiki. But then again why
bother forging a post if they have password? Just create your wiki and
gain control the normal way? For that matter, why not just get the
server account password, and take full control of everything forget
about ZAPwiki.

If you have a problem with allowing those with password permission to
be able to create wiki's that's one thing. But let's not be
disengenous, and say the whole setup file is completely unprotected.

Besides, it's worth noting, for the more security cautious, ZAPwiki
runs perfectly without the setup.php script. So once your wiki is
generated, just delete it form the server. No problem. Oh, and while
on the subject, just like in PmWiki, the barn code can easily be moved
to non-writable webspace.

> Since you've been misguided enough to let the web server have write
> access to index.php, then you deserve the fruits of your labors. The
> 'badcode' could easily be a suite of spam software that spawns a rash
> of spam each time somebody _visits_ your site. With this, I can write
> my own back door and change that door at will.

Admittedly, I have not yet done anything much with permissions. One of
the security areas I'm still researching is server permissions. But
that will be fixed soon enough. I initially took a few stabs at it and
had some problems getting it to work right. So postponed it. But with
ZAPwiki's simple installation structure, this is quite easy to set
manually, and will hopefully be automated very soon, definitely before
ZAPwiki comes out of beta.

> As far as using a text editor to edit raw wiki text, that's easily
> possible with PmWiki, as demonstrated by Cookbook:Pywe and the Pmwe
> tool. Heck, all you need to do is write a simple wrapper that knows
> how to wrap/unwrap the raw wiki file and inject your nifty text. It's
> not like PmWiki uses a super-secret algorithm to make things
> difficult. In fact, PmWiki's page storage system is _almost_ like
> JSON.

It's true there are tools you can use to mimic this. And maybe it's
not even that hard. But can you edit a wiki page easily with say
notepad?  Or if you are using a web-based site editing program like
the one that comes standard with CPanel, can you edit PmWiki pages
with it, easily--say from some friends computer without your special
software available?  It may be insignifcant, but it's one thing to say
you can create a special wrapper, another to say no wrapper is needed.

And again to avoid the perception I'm trying to compare PmWiki and
ZAPwiki, I'm only suggesting some similar mechanism be made available
within PmWiki. Pm has already said this could be done within PmWiki by
creating a custom page store class, or something of the sort. Either a
recipe or a core config setting that can be turned on or off. I love
the feature, and think others might too. If so, PmWiki would be
benefited by making it an option. But only Pm could say whether it's
practical within the current PmWiki codebase. Reworking the attributes
to make this possible might be a nightmare. Maybe not.

> ZAPWiki, meet handyman special.

I'll pass commenting on your heartbreaker story at the end of email.
If you think the code is rank ameteur quality, I won't argue the
point. But it might be helpful to put something substantial behind the
charge.

Or better yet, since this thread really is supposed to be about
PmWiki, why not answer ZAPwiki's conceptual challenges:

1. A simple script for auto installing farm fields. How many questions
do we get about farm configuration issues?

2) An optional, simpler page format? Ok, you addressed this one, but
your point was a dud.

3) Moving skin control to within the wiki. ZAPwiki has some very
creative and flexible ideas in this area. And the results are in my
view, impressive. Surely some bright mind could replicate something
similar in PmWiki. There's already recipes that get us there part way.

4) How about a real form processing engine in PmWiki and a way to use
it instead of hardcoded site actions. Until you've toyed with this
some you have no idea how liberating (and efficient) ZAPwiki's
approach is. It's probably already possible between PmWiki and ZAP, or
could be made so quite easily.

To the rest of the list: if you try ZAPwiki--try it so you can see
what you're missing in PmWiki and then make a request PmWiki do
something similar. Use it to make PmWiki better. Don't switch (I can't
support you. 90% of the list questions are over my head). Let's
instead make PmWiki all it can be.

Cheers,
Dan