You are here: Foswiki>Tasks Web>Item3154 (14 Mar 2011, GeorgeClark)Edit Attach
Configure extension installer leaves zip and installer script behind in twiki root

Here they are accessible - worst case executable.

I do not like that as time goes by and many extensions are added the root has maybe 40 files in the twiki root that are just left behind.

The installer should remove the tgz and installer.

When you install manually you know they are there and you remove them but when you use the configure you will not know that this garbage is left behind.

I see this as a potential security issue. We cannot be sure that files in this directory cannot be executed and who know how a hacker can take advantage of an installer script which is not made to be robust to user inputs. Therefore urgent

-- KJL

No. When you install manually, you should keep the zips/tgz's - most people do. It's an essential part of being able to reproduce your configuration if everything goes spazzy.

As documented, the installer script is able to use/download to a directory pointed at by the environment variable TWIKI_PACKAGES. The point of this is to enable local admins to set up local repositories of packages.

I don't agree on this point, and am setting to "Waiting for Feedback" so you can consider my points.


CC and KJL have a point. I think the best of both world is to have downloaded extensions stored in twiki/download by default. An empty directory with just one protective .htaccess can be shipped in the distribution.


Saving in a download directory is fine. Controlling this with an environment variable is absolute gaga. We should simply create a new directory for this in the lib directory. This is already pretty well protected so you can use your TWiki4.0 Apache config. lib/download. There is no value adding making this flexible. Just more problems for the newbie to break his neck on.


The packages are designed to be extracted in the root directory. The extension installer looks in the root directory for packages. The installers all assume they are run from the root directory. Moving the packages to a download subdirectory is just work creation. The reason I added $TWIKI_PACKAGES is that I work with admins who store all downloaded packages in faraway places. They don't want packages stored under the TWiki tree because they revision control the entire installation.

Personally I don't see this as a requirement; there are far more pressing issues. I'm going to leave this open, but I'm regrading to an Enhancement and setting to Actioning as it's pretty clear what has to be rewritten (a lot).


I am not so concerned with the zip or tgz being left behind. They should never be a security issue. But the installer is an executable and if the root dir allows execution because the admin is not an apache setup expert (most are not) some evil spirit may explot an installer. The installer scripts are not written with security in mind. So maybe just delete the installer after the installation is complete. It is only when downloading and installing from configure I am concerned! So it is configure that should clean out the installer from the twiki root.

When you install manually I have not concern because then you can expect the admin to clean up and move things out of the way.


In 1.1, the refactored code no longer uses TWIKI_PACKAGES.
  • Zip/Tar files are no longer saved.
  • _installer files are stored in working/configure/pkgdata

-- GeorgeClark - 09 Apr 2010

I change the state of this to Waiting For Release.

Even if this was resolved in another bug item it is still good to have the happy message in the release note that also this issue is resolved.

Thanks for fixing this George.

Updated the headline for use in release note

-- KennethLavrsen - 09 Apr 2010

ItemTemplate edit

Summary Configure extension installer should not leave zip and installer script behind in foswiki root
ReportedBy Foswiki:Main.KennethLavrsen
SVN Range TWiki-4.1, Thu, 09 Nov 2006, build 11947
AppliesTo Engine
Component Configure
Priority Enhancement
CurrentState Closed
TargetRelease minor
ReleasedIn 1.1.0
Topic revision: r12 - 14 Mar 2011, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy