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

[The Editor]

Thanks for the lengthy reply Pm, much appreciated. I posted a few
comments below, but tried to keep it short, for everyone's sake.

On 6/1/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Fri, Jun 01, 2007 at 09:17:52AM -0400, The Editor wrote:
> > > [...] 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. [...]
> >
> > 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?
>
> I think Ben's point is not that an attacker could get control of the
> wiki, but rather that they could use this to get control of the
> server.  There's a vast difference between the two.

Ok, I guess I still don't see how that could be done, but I'm likely
missing something. I'll put some kind of pattern check on the post
value to try and secure that line of attack. Just ordered a
recommended book strictly on PHP security from Amazon. Hopefully it
will point out other potential holes.

> > Or better yet, since this thread really is supposed to be about
> > PmWiki, why not answer ZAPwiki's conceptual challenges:
>
> Okay, I'll answer the "challenges".  But I do have to point
> out that I've already answered them _many times_ before.

Yes, I know you answered some of them with me before. Still my hope
was when others saw what could be done it might inspire more desire
for it. It's one thing to talk about it hypothetically, another to see
it working.

> > 1. A simple script for auto installing farm fields. How many questions
> > do we get about farm configuration issues?
>
> I've already answered this one, several times.  If we have an
> auto-install script of some sort, then how does it get executed?
> If it's executed from a web browser, then any .php files it creates
> will have to be owned and/or writable by the webserver account.
> To me, that presents too many possible security vulnerabilities
> for the server, and so I've rejected anything that opens the
> possibility to webserver-writable PHP scripts, and I have made
> this reason clear in the past.  ZAPwiki doesn't present any new
> concepts here that I haven't already covered, nor does it
> answer the objections I've raised.

Fair enough, I don't understand really anything how apache works so
I'll have to take your word on this. But still, PmWiki could have a
backup/extraction mechanism that could make it very easy to prepare
pre-bundled wikis. And for the one config file PmWiki would need to
write, couldn't the permissions could be reset once they are created.
Or the ownership of it? Or is that not possible?

> One alternative is to not use .php files for field configuration --
> i.e., make all configuration done by something other than PHP code.
> While I've considered this in the past, and PmWiki uses non-PHP
> files for configuring subsystems such as authuser, notify, intermap,
> etc., I think it will always be the case that the flexibility
> desired by site administrators and required by disparate PHP
> environments will mean that there will always have to be _some_
> manual configuration performed.

Agreed, there should be an option for that. But in ZAPwiki for
example, there's very little need for that kind of configuration, or
for skins, plugins, css, whatever, because that can all be done within
the wiki on the fly. It's very simple structurally.

> > 2) An optional, simpler page format? Ok, you addressed this one, but
> > your point was a dud.
>
> I've already answered this one as well.  My points aren't duds.

No, Ben's point that there were special plugins that could simulate
direct text editing was not very convincing, not your points. In fact,
after my original idea of separating text from data, I came around to
your view point they should be together on the page.

> First, the ability to use a simpler page format is _already_ an
> option in PmWiki -- simply come up with a recipe that provides
> PageStore objects that have the layout you want.  If it ever
> becomes popular enough, it can become a candidate for the core.

Unfortunately, I have no clue how to do this in PmWiki. But I
definitely like the feature.

> Second, I simply have a design preference that all text and
> metadata (passwords, history, attributes) for a page be stored
> in a single unit that can be easily moved from place to place.
> I'm not a fan of designs where we have to be concerned with
> keeping multiple files for the same object (page) in sync with each
> other.

Agreed. Byt my idea was these can be done more flexibly using admin
defined data values rather than hardcoded attributes. ZAPwiki is
actually not so different in that it stores data on the same page, but
invisible in the source--(much like PmWiki's attributes). But because
it's data driven, admin's decide what data they want to save right
within the wiki and can change it instantly for any page they want.
Full flexibility, and simpler code.

I should note my timestamping system, the alternative to diffs, is
stored elsewhere, but it works great in terms of undeletes, etc. Plus
I get to decide when and where and by who, diffs get stored (actually
full timestamped roll back versions). It's all controlled within the
wiki. And my main read pages stay small--like 2-3 K instead of 20-30 K
or much more. Not sure what the speed impact is but it's gotta save
time to not have to load all that stuff up you don't need.

> Lastly, it seems to me that the ability to edit files directly
> on disk is of benefit primarily to the wiki administrator, or
> people that have login/ftp privileges on the account.  It doesn't
> help the typical author (except for those environments where the
> administrator _is_ the typical author, and likes to use text
> editors on files).
>
> So, this feature is one that appears to have relatively low demand.
> (I'll grant that people who really want this feature may be choosing
> other wikis that provide it, such as Dokuwiki.  Still, it doesn't
> appear to be a make-or-break feature for PmWiki adoption.)

Maybe so, but I find it quite valuable as an admin. And unlike
Dokuwiki I keep the data with the page. So I can manually edit it as
well, at the same time.

> > 3) Moving skin control to within the wiki.
>
> I don't have a need for this -- as a skin designer I prefer
> to be able to specify the HTML and CSS directly in files and
> not have to go through wiki markup to do it.  This would also
> seem to require enabling HTML and CSS in wiki markup , or
> providing wiki markup sequences for everything that one might
> want to do in HTML and CSS.  I'm not a fan of either.

Actually, I do use straight html and css pages in ZAPwiki. No markup
involved other than simple markups for things like insert page section
here (zone). What I do is have a list of page types that are
automatically "escaped", such as html or css. So when you create the
page they display exactly as typed, and can be edited directly. Using
a slightly different zone markup causes them to be imported without
using the markup engine. So I can easily create a different skin for
every group, or edit my styles right on the fly--easy.

