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

Fri Jun 1 17:41:29 CDT 2007

Two points:

1. Would it make sense to move this thread to the pmwiki-devel forum?

2. I get a bit concerned when Patrick feels compelled to repeat points 
previously made, particularly in relation to a challenge to his 
legitimacy, or the legitimacy of his technical positions. It wastes his 
time, and presumably saps his normally sunny demeanor<grin>

There comes a time when it becomes legitimate to say that a thread 
doesn't belong here, and when challenges to Patrick become belabored and 
inappropriate, even with Patrick's unique generosity.

- Henrik

Patrick R. Michaud 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.
>
>   
>> 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.
>
>
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>
>
>   

-- 

Henrik Bechmann
www.bechmann.ca
Webmaster, www.dufferinpark.ca

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-users/attachments/20070601/ba5fdbbf/attachment.html 