Item12327: new signature system and general improvements

Apologies for unrelated changes in here, but the changes are
interrelated too strongly for separating them into more commits at this
point.

New features and incompatible changes:

* Use SHA-256 instead of the broken MD5 for code signatures; introduces
  dependency on Digest::SHA.

* Introduce a mechanism to add inline signatures to JS code. This makes
  it possible, in principle, to deploy WikiApps with only access to the
  frontend (iff the secret key, newly introduced in SWP's config, is
  known). This mechanism is based on HMAC/SHA-1 signatures. Introduces
  dependency on Digest::HMAC_SHA1.

* In addition to what was filtered before, also filter {} structures in
  the class/data attributes (eval'd by JQueryPlugin::Plugins::METADATA)
  and "javascript:" links.

* Allow the core and other plugins to bypass filtering when using
  Foswiki::addToZone (and its frontends). This prevents dynamically
  generated JS code (most notably, JQueryPlugin's) from being disarmed.
  Plugins are responsible for making sure they don't output anything
  dangerous. The ADDTOZONE macro does NOT bypass filtering. This change
  currently makes it necessary for the plugin to replace a few core
  Foswiki functions. It has been tested with some versions of Foswiki
  trunk and with Foswiki 1.1.5. It probably won't work on much older
  versions.

* The ADDTOZONE macro learned an additional "signature" parameter that
  can contain an HMAC/SHA-1 signature. If an ADDTOZONE block is signed,
  there is special handling in it for only expanding escaped ($percnt)
  macros if they pass an extra validation step; documented in the plugin
  topic. This makes it possible to sign dynamic code that can still be
  safe (if the developer doesn't mess up).

* Remove the config options for explicitly unsafe handlers/URIs etc.
  Having these in the first place encourages wishful thinking: if only
  we blacklist all evil code things will be secure! But blacklisting all
  evil code is a fool's errand. The proper solution is to rely on
  whitelisting exclusively; anything else is not actually secure.

* Allow other plugins to install signatures to a specific location,
  lib/Foswiki/Plugins/SafeWikiPlugin/Signatures. This location is
  probably not ideal, especially when pseudo-install comes in. On IRC
  working/ was suggested, but that seems like more of a location for
  transient data. Ideas welcome.

* Ship Foswiki signatures in Signatures/ instead of in LSC, so that
  admins don't need to merge updates in the LSC field.

* Add mechanism to strip certain tags from the output; filters
  frames/iframes by default to prevent doing weird things in the
  background.

Other changes:

* Filter handler attributes more aggressively by default since the old
  default allowed attackers to break out into arbitrary code.

* Retire warning about {AllowInlineScript} since it's irrelevant when
  SWP is enabled.

* Introduce warning when SWP is installed but disabled; if anyone goes
  to the trouble of installing it in the first place, they almost
  certainly don't want it disabled.

* Let HTML comments survive the filtering. This is not only more
  convenient in many cases, but it also makes the new bypassing features
  easier to implement.

* Don't run if GenPDFPrincePlugin is used and handling the current
  request; it doesn't seem to like SWP sanitizing its output.

* Parser: work on a Unicode string version of the page to avoid charset
  and entity breakage.

* Parser: properly delimit tag attributes when generating the new page;
  do an entities decode/encode round trip to avoid breaking out of the
  delimiters (with special case for <nop>).

* Parser: update list of auto-closing tags; new list taken from current
  WysiwygPlugin. This eliminates a lot of unnecessary output mangling
  that happens because the parser doesn't properly close traditional
  HTML-style auto-closing/empty tags.

* Parser: improve debug output by displaying an element's ID attribute
  in trace mode (if any)

* Parser: warn about unmatched close tags in debug/trace mode only

* When processing IE conditional comments, turn the placeholders into
  HTML comments to avoid any accidental mangling.

* Report both SHA-256 and HMAC/SHA-1 ("SHA" and "MAC") hashes in
  assertions thrown.

* When disarming handlers, default to substituting a comment instead of
  an alert() call (which can be severely annoying in production use).

* Disable the _FORM handler in the parser; it's more of an example than
  something that should actually be used in production. Leave it in
  commented form so it can serve as just that: an example for
  developers.

* This is no longer a WikiRing extension (though the WikiRing logo still
  lives on in the extension's logo).


git-svn-id: http://svn.foswiki.org/trunk@16380 0b4bb1d4-4e5a-0410-9cc4-b2b747904278