Only those with admin authority can edit these pages of course,
otherwise the < char gets escaped and it invalidates the code.

> Beyond that, I don't think there's anything in the current design
> that would prevent someone from developing a skin that does
> _all_ of its layout within the wiki.  But as I said, I personally
> don't need it, and I don't hear a large demand for it.  I _do_
> hear frequent demands for being able to get very precise
> skin control outside of what is typically possible in wiki
> markup, or to integrate PmWiki with pre-existing templates
> and sites that have their own skins.

There's little demand, I suspect, because people haven't tried it.
Once I began toying with it, I found it incredibly liberating. Add and
drop zones wherever you want, full hierarchical powers (like Hg). It's
incredible. Get a few souls to get a taste of what it's like, and
there might be more demand for it in PmWiki. I can't imagine who
wouldn't want it.

> > 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.
>
> But, as we've amply demonstrated in the past, this also comes with
> its fair share of security risks.  And forms processing has never
> been PmWiki's primary purpose, although that may change over time.
> The PmForm module I'm working on is intended to provide forms
> processing capability.  However, I'm not looking to supplant what
> we have now.
>
> By advocating a "real form processing engine" instead of "hardcoded
> site actions", what you're really saying is that we should
> discard an awful lot of existing infrastructure (core code and
> recipes) upon which PmWiki has been built.  That may be a valid
> approach, but in the overall scheme of things I don't yet see
> the benefits of that approach as significantly outweighing the
> drawbacks.

First of all, it's only partially true I'm advocating dismantling a
lot of PmWiki infrastructure. It *would* make a lot of infrastructure
completely unnecessary, but both could continue to be available. Not
very efficient, but the required changes, if any, to PmWiki would be
so minimal it would be a shame not to at least explore the
possibilities a bit. It may even already be possible--I just don't
know. I really envision it opening up tremendous avenues for PmWiki,
and it needn't break a single site. I'd love to see it happen for
PmWiki's sake.

This is another real example of once you try it you fall in love with
it. In fact this was the primary conceptual inspiration behind
ZAPwiki. I discussed it with you months ago, when ZAP's potential
began to dawn on me. But now it is working, and amazing. It's piddling
code to have 30 or 40 or 50 powerful, fully customized site
actions--running off a tiny wiki engine. I can instantly change every
facet of how ZAPwiki works by simply editing a ZAP form. Forget the
need for scores of different recipes to "work around" limitations in
the core functionality. I just build what I want right in the wiki,
and it can do about anything I can imagine. And it's easy...

> I also know that many times in the past you've claimed that ZAP
> is intended for "non-programmers", but really much of what ZAP has
> done is simply introduce its own programming "language" and
> constructs, which people must learn to write in before they can
> use it.  Or, they rely on other people to write the ZAP code,
> but that's essentially the "recipe" approach that PmWiki uses.
> Yes, the ZAP language may be somewhat simpler than PHP, Perl, Java,
> or other traditional languages, but just because it isn't one
> of those languages doesn't mean it's not "programming", or that
> it's substantially more accessible to non-programmers for the
> level of capability provided.

Pm, you are exactly right. This is the precise issue. ZAP (and moreso,
ZAPwiki) is really a scripting language. It's not a plugin. But in
terms of ease of learning, there's no comparison between it and PHP,
Perl, or Java. Esp in ZAPwiki where I was able to avoid a good number
of complexities required to get ZAP forms in PmWiki to do what I want.
ZAPwiki makes it all a breeze, and simpler code is stabler code. Try
it and see. If we could just catch a vision for the potential of
incorporating a really good "scripting language" into PmWiki over time
(ie Pm's version, not necessarily ZAP), the results would be
fantastic.

> > 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.
>
> I'm all in favor of people trying other products and saying
> "I really like this feature and wish we could add it to PmWiki".
> For the most part I've tried to develop PmWiki so that even
> if someone wants a feature that I'm not interested in pursuing
> myself, it's possible to do it in PmWiki.

Yes, and this is the reason PmWiki is such a success, and even that
something like ZAPwiki could come along. ZAP would have never come
into existence if you hadn't designed such a flexible engine. But
whole new realms are opening up even in PmWiki. And we are still stuck
in old ways of thinking and programming. We mustn't look backward, we
must look forward. ZAPwiki's not the future, but it may well be a
glimpse of the future.

> However, if the purpose of "ZAPwiki's conceptual challenges" is
> to get me to shoulder the burden of developing and/or supporting
> features that I don't need, don't seem to have much popular
> demand, and that I philosophically disagree with from a long-term
> design and security perspective, then I don't have much to add
> beyond what I've said in the past.  In many previous messages
> I've already addressed these challenges, and cited the drawbacks
> that I see from the approaches advocated here.  ZAPwiki doesn't
> really address the drawbacks I've raised -- it just ignores them
> or treats them as being insignificant.

Actually I'm not asking anything right at the moment but an open
discussion of several new conceptual possibilities for PmWiki--in
light of a radically different proof of concept wiki showing some of
the possibilities of what PmWiki might be able to become one day. If
we're all happy where we are that's fine. But other wiki's are sitting
still either I'm sure. And to stay vibrant we at PmWiki may need to
think a bit about our future.

Lack of demand for something we've never seen is not convincing to me.
I'm not asking for any help developing anything for me. ZAPwiki is
great for my limited needs. But if there is interest in anything
ZAPwiki has to offer, I'm all for helping work together to port things
into PmWiki. No interest, no problem.

> Hope this helps,
>
> Pm

Very helpful, and thanks again for the respect you've shown in
seriously addressing my challenges. I'm happy to accept whatever
conclusion you come to about exploring ideas from ZAPwiki further.

Cheers,
Dan