zarafa-announce

zarafa-announce@lists.fedoraproject.org

64 discussions

Zarafa 7.1.14 has been pushed to stable updates
by Robert Scheck 02 Dec '15

02 Dec '15

Good evening, Zarafa 7.1.14 has been pushed to stable updates (Fedora EPEL 5, 6, 7 and Fedora 21). Here is the full list of changes in Zarafa 7.1.14 [51822]: Zarafa Collaboration Platform 7.1.14 final [51822] ================================================== - ZCP-13581: update fck-editor (for webaccess) to solve CVE-2012-4000 - ZCP-13572: CVE-2015-6566 - zarafa-autorespond suffers from a potential local privilege escalation - ZCP-13087: Meeting requests are not being sent with Thunderbird Lightning due to new functionality - ZCP-13608: Attachments are missing in the Sent items folder when using a cache profile - ZCP-13243: ser_safe_mode falsely reports that it would delete users You should be able to update to Zarafa 7.1.14 by using yum update 'zarafa*' on all Fedora releases and Fedora EPEL. If you should find bugs or issues, please fill a bug report in Red Hat Bugzilla as described here: https://fedoraproject.org/wiki/Zarafa#Bugs Your feedback is very much appreciated. Greetings, Robert

1 0

Zarafa 7.1.13 has been submitted to updates-testing
by Robert Scheck 05 Aug '15

05 Aug '15

Good evening, Zarafa 7.1.13 has been submitted to updates-testing (Fedora EPEL 5, 6, 7 and Fedora 21). Here is the full list of changes in Zarafa 7.1.13 [51032]: Zarafa Collaboration Platform 7.1.13 final [51032] ================================================== Downstream changes ------------------ - Added patch to fix a possible XSS situation in WebAccess - Added patch to avoid non-working default font in WebAccess - Added patch to implement DHE/EDH support (aside of ECDHE) Upstream changes ---------------- - ZCP-12956: Auto-accept meeting request does not work after update to ZCP 7.2 and 7.1.12 - ZCP-13401: Attachment handler closes file descriptor twice - ZCP-13405: Segmentation fault in ldap plugin - ZCP-13175: Mail from Mac OSX 10.10 sends broken umlauts - ZCP-13374: SIGABRT (6), out of memory or unhandled exception on RHEL 6 Zarafa 7.1.12 - ZCP-13222: Missing /etc/zarafa/php-mapi.cfg leads to segfault in Apache - ZCP-13439: umlauts broken with 7.1.13 RC1 - ZCP-13424: zarafa-server freezes afterECFileAttachment::LoadAttachmentInstance - ZCP-13473: zarafa-dagent cannot deliver all mails - ZCP-13493: zarafa-webaccess.conf is not available for Ubuntu 14.04 You should be able to update to Zarafa 7.1.13 by using something like: yum update --enablerepo=updates-testing 'zarafa*' on all Fedora releases and for Fedora EPEL you should use the following: yum update --enablerepo=epel-testing 'zarafa*' After testing, please add positive or negative karma to the Zarafa packages in Bodhi: https://admin.fedoraproject.org/updates/zarafa And if you should find bugs or issues, please fill a bug report in Red Hat Bugzilla as described here: https://fedoraproject.org/wiki/Zarafa#Bugs Your feedback is very much appreciated. Greetings, Robert

1 0

CVE-2015-3436: Overwrite arbitrary files in filesystem at Zarafa
by Robert Scheck 18 May '15

18 May '15

Good evening, Guido Günther detected and reported that replacing /tmp/zarafa-upgrade-lock by a symlink makes the zarafa-server process following that symlink and thus allows to overwrite arbitrary files in the filesystem (assuming that zarafa-server runs as root which is not case by default at Fedora/EPEL, but upstream default). One just needs write permissions in /tmp and wait until the zarafa-server is restarted. CVE-2015-3436 was assigned for this flaw. Updated RPM packages of Zarafa with a backport of the patch (from Zarafa 7.2.1 beta 1) have been submitted to updates-testing for Fedora EPEL 5, 6 and 7, Fedora 20 and 21. You should be able to update to Zarafa 7.1.12 (re-released) by using something like: yum update --enablerepo=updates-testing 'zarafa*' on all Fedora releases and for Fedora EPEL you should use the following: yum update --enablerepo=epel-testing 'zarafa*' After testing, please add positive or negative karma to the Zarafa packages in Bodhi: https://admin.fedoraproject.org/updates/zarafa And if you should find bugs or issues, please fill a bug report in Red Hat Bugzilla as described here: https://fedoraproject.org/wiki/Zarafa#Bugs Your feedback is very much appreciated. Greetings, Robert

1 0

Zarafa 7.1.12 has been submitted to updates-testing
by Robert Scheck 07 Apr '15

