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

[Patrick R. Michaud]

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.

> 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.

> 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.

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.

> 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.

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.

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.  

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.)

> 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.

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.

> 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.

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.

> 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.

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.

So, I think I've already answered the "ZAPwiki conceptual
challenges" in the past; ZAPwiki doesn't answer the counterpoints
I've raised to those challenges.

Lastly, you've made comments about ZAPwiki's smaller size, as
compared to PmWiki (I presume 2.2.0-beta).  I think that's a 
very apples-to-oranges comparison.  PmWiki has trails,
supports multiple languages and character encodings, controls for
web spiders and robots, three types of caching, RSS feeds, 
merging of simultaneous edits, automatically downloaded blocklists, 
authentication from external sources, etc.  So, for a more 
representative comparison of code size, try comparing against 
PmWiki 1.0.0 (2775 lines [1]), or even earlier.  I think you'll find 
that for comparable feature sets, PmWiki's code size has generally 
been equal or smaller than what ZAPwiki is providing.

Hope this helps,

Pm


[1]  Determined by counting lines in all .php files of pmwiki-1.0.0,
     excluding scripts/layout-0.5.php which was used only for
     sites migrating from PmWiki versions prior to 0.6.1.