Hello This is a request for the newly released Squirrel Mail 1.4.0 to be added to portage! Here are the links of relevance. Site: http://www.squirrelmail.org/ Download page: http://www.squirrelmail.org/download.php Many thanks
In case, it is of interest here is the announcement email. ---- Ladies and Gentlemen, After a long wait, serious testing, breaking, and work from developers and users alike, it's out pleasure to announce the final release of SquirrelMail 1.4.0 to the SquirrelMail stable branch. Changes in this Release ======================= This release brings forward some major changes in the way we handle IMAP results, increasing our compatibility with IMAP servers. Other changes include additional languages, faster mail handling, and improved MIME support. A big introduction in this version is the implementation of different authentication methods. To use TLS, PHP 4.3.0 or higher is required, further information on secure authentication can be found in the docs. For further information about the changes made, please see the ChangeLog, and ReleaseNotes document. The latest release can be downloaded from the SquirrelMail website at http://www.squirrelmail.org/download.php Happy SquirrelMailing The SquirrelMail development Team ----
*** Bug 18805 has been marked as a duplicate of this bug. ***
Created attachment 10848 [details] Squirrelmail 1.4.0 ebuild This ebuild is almost identical to the 1.2.11 ebuild -- I just modified the chown statement to only chown the data dir to owned by apache. I beleive this is safer than allowing a web server process to modify the scripts themselves (just in case some apache bug allows people to run arbitrary commands, having directories and scripts owned by apache is a security risk). The tmp dir (whichever one you setup) needs to be writable by user apache as well, but that is outside the scope of the ebuild (some folks just use /tmp). To use the attached file, untar it into /usr/local/portage/net-mail and make sure you have the PORTDIR_OVERLAY uncommented in your /etc/make.conf file. Then, just emerge squirrelmail as normal. I've been using the rc2a version of 1.4.0 for a couple months now, and it has worked great, so hopefully this final version will be just as good.
Is there anyone who has tested out wayne davison (gentoo@blorf.net)'s ebuild ? I'm dying to put 1.4 on my univ's mailserver but a bit wary of migrating a 500 user installation to something that's not tested / confirmed. Depending on how foolhardy/brave I'm feeling i'll emerge it sometime this weekend I guess... and report back. Aniruddha Shankar Bangalore, India
Hello. Here are the following security precautions when rolling out squirrelmail as recommended by the squirrelmail team. The directories below are located in the squirrelmail webmail directory. chown -R apache:apache data mkdir attachments chown -R root:apache attachments chmod 730 attachments The ebuild should work in this way to follow suit with official instructions. Many thanks.
Created attachment 10874 [details] Slightly improved version of previous ebuild. This ebuild improves one more thing in the install process -- it doesn't nag the user about moving old squirrelmail files to new their new location when there are no old-version files to move. Everything else about it is the same and there is no change to the installed files, so I left it at the same ebuild version. As in the previous ebuild, this one only chowns the data dir to apache:apache, so it conforms to the official security instructions. The ebuild does not install an attachment directory, so it leaves it up to the user to follow the instructions in the configuration process on where to put this directory and how to make it safe. If the attachment directory were to be added to the official ebuild we would need to put a .keep file into it (to prevent the next install from removing a possibly empty dir), and we should therefore also install a daily crontab script to cleanup the attachement directory without removing the .keep file. Such an improvement seems like a good idea to me, but I I thought I'd leave it out for now to see if anyone else likes the idea. If so, we should probably also patch the config.pl script to mention the suggested setting for the attachement directory and that it was already being auto-cleaned.
Looks like Daniel Ahlberg has committed a 1.4.0 ebuild, but it is just a copy of the 1.2.11 ebuild file and does not have the security fix nor the anti-nag change that is present in my version of the ebuild.
Frankly, I think the ebuild should just place the package contents in the right locations in the default manner. The rest (advice, configuration, migration of old config and non-essential security modifications) should be left upto the end user and the project site which in this case would be squirrelmail.org. That is the most widely applicable and neutral method of installation. Some changes that were suggested were actually individual preferences rather than global installation requirements.
i'll fix this asap
added in cvs thx