07 Apr '15

Good evening, Zarafa 7.1.12 has been submitted to updates-testing (Fedora EPEL 5, 6 and 7, Fedora 20 and 21). Here is the full list of changes in Zarafa 7.1.12 [48726]: Zarafa Collaboration Platform 7.1.12 final [48726] ================================================== - ZCP-10149: Include Documentation hint for usage of NFS and -o nolock option - ZCP-10233: Zarafa-mr-accept script complains in certain cases about php timezone functions - ZCP-10578: missing prerequisites for the reverse proxy in the administrator manual - ZCP-10639: Incorrect message when trying to add an archive - ZCP-10919: a remote admin in multi tenant mode cannot resolve users - ZCP-11061: Bandwidth requirement documentation - ZCP-11413: Monitor complains on unused config options. - ZCP-11418: Compat features do not work with outlook 2010 and windows 8 - ZCP-11468: Document for a user who wants to use webapp, but is experiencing problems by using an unsupported browser, an easier area to locate the list of supported browsers - ZCP-11664: Remove "you" wording from the WebApp User Manual - ZCP-11713: Japanese e-mail breaks the body text - ZCP-11744: zarafa-restore error in documentation - ZCP-11786: zarafa-ws is trying to put files in /usr/share/doc/zarafa - ZCP-11869: Documentation is not clear about Multitenant Public Folder attribute - ZCP-11929: differences between "Managing tenant (company) spaces" and zarafa-admin - ZCP-11931: Outlook Client: synchronisation of an offline profile makes zarafa-server unresponsive - ZCP-11937: Setting out of office for the first time sets language to Catalan - ZCP-11949: Update documentation to stress that one server must have one database. - ZCP-12081: AB Provider UID is defined multiple times and may cause the server to read invalid memory - ZCP-12110: Segfault zarafa-server 7.1.8 R1 - ZCP-12257: include location of the ads plugin in the manual - ZCP-12371: Add additional LDAP logging when using extended log level - ZCP-12409: zarafa-search crashes with ssl - ZCP-12424: Dagent in LMTP mode violates RFC5321 - ZCP-12461: ECDatabaseMySQL defined twice - ZCP-12488: storing attachments in files on disk is not optimal implemented - ZCP-12491: Last date of a serial MR is ignored - ZCP-12492: Private mails sent from Exchange are not marked private. - ZCP-12501: Component documentation - ZCP-12534: Sending a mail to a group: The receivers do not see the group correctly. - ZCP-12549: remove mail subject from spooler.log - ZCP-12550: Zarafa-hidden does not work for cached outlook in ZCP 7.1.10 - ZCP-12566: gsoap code gets our license attached in community distribution of zcp - ZCP-12568: ldap_uri slows down webapp and server after switching the LDAP-Server - ZCP-12574: meeting request copy to delegate - german umlauts broken - ZCP-12592: Update unsecure swfupload.swf - ZCP-12596: senddocument.php allows unauthorized upload of files - ZCP-12597: OL2013 15.0.4641.1001 shows private appointments - ZCP-12600: Sync seems to fail for larger objects - ZCP-12608: Compatibility package does not install correctly with OEM version of Outlook 2013 in every case - ZCP-12611: Cannot move appointment to different calendar - ZCP-12618: Move temporary patch definitions file to systemwide central location - ZCP-12629: zarafa-server binary does not check for existence of sockets and pids when started manually - ZCP-12657: Optimization of dagent incoming e-mail processing - ZCP-12660: Change runlevel of zarafa-licensed to start before zarafa-server - ZCP-12671: Add new OL2013 version 15.0.4659.1000 client to compatibility component - ZCP-12676: IMAP Failed to read line: Interrupted system call - ZCP-12692: Stores should not be orphaned when user_safe_mode is active, even if they are back when correcting backend - ZCP-12696: SMTP RFC store violation - ZCP-12698: compile fail with recent g++ (4.9) - ZCP-12716: mails send with x-mailer "CDO for windows 2000" loses attachments. - ZCP-12720: SMTP RFC store violation - ZCP-12754: Document that its a bad idea to switch the connection type inside a profile - ZCP-12755: Add new OL2013 version 15.0.4667.1000 client to compatibility component - ZCP-12762: remove userquota_soft_template & userquota_hard_template from documentation - ZCP-12766: zarafa-mailbox-permissions doesn't remove rules for --remove-all-permissions - ZCP-12788: Updating the name of a non-active user will change it to a active user - ZCP-12790: Message with attachments converted from uuencoded to attachments with uudecode.py - ZCP-12791: zarafa-server crashing due to ldap.cfg error - ZCP-12801: Attachments aren't written into the database - ZCP-12824: zarafa server still logs indexer instead of search. - ZCP-12845: storing attachments in files on disk is not optimal implemented - ZCP-12847: Change changelog author for debian/rhel packages - ZCP-12850: ECDatabaseMySQL defined twice - ZCP-12851: zarafa-gateway: NOOP returns with wrong return code - ZCP-12852: Reading an encypted or signed email will change the receive date of the email to server time - ZCP-12865: zarafa-gateway.cfg man page missing description of imap_max_fail_commands. - ZCP-12877: meeting request copy to delegate - german umlauts broken - ZCP-12889: Segfault zarafa-server 7.1.8 R1 - ZCP-12892: Last date of a serial MR is ignored - ZCP-12898: zarafa-webaccess no login after update to 7.1.10 on Ubuntu 10.04 - ZCP-12901: mails send with x-mailer "CDO for windows 2000" loses attachments. - ZCP-12908: zarafa-server crashing due to ldap.cfg error - ZCP-12910: Monitor complains on unused config options. - ZCP-12914: Add comment in monitor.cfg for companyquota_warning_template - ZCP-12918: zarafa spooler queues mails forever if smtpd rejects the mail - ZCP-12920: As a user I want to be able to sort the global addresses book by Chinese character - ZCP-12921: Chinese character broken once received - ZCP-12922: remove userquota_soft_template & userquota_hard_template from documentation - ZCP-12923: Building from source fails when xmlto / libical / bison is missing - ZCP-12926: ECChannel::HrSelect doesn't handle EINTR as it should - ZCP-12930: zarafa-dagent segfault when deliver special mail - ZCP-12934: When reporting this traceback, please include Linux distribution name, system architecture and Zarafa version. - ZCP-12944: another chinese decode issue - ZCP-12945: Add new OL2013 version 15.0.4675.1003 client to compatibility component - ZCP-12949: Update documentation for unsupported Oracle Packages - ZCP-12950: zarafa-dagent segfault when deliver special mail - ZCP-12968: ECChannel::HrSelect doesn't handle EINTR as it should - ZCP-12994: Disabling imap on a pop3 users breaks certain mail. - ZCP-12995: Example command given in "Out of office management" is incomplete - ZCP-13015: add SSL settings for zcp 7.1 - ZCP-13019: Update documentation for Debian language pack installation - ZCP-13020: zarafa-admin tool mismatch password gives wrong notification - ZCP-13024: allowed to create SYSTEM user - ZCP-13026: Add new OL2013 version 15.0.4693.1000 client to compatibility component - ZCP-13030: Add new OL2010 version 14.0.7143.5000 client to compatibility component - ZCP-13035: Rather use SSLCERT_FILE & SSLCERT_PASS when setting up SSO for WebApp/WebAccess - ZCP-13039: Add comment in monitor.cfg for companyquota_warning_template - ZCP-13046: Improve z-push documentation in admin manual - ZCP-13047: man page zarafa-admin --hook-store --copyto-public could use some extra information - ZCP-13055: Zarafa outlook client 7.1.11-48011 does not work well with zarafa auto updater - ZCP-13060: zarafa server still logs indexer instead of search. - ZCP-13061: Sync seems to fail for larger objects - ZCP-13062: Merge the compatibility package installation into the MSI typical install mode - ZCP-13082: patch: wrong charset in HTML - ZCP-13120: Add new OL2013 version 15.0.4701.1000 client to compatibility component - ZCP-13123: Simplification of installation targets of compat package for manifest and c2r installations - ZCP-13143: Spooler.log gives wrong messages notifications - ZCP-13153: Outlook: answering on a message in 'send items' results in a message with empty Reply-To: header. - ZCP-13154: it would be helpful if phpmapi would produce a logfile - ZCP-13155: WebAccess /etc/zarafa/webaccess/config.php is not a symlink - ZCP-13158: Upgrade OpenSSL to 1.0.1m on Win32 - ZCP-13176: zarafa-server binary does not check for existence of sockets and pids when started manually - ZCP-13177: patch: wrong charset in HTML - ZCP-13179: it would be helpful if phpmapi would produce a logfile - ZCP-13180: Spooler.log gives wrong messages notifications - ZCP-13187: Message with attachments converted from uuencoded to attachments with uudecode.py - ZCP-13190: Setting out of office for the first time sets language to Catalan - ZCP-13191: When reporting this traceback, please include Linux distribution name, system architecture and Zarafa version. - ZCP-13192: Incorrect message when trying to add an archive - ZCP-13194: remove mail subject from spooler.log - ZCP-6294: allowed to create SYSTEM user - ZCP-6443: zarafa-admin tool mismatch password gives wrong notification - ZCP-7085: Updating the name of a non-active user will change it to an active user - ZCP-7296: Extension on the administrator manual You should be able to update to Zarafa 7.1.12 by using something like: yum update --enablerepo=updates-testing 'zarafa*' on all Fedora releases and for Fedora EPEL you should use the following: yum update --enablerepo=epel-testing 'zarafa*' After testing, please add positive or negative karma to the Zarafa packages in Bodhi: https://admin.fedoraproject.org/updates/zarafa And if you should find bugs or issues, please fill a bug report in Red Hat Bugzilla as described here: https://fedoraproject.org/wiki/Zarafa#Bugs Your feedback is very much appreciated. Greetings, Robert

