[Users] Last security patch

[L Mark Stone]

As regards ehcache,  I had a Support Case open with Zimbra on this, and it was recommend to increase the ehcache size.

This is what I have now:


zimbra at my:~$ zmprov gacf | grep -i ehcach

zimbraActiveSyncEhcacheExpiration: 5m

zimbraActiveSyncEhcacheHeapSize: 10485760

zimbraActiveSyncEhcacheMaxDiskSize: 10737418240

zimbraImapActiveSessionEhcacheMaxDiskSize: 107374182400

zimbraImapInactiveSessionEhcacheMaxDiskSize: 107374182400

zimbraImapInactiveSessionEhcacheSize: 1048576

zimbra at my:~$

Hope that helps,
Mark

_________________________________________________

Another Message From...   L. Mark Stone


________________________________
From: Victor d'Agostino <d.agostino.victor at gmail.com>
Sent: Tuesday, March 19, 2019 9:36 AM
To: David Touitou
Cc: L Mark Stone; users; Info Zeta Alliance
Subject: Re: [Users] Last security patch

Hello again

Security apart the article lets suppose a zimbraMemcachedClientServerList empty attribute is always safer, but IMAP performance could be better with it because the zimbra store would use the memcached service for IMAP protocol instead of EhCache.

The official Zimbra guide says :
zimbraMemcachedClientServerList : list of host:port for memcached servers; set to empty value to disable the use of memcached

I also have an empty attribute on my Zimbra 8.8.8 multi-store environment. If I have I/O performance issues on my zimbra stores, should I set the zimbraMemcachedClientServerList server attribute or let it empty ?

Why does the memcached service is better than EhCache which is memory based ?

Regards,
Victor



Cordialement,
Victor d'Agostino


Le mar. 19 mars 2019 à 14:30, David Touitou <david at network-studio.com<mailto:david at network-studio.com>> a écrit :

> Thanks David; it wasn't clear to me that the author was saying in the last
> section that all these exposures had been fixed.

I might be wrong.
But considereing there are attributed CVE numbers and patches, it looks to me as standard procedure:
 . vulnerability discovered and embargoed
 . software company contacted
 . software company acknowledged the vulnerability
 . software company issued patch
 . a couple days later, vulnerability went public with explanations

David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zetalliance.org/pipermail/users_lists.zetalliance.org/attachments/20190319/64c70e4f/attachment.html>