[pmwiki-users] New Acme recipe...

[Patrick R. Michaud]

On Wed, Apr 18, 2007 at 09:31:23AM +0100, Hans wrote:
> Tuesday, April 17, 2007, 11:06:38 PM, The Editor wrote:
> > The code is quite functional and works well.  Hans changed the
> > status to beta for me because PmWiki is in beta status, and ZAP
> > requires the latest beta versions.  Other than that it is quite
> > stable.
> 
> There is no official status for PmWiki add-ons released in the cookbook
> section.  Pm does not take any responsibility for functionality or
> security regards to theses scripts. I think it is up to us, as
> a community of PmWiki users and recipe developers, to provide feedback
> about recipes and issue warnings where necessary, and correct errors
> on cookbook pages, if found.

I largely agree, with some clairifications.  

While PmWiki doesn't designate any official status to recipes, 
that doesn't mean that recipe authors and/or the community cannot 
declare some.  

It's also very true that I don't (can't) make any claims about the
functionality or security implications of any scripts that appear
in the cookbook -- if only because it would be impossible for me
to keep up with them all.  But this is an appropriate task for the
community; as people perceive issues in recipes, simply report them,
either on the recipe page itself or in the recipe's -Talk page.

(Of course, I do vouch for recipes that I author, and if a recipe
is enabled on pmwiki.org that's a good indication that I think the
recipe is reasonably safe from a security perspective -- at least
to the level that I'm comfortable with for pmwiki.org.)

> Also: PmWiki is not in beta status. PmWiki 2.1.27 is available as a
> stable release. Only the newest development of PmWiki 2.2.0 is
> undergoing a prolonged beta series of releases, which are fairly
> stable in themselves, but have required configuration adjustments here
> and there by administrators.

This is correct -- PmWiki has a 'stable' release (2.1.27).  The 
leading-edge development releases are designated as 'beta' to indicate:
  - the release contains new and/or experimental features that are
    still subject to change
  - some core features of the previous 'stable' release may be
    different and/or non-existent in the beta

However, past history has demonstrated that PmWiki 'beta' releases
also tend to be fairly stable from an operational perspective, and
that it's generally safe to use them.  Whether or not this is true 
for a given recipe really depends on the recipe.

I'll add more about PmWiki 2.2.0's beta status in a subsequent message.

> >> - Is it safe to use
> 
> > No known security vulnerabilities or bugs.  All are fixed as rapidly
> > as possible. In some ways it is more secure than other processors as
> > it uses session variables for all it's major commands. [...]
> 
> I would love to hear other's opinions on this. Especially about the
> claim that using session variables makes it more secure.

Security is a very complex topic, and in general there are limited
ways to get it right and lots of ways to get it wrong.  The best
measure of security is to have the code reviewed by others and to
see how well it survives real-world attacks.  

The use of session variables doesn't automatically make a script
"more secure" -- it depends on how they are used.  To give an example,
a recipe might use session variables to store a captcha key, but
if that recipe also transmits the captcha key in cleartext as
part of an input form, then the use of the session variable hasn't 
increased security at all.  (In fact, in such a case the session variable
will technically provide _less_ security, because the captcha value is
available in even more places than it was before.)

I also have difficulty blindly accepting the claim that "it is more
secure than other processors", as I don't know how deeply the security
implications of _any_ of the forms processing scripts have been studied.
Such a claim really needs some more hard evidence to back it up 
(and as I mentioned above, the use of session variables is by itself not
guarantor of increased security).

> Pm has said that he will most likely use {$$varname} syntax for
> replacement variables in future in PmWiki. When this comes into
> effect I predict ZAP will follow suit and change the {varname} syntax
> to {$$varname}. Then all of ZAP's forms need to be modified. 
> Sites using the old syntax will break. 

Actually, it's entirely possible for ZAP to support both syntaxes,
and then any existing forms wouldn't need modification, or could
be migrated over a longer period of time.

> I think it is only fair to mention
> this, as Dan has been warned by Pm that the {varname} may very likely
> cause conflicts in future with other pieces of PmWiki modules.

I don't know that I meant to imply "very likely" -- I think I was 
simply pointing out that {varname} (or anything using single curly 
braces) is not a good choice of syntax because it's very easy for
it to inadvertently conflict with other markup sequences that may
want to use curly braces.

And {$$varname} is now definite for any templating items that I
may be developing.

> >> - Do I need to use ZAP or ACME
> 
> > The Acme Forms ZAPPING Engine is the name of the recipe. The
> > underlying code and scripts continue to be called ZAP.
> 
> [...]
> >> - Why all these names

I agree that having the many names (FAST/ZAP/Acme/ZAPPING)
is really confusing.

> So we can safely give Dr Fred C credit for the idea to rename the ZAP
> page "Acme", and deduct that Dan's prime motive for doing so is to get
> ZAP to the top of pagelists in PmWiki. Since the cookbook sidebar is
> now showing categories using pagelists I suspect Dan felt ZAP will not get
> noticed enough.

If this is the motive, it probably won't matter much in the long
run anyway, since "Show search results by relevance" is on the 
development road map and a likely candidate for implementation in
the very near future.

I think I'll also look at adding a "Ratings" section/page variable 
to recipes, so that newcomers to PmWiki can get some guidance as to
the overall use of individual recipes.  I just need a syntax for
rating.  Ideally it will end up being something like

    * [[~Pm]]   +3    works for me
    * [[~John]] -2    it totally broke my system

except I'm not sure I like the "+3" and "-2" notation because it's 
difficult to represent negative votes in a concise format.  
More on this in another message.

Pm