1 0

Future of Zarafa in Fedora and EPEL
by Robert Scheck 24 Mar '15

24 Mar '15

Good evening, since the final release of the Zarafa Collaboration Platform (ZCP) 7.2 about 3 weeks ago, I received multiple e-mails about when the packages in Fedora and EPEL will be updated from latest 7.1.x to 7.2.0. The answer is unfortunately quite simple: Not at all - or at least not by me. With this e-mail I try to answer all questions that arrived regarding the future of Zarafa in Fedora and EPEL. What does that mean exactly for me? As of writing this means for: - Fedora 22 (and newer, including Rawhide): No Zarafa in Fedora at all. - Fedora 21 and 20: Zarafa 7.1.x until the Fedora release is EOL. Fedora 21 will be maintained until 1 month after the release of Fedora 23 [1]. - Fedora EPEL 7, 6 and 5: Zarafa 7.1.x at least until the Fedora 21 release goes EOL. Fedora 21 will be maintained until 1 month after the release of Fedora 23 [1]. In case Zarafa drops the support for the 7.1 series before EOL of Fedora 21 I might do so as well on all Fedora and EPEL branches [2]. It is hard to maintain a huge software like Zarafa if there is no more upstream support. Why don't you want to update Zarafa in Fedora? I finally retired Zarafa in Fedora Rawhide in December 2014 because I simply do not want to maintain the package anymore and nobody else stepped up so far to do this work [3]. I need Zarafa 7.2 because of the "Revamped OpenSSL stack"! If you use the Zarafa packages from Fedora or EPEL, it is already available since October 2014. I wrote that patch in March 2014 and proposed it to Zarafa. Further more only in Fedora and EPEL RPM packages there is ECDHE support (Elliptic curve Diffie-Hellman) for PFS (Perfect Forward Secrecy). This patch is from April 2014 and has not yet been merged into the Zarafa mainline [4] [5]. Which other features or patches did you add to Zarafa in Fedora and EPEL that might go away if I switch to other packages? All of them are listed at the Fedora GIT and can be downloaded there [6], most of them have not yet been merged to the Zarafa mainline. What about the official RPM packages from zarafa.com for RHEL and CentOS? Zarafa announced its new direction in the beginning of 2015 and part of that is that in the future only Zarafa's commercial customers will have access to tested binaries (= RPM packages) [7]. What about Zarafa packages on other distributions? Honestly, I do not know because I am a Fedora contributor. As of writing, I know that Debian is not shipping Zarafa at all [8] and Mageia is shipping it but retired it for the future releases [9] as well. As a Zarafa user, what options do I have? As of writing you could: - Takeover and resurrect the Zarafa package in Fedora. - Compile Zarafa completely from source yourself. - Migrate to another groupware/solution. - Get a commercial customer of Zarafa. - Freeze the state of your system (not recommented for security reasons). Do you want to push me to get a commercial customer of Zarafa or to migrate to another groupware? No. Is it complicated to build RPM packages of Zarafa? It's not rocket science at least. However it is neither easy nor trivial to build high quality RPM packages for a Linux distribution that aims to be the leader in latest of free and open source software. But if you are looking for a challenge, you are welcome to take it! Will you help me if I resurrect the Zarafa package in Fedora? Maybe, but if so, then only up to a certain point. I am not interested in getting the new co-maintainer of the Zarafa package in Fedora, sorry. What are the known issues and/or blockers if I resurrect Zarafa in Fedora? - Zarafa depends on libvmime which needs to be resurrected then as well. The issue here is, that libvmime is under heavy development for years now, has thus unfortunately not really a stable API or ABI. According to my knowledge the last libvmime version that Zarafa works with is upstream GIT b5927243a27b30cad4b303308c953d6a2d48bc0b. Shortly after that commit, upstream broke API and ABI compatibility. A fix isn't impossible but have a look to the history of non-working zarafa-7.1.4-libvmime092.patch [10]. - Zarafa WebAccess switched with the release of Zarafa 7.2 to complementary support [11] and this is about 6 months before socalled end-of-lifecycle milestone [12]. Given that browsers are changing often there might be one or the other issue with latest browsers that might need to be addressed. - Simply switching from Zarafa WebAccess to the Zarafa WebApp doesn't work for Fedora because the WebApp bundles lots and lots of 3rd party software such as at least pear/Services_JSON, pear/XML_Serializer, TinyMCE, Ext JS, BenExile/Dropbox, sabre/dav, JW FLV Player (including a binary flash blob), oauth2-php, pdfbox, Httpful, xmlrpc.inc, timezones.inc, Z-Merge, webodf, script.aculo.us and JSJaC. These libraries etc. would need to be unbundled to match the Fedora packaging guidelines [13], however some of the bundled components seem to be older versions and/or forked. All of these points are not new, mentioned publically [14] and also sent to the upstream developers about 2 years ago. - Zarafa 7.2 requires gSOAP >= 2.8.19 [15] which is currently satisfied by Fedora 22 and later. It is not impossible to update gSOAP on all relevant branches however there is at least an ABI incompatibility (with a soname version bump) between 2.8.17 and 2.8.21 (which simply means that then during the rebase of gSOAP in existing stable branches all other packages depending on gSOAP would have to be rebuilt against the new gSOAP version as well). Unbundling the gSOAP is needed according to Fedora packaging guidelines [13]. - New search-plus of Zarafa 7.2 also bundles at least python-magic [13]. I am really sorry for all Zarafa users at Fedora and EPEL which have to act now in one or the other way, but my lack of interest in Zarafa has multiple reasons. It took me about 12 months to get Zarafa into Fedora, I maintained Zarafa in Fedora with usually the latest version for about 5 years. But I'm not a fan of the Zarafa WebApp which replaces the Zarafa WebAccess sooner or later completely. Given the WebApp isn't a tiny piece of software, I am neither confident nor interested to maintain a software that I do not use. I would be happy if somebody else steps up and does the nice amount of work and continues with Zarafa in Fedora and EPEL. References/links: [1] https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#End_of_Life_.28EOL… [2] http://doc.zarafa.com/trunk/Support_Lifecycle_Policy/en-US/html/_major_rele… [3] https://admin.fedoraproject.org/pkgdb/package/zarafa/timeline [4] http://pkgs.fedoraproject.org/cgit/zarafa.git/tree/zarafa-7.1.10-ssl_protoc… [5] http://pkgs.fedoraproject.org/cgit/zarafa.git/tree/zarafa-7.1.9-ssl_ecdhe.p… [6] http://pkgs.fedoraproject.org/cgit/zarafa.git/tree/?h=f21 [7] http://www.zarafa.com/faq-about-zarafas-new-direction/7 [8] https://wiki.debian.org/Groupware/Giraffe [9] https://bugs.mageia.org/show_bug.cgi?id=14993#c3 [10] http://pkgs.fedoraproject.org/cgit/zarafa.git/diff/zarafa-7.1.4-libvmime092… [11] http://doc.zarafa.com/trunk/Support_Lifecycle_Policy/en-US/html/_support_de… [12] http://doc.zarafa.com/trunk/Support_Lifecycle_Policy/en-US/html/_major_rele… [13] https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries [14] https://lists.fedoraproject.org/pipermail/zarafa/2013-September/000065.html [15] https://forums.zarafa.com/showthread.php?11043-gsoap-installation-not-check… Greetings, Robert -- Fedora Project * Fedora Ambassador * Fedora Mentor * Fedora Packager

