Introduce notion of 'safe' and 'unsafe' plugins

[astei]

I would like to introduce a notion of "safe" and "unsafe" plugins to the Velocity API. This does not construe a change in our versioning policy, rather it is an affirmation of it.

What are safe and unsafe plugins?

Safe plugins are those plugins that use the API exclusively, do not rely on internal ABI details, and explicitly depend on any plugins they need to depend on. These plugins are only "safe" in the sense that they use the Velocity API (and do not rely on our ABI) and are careful about using APIs from other plugins. Examples of "safe" plugins include NuVotifier and Catalyst.

Unsafe plugins are plugins that are not safe. Examples include the Via* plugins (because they inject into the server and client pipelines).

What changes are coming?

We plan to introduce this notion in Velocity 1.1.0 but safe and unsafe plugins will continue to act the same, at least immediately. The first changes that will treat safe plugins differently from unsafe plugins will come in Velocity 1.2.0 (or 2.0.0 if we get to that point, which is not very likely).

We plan to introduce this notion in Velocity 2.0.0.

Possible changes include:

• Restricting the classloader environment for "safe" plugins.
• Indicating a proxy instance as "tainted" due to the use of an unsafe plugin.
• Locking down some dangerous internal APIs so safe plugins can't access them.

[hugmanrique]

I like the idea. How about also encouraging unsafe plugin authors to include a range of tested/"safe" versions and fail hard if unsupported? Of course, this can be implemented by each plugin, but additional class loading precautions need to be taken, e.g. so as to shutdown the proxy instead of throwing a ClassNotFoundException.

[astei]

The other thing I want to stress is that this is not a security mechanism - it's more of a correctness mechanism.

[astei]

We will probably leverage Jigsaw support (see #354) to enforce these restrictions.