chasd wrote: >> I suppose the folder could be moved to/from a folder that is not >> web-accessible > > I think that is the best approach if you are concerned about security.
I would still prefer it didn't exist at all on an existing install, as it shouldn't be necessary. :) > You could have an apache directive forbidding access to "installer1" Or even for 'installer' for that matter, and the warning message could check for such a condition. >> but that would only further complicate the situation. > If you have an automated way to do it, the complexity is hidden and > forgotten. I'd prefer a simple/elegant solution over hidden complexity. In my experience, that would inevitably lead to breakage down the road and more confusion over how to fix it (unless it's well-documented). >> Here is another interesting possibility: Could the installer chmod >> itself 000 after it is finished running? > > The possibility I thought of was to tar the directory up before > removing it. > When it comes time to update, untar the file. > > If the files are tarred up, they can't be executed, only downloaded. That's another good possibility. Given any of these choices, though, I would go for the simpler choice of aliasing "svn up; rm -rf installer/". Here's another choice: Have a config option, that if absent (either left out or if there is no config file) activates the installer. It could be something like $rcmail_config['post_install'] = true. If the variable is set, the installer scripts would die or become inactive. Some other projects use such a variable to prove that you have edited the default config. Jim _______________________________________________ List info: http://lists.roundcube.net/dev/