1 0

Zarafa Collaboration Platform vs. SSLv3/POODLE vulnerability
by Robert Scheck 15 Oct '14

15 Oct '14

Good evening, the press already wrote about it: Bodo Möller, Thai Duong and Krzysztof Kotowicz from the Google Security Team discovered a design vulnerability in SSLv3 also known as "POODLE". Technical details are e.g. available at https://www.openssl.org/~bodo/ssl-poodle.pdf. In this e-mail I will try to answer some questions that popped up today regarding Zarafa and POODLE. Important: Even the vulnerability seems to only affect HTTPS, it might (!) apply to other protocols/services as well (if an attacker has control over the packets that also contain secret data), thus Zarafa might be affected in the future as well. As of writing Zarafa itself should be not affected through, nevertheless I do not take any responsibility for this statement. Given the most common attack vendor is HTTPS...it makes sense to disable SSLv3 support in the Apache web server configuration in the first step. A second step is to also disable SSLv3 for all Zarafa services (to be safe for the future). Practical details are available at the end of this mail. Disabling SSLv3 support in the Apache web server is easy - but not really for Zarafa: The built-in SSLv3 support in Zarafa can not be turned off using a configuration option. Zarafa supports from SSLv2 up to TLSv1.2 in its daemons and the whole SSL/TLS support can be either completely enabled or completely turned off. The only thing that can be separately disabled is the (weak) SSLv2 support that is fortunately anyway turned off by default. In case you are using separate TLS accelerators/gateways or reverse proxies the SSL/TLS support in Zarafa is usually disabled and configuration changes need to be applied at these TLS accelerators/gateways or reverse proxies. The feature request to have configurable SSL/TLS protocols and ciphers in Zarafa is not that new, I raised it via ZCP-11781 on 2013-09-24. And then I developed exactly such a patch 7 months ago in my free time - and proposed it to Zarafa; see https://jira.zarafa.com/browse/ZCP-11781 for my initial patch and a re-merged version. Unfortunately this patch has not yet been included into any regular Zarafa release (for different reasons) but it is likely included in the upcoming Zarafa 7.2. Nevertheless my patch has one caveat: If you disable SSLv3 for the Zarafa server daemon (in /etc/zarafa/server.cfg) and you are using zarafa-licensed for the (proprietary) Zarafa Outlook Client you will exclude these users as my tests turned out that (as of writing) the Zarafa Outlook Client support SSLv3 only; https://jira.zarafa.com/browse/ZCP-12366 requests some changes. Fortunately the important Zarafa components are Open Source and thus I now simply added my patches to the Fedora packages so that really each Zarafa administrator can decide her-/himself if (s)he wants to disable SSLv3 also in Zarafa or not (and if so for which of the the Zarafa daemons). And thus my patch allows to follow various security recommendations out there that suggest to disable SSLv3 as soon as possible simply for all services. On top of that I added my patch proposal from 2014-04-16 for ECDHE support (Elliptic curve Diffie-Hellman); https://jira.zarafa.com/browse/ZCP-12237 contains the patch proposal itself (not yet part of any Zarafa release). My patched Zarafa packages are available since last night, details are at https://lists.fedoraproject.org/pipermail/zarafa-announce/2014-October/0000… available. If you can not wait to disable SSLv3, get the packages manually from the Fedora buildsystem (linked under "builds" section): - https://admin.fedoraproject.org/updates/zarafa-7.1.11-1.fc21 - https://admin.fedoraproject.org/updates/zarafa-7.1.11-1.fc20 - https://admin.fedoraproject.org/updates/zarafa-7.1.11-1.fc19 - https://admin.fedoraproject.org/updates/zarafa-7.1.11-1.el7 - https://admin.fedoraproject.org/updates/zarafa-7.1.11-1.el6 - https://admin.fedoraproject.org/updates/zarafa-7.1.11-1.el5,php53-mapi-7.1.… Once you updated Zarafa you have to configure the settings you would like to have. Here is a fast walk through with the settings I would use on systems that need to be accessed by multiple users (= different clients), but please do not blame me if these settings are too strong/weak for your specific usecase: In /etc/zarafa/server.cfg change the following settings e.g. to this: server_ssl_protocols = !SSLv2 !SSLv3 server_ssl_ciphers = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA server_ssl_prefer_server_ciphers = yes In /etc/zarafa/gateway.cfg change the following settings e.g. to this: ssl_protocols = !SSLv2 !SSLv3 ssl_ciphers = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA ssl_prefer_server_ciphers = yes In /etc/zarafa/ical.cfg change the following settings e.g. to this: ssl_protocols = !SSLv2 !SSLv3 ssl_ciphers = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA ssl_prefer_server_ciphers = yes In /etc/httpd/conf.d/ssl.conf change the following settings e.g. to this: SSLProtocol all -SSLv2 -SSLv3 SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA SSLHonorCipherOrder on Restart all affected services afterwards and don't forget to test if all clients can still connect. If a client fails you maybe run that client on an old operating system or the client requires ciphers that are questionable or weak (or you maybe just broke your configuration). https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility provides a good set of example ciphers. Above examples are done using "Intermediate compatibility". If you want more security switch ciphers to "Modern compatibility" (or to something even more stronger). How to test if your services support SSLv3 or whether it is disabled? Red Hat provides at https://access.redhat.com/articles/1232123 a small generic detector. Alternatively the following commands are helpful for e-mail related services: - openssl s_client -ssl3 -connect <server>:25 -starttls smtp - openssl s_client -ssl3 -connect <server>:110 -starttls pop3 - openssl s_client -ssl3 -connect <server>:143 -starttls imap - openssl s_client -ssl3 -connect <server>:237 - openssl s_client -ssl3 -connect <server>:443 - openssl s_client -ssl3 -connect <server>:465 - openssl s_client -ssl3 -connect <server>:587 -starttls smtp - openssl s_client -ssl3 -connect <server>:993 - openssl s_client -ssl3 -connect <server>:995 - openssl s_client -ssl3 -connect <server>:8443 In case of any issues, questions or trouble do not hesitate to send a message to the zarafa mailing list. Greetings, Robert

