Extension installer

As part of refactoring configure in DEVELOP branch, I have coded an extension installer similar in behaviour to the Firefox extensions browser. I want to propose that it be included in release 4.1

• It requires a major refactoring of configure, so is unreasonable to ship it stand-alone (as a contrib)
• It is ready to roll, subject to testing.
• It has some implications for the plugins web, because it only really works with extensions packaged using the BuildContrib.
• It adds several new package dependencies, including LWP (while it could be made to work with getUrl, I am not prepared to do that work). However these are ony required if the extension installer is invoked, and are not required for the rest of configure.

Security Considerations

Before preparing to use the extension installer in your TWiki, make sure you understand its implications on security: In contrast to the Firefox extension browser where all you can blow up is your PC, a TWiki extension installer creates software on a server.

The extension installer can only work if critical parts of a TWiki installation (the lib/TWiki/Contrib and lib/TWiki/Plugins directories, plus bin and tools for certain Contribs) are writeable for the web server's user id.

• Double check all other CGIs running under the same user id. Other CGIs under the same user id can't just trash your data (as they can in any TWiki installation), they can change your code by overwriting any of the extensions which came through the installer, and so they can compromise the whole web server. This is especially important with TWikiOnWebHostingSites: separation against other hosted CGIs by a wrapper (suexec, cgiwrap...) isn't just recommended, it is mandatory for the extension installer.
• Double check the integrity of the extension you're going to install (you always do that, don't you?). Every registered user can upload an extension to twiki.org and adjust the MD5 file to his needs.
• Make sure that you have a way to get rid of unwanted extensions and any files they create. All files created by the extension installer will be owned by the web server's user id, so it might take root access to delete them.
  • You can not rely on uninstalling with configure if you caught malicious code. The code can change your configuration password as well, e.g. in the installer script of a malicious extension.

Gory details

Stop reading here if Perl frightens you (it frightens me, so you are not alone!)

The installer is a plugin-in UI module to configure. It is triggered by finding %EXTENSIONS% in TWiki.cfg, same way as %PLUGINS% works.

The module pulls a page from t.o (http://twiki.org/cgi-bin/view/Plugins/FastReport), which is a SEARCH with output specifically formatted to be easily parsed. This page is presented to the user. Existing installed plugins are discovered by checking (use $module) for the module pm (e.g. lib/TWiki/Contrib/PatternSkin.pm). If a plugin is selected for installation, then LWP is used to download the installer script. The script is then run.

Installer scripts have changed to download an archive if there isn't an existing one in a local packages directory, and unpack and install hands-off.

-- Contributors: CrawfordCurrie

Discussion

I think this is a great idea. This will make managing plugins a whole lot easier.

On a related now, one thing that has always troubled me about TWiki plugins and extensions is how they are co-mingled with the TWiki core. It would be nice if each plugin's source and related files were kept separate somehow -- any strategies for doing this?

Of course, if the installer/uninstaller is manages all of this properly this is not nearly as large an issue.

-- ChristopherRued - 16 Sep 2006