1 0

Zarafa 7.1.11 has been submitted to updates-testing
by Robert Scheck 15 Oct '14

15 Oct '14

Good morning, Zarafa 7.1.11 has been submitted to updates-testing (Fedora EPEL 5, 6 and 7, Fedora 19, 20, 21 and Rawhide). Here is the full list of changes in Zarafa 7.1.11 [46050]: Zarafa Collaboration Platform 7.1.11 final R1 [46050] ===================================================== General ------- This R1 release of the 7.1.11 final release addresses the WebAccess install problem on RPM-based systems and resolves the dependencies problems under Ubuntu 14.04. Backend ------- - ZCP-12472: zarafa-search crashes on ubuntu 14.0.4 LTS - ZCP-12405: zarafa-search do not start on Ubuntu 14.04 - ZCP-12581: config files are being saved as config.cfg.dpkg-new on ubuntu 14.04 - ZCP-12570: install.sh for Ubuntu 14.04 - ZCP-12582: installing webaccess on rhel based systems result in scriptlet failed, exit status 1 Zarafa Collaboration Platform 7.1.11 final [45875] ================================================== General ------- This release brings a few new features while maintaining stability. With this release we address a few segfaults in zarafa-search to match this final release. Backend ------- - ZCP-11809: zarafa-gateway is unable to create RTF text stream - ZCP-11862: zarafa-backup zarafa-restore breaks textfiles - ZCP-11934: Enhance MariaDB support by modifying sql_mode - ZCP-12012: zarafa-server segfaults when running zarafa-stats --system - ZCP-12097: Disposition-Notification-To double colons in middle of line. dagent crashes - ZCP-12110: Segfault zarafa-server 7.1.8 R1 - ZCP-12127: Support for Apache 2.4 - ZCP-12134: Randomly lost e-mail attachments in e-mails - ZCP-12266: [BIG5] Customer requires an option to set the default character encoding of incoming mail when no encoding is set. - ZCP-12269: public folder shows MAPI_E_STORE_FULL when creating new element - ZCP-12272: WebAccess: .htaccess is not marked as a configuration file in rpm - ZCP-12436: jpegPhoto included twice in ldap.propmap.cfg - ZCP-12500: Zarafa stores rfc enforced linebreaks as actual line breaks - ZCP-12511: zarafa-gateway is unable to create RTF text stream - ZCP-12537: ical issue when password contains a colon - ZCP-12547: As a hoster I need a way to reduce the performance impact on LDAP caused by zarafa-licensed. - ZCP-12563: Create configuration setting to indicate if folder owners automatically get full access rights or not - ZCP-12548: zarafa-search segfault You should be able to update to Zarafa 7.1.11 by using something like: yum update --enablerepo=updates-testing 'zarafa*' on all Fedora releases and for Fedora EPEL you should use the following: yum update --enablerepo=epel-testing 'zarafa*' After testing, please add positive or negative karma to the Zarafa packages in Bodhi: https://admin.fedoraproject.org/updates/zarafa And if you should find bugs or issues, please fill a bug report in Red Hat Bugzilla as described here: https://fedoraproject.org/wiki/Zarafa#Bugs Your feedback is very much appreciated. Greetings, Robert

1 0

Hot and greasy: Zarafa 7.1.10 and pam_mapi 0.2.0 for Fedora EPEL 7
by Robert Scheck 07 Jul '14

07 Jul '14

Good evening, earlier today CentOS 7 has been released [1] - congratulations also from my side to all contributors for their hard work! Guess what? Also today Zarafa 7.1.10 has been built [2] for Fedora EPEL 7 (well, a few minutes ago). While looking to Fedora's foundations [3] there is a clear match: First. As far as I know nobody else - even not Zarafa upstream - has released Zarafa RPM packages for Red Hat Enterprise Linux 7 or CentOS 7...grab them as long as they are fresh! ;-) Of course pam_mapi 0.2.0 has been built [4] for Red Hat Enterprise Linux 7 and CentOS 7, too. The packages should reach the repositories tomorrow and are available using yum via Fedora EPEL 7 like this: yum install --enablerepo=epel --enablerepo=epel-testing 'zarafa*' And if you should find bugs or issues, please fill a bug report in Red Hat Bugzilla as described here: http://fedoraproject.org/wiki/Zarafa#Bugs Your feedback is very much appreciated. References: [1] http://lists.centos.org/pipermail/centos-announce/2014-July/020393.html [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=542366 [3] https://fedoraproject.org/wiki/Foundations [4] http://koji.fedoraproject.org/koji/buildinfo?buildID=542377 Greetings, Robert

1 0

pam_mapi 0.2.0 is now supporting Zarafa's feature management
by Robert Scheck 01 Jul '14

01 Jul '14

Good evening, about 2.5 years ago I presented the first public version of pam_mapi. If you don't know pam_mapi, please read my initial introduction e-mail at https://lists.fedoraproject.org/pipermail/zarafa-announce/2011-November/000… Today I am happy to announce pam_mapi 0.2.0 - which is supporting Zarafa's feature management. What does this mean? Since Zarafa 7.0.0 some features can be enabled and disabled on a per-user basis. If e.g. IMAP is disabled for a specific user any IMAP login will fail. More about this can be read in the Zarafa documentation, section "8.7. Zarafa Feature management" at http://doc.zarafa.com/7.1/Administrator_Manual/en-US/html/_FeatureManagemen… This feature management can be now optionally applied to pam_mapi for e.g. SMTP authentication. But so far even if both, IMAP and POP3 were disabled, pam_mapi was still succeeding authentication and thus allowing to relay e-mails. If this is unwished the new argument "service=pop3|imap" can now be added to the PAM configuration file /etc/pam.d/smtp. This requires that either POP3 or IMAP is enabled to pass authentication. Valid values for the "service" argument are values from "disabled_features" in /etc/zarafa/server.cfg. Multiple services can be listed using the pipe character ("|") and behave like a digital logic OR gate. Configuration example for /etc/pam.d/smtp when authenticating only against Zarafa users while the IMAP feature must be enabled in Zarafa: #%PAM-1.0 auth required pam_mapi.so try_first_pass service=imap account required pam_mapi.so More configuration examples are available in the documentation of pam_mapi. Of course pam_mapi still supports Zarafa versions before 7.0.0 - however without feature/service management (and without unicode). The oldest with pam_mapi 0.2.0 tested Zarafa version is 6.20; the release where Zarafa got Open Source. The installation of pam_mapi on Fedora or Red Hat Enterprise Linux can be simply performed via "yum". Note, that for Red Hat Enterprise Linux and derivates like CentOS, the repository Extra Packages for Enterprise Linux (EPEL) has to be enabled: https://fedoraproject.org/wiki/EPEL/FAQ#howtouse yum install -y pam_mapi Until the updated package is available in the repositories, just download it manually from https://admin.fedoraproject.org/updates/search/pam_mapi. More information regarding configuration and possible options can be found in the man page: man pam_mapi In case you need help, you could write an e-mail to the Zarafa mailing list at the Fedora Project on https://lists.fedoraproject.org or you could join the IRC network Freenode on channel #zarafa. And if you should find bugs or issues, please fill a bug report in Red Hat Bugzilla as described here: https://fedoraproject.org/wiki/Zarafa#Bugs Your feedback is very much appreciated. Greetings, Robert

1 0

CVE-2014-0103: Zarafa WebAccess/WebApp store passwords in cleartext on server
by Robert Scheck 29 Jun '14

29 Jun '14

Good evening, some time ago it was discovered that Zarafa's WebAccess and WebApp store session information, including login credentials, on-disk in PHP session files. This session file would contain a user's username and password to Zarafa in cleartext. If Zarafa WebAccess or WebApp was run on a shared hosting site (multiple web sites on the same server), and an administrator of another server, with the ability to upload arbitrary scripts to the server, they could use this to obtain these Zarafa credentials due to both sites being run by the same Apache user, and the PHP session files being owned by the same. In a non-shared hosting environment, or one using something like suEXEC, where the PHP session files are owned by individual users on a per-site basis, this would not be an issue. In that case, only a local user able to read these files (either as root or as the user running the Apache web server) would be able to view the credentials. Zarafa WebAccess 7.1.10 contains a fix for this issue which requires PHP >= 5.3. Red Hat Enterprise Linux 5 (and derivates) provide PHP 5.1 by default - and thus Zarafa WebAccess remains vulnerable on such systems further on. I already proposed a patch to Zarafa to address this also for PHP < 5.3 and this fix might be included in the upcoming Zarafa WebAccess 7.1.11. For Fedora 19, 20, Rawhide and Red Hat Enterprise Linux 6 the best solution is to update to Zarafa 7.1.10 (submitted today to testing repositories); please have a look to my e-mail regarding changelog and how to update best: https://lists.fedoraproject.org/pipermail/zarafa-announce/2014-June/000053.… Zarafa WebApp is still vulnerable to CVE-2014-0103, a fix will be included in the upcoming Zarafa WebApp 1.6 according to upstream. Have a look to Red Hat Bugzilla at https://bugzilla.redhat.com/show_bug.cgi?id=1073618 if you would like to follow up this issue in general and with more details. In case there are any questions regarding this vulnerability feel free to ask them either here on the mailing list or just send me a private e-mail. Same applies of course also for all Zarafa related questions or issues ;-) Greetings, Robert

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

zarafa-announce