I'm really getting fed up w/ your way of doing security "patches".
Things like this:
We">https://www.zimbra.com/forums/announcem ... ility.html
We already had the same mess w/ the heartbleed fix. A script which downloads some tarball and replaces individual files,
completely outside the package manager, so defeating the whole purpose of package management.
First of all, that script is totally insecure. Okay, you've now learned to use https instead, but w/ explicitly switching off
certificate check, this becomes nothing but a bad joke. Oh, and why that md5 file ? I hope you dont think it should
give you more security, because it does NOT.
You really wanna invite the NSA to abuse your "patching" for injecting backdoors ?!
And now for the approach of replacing single files, instead of just shipping new packages:
Do you understand what the concept of package management it is meant for ? Because I really doubt that
Package management isn't just a fancy way for transporting bundles of files to some target system, it is
the *CORE* of software deployment on modern *nix platforms, which operators use all the day.. The main
purpose is CONSISTENCY and easy tracking of installed files and package versions (of course, including
_fully automatic_ checking for available packages and updates, downloads, signature checking, deployment,
and removal, etc).
And it also adds another - fully automatic - security layer, as the package manager checks package signatures
against the repo and validates the repo against the authorized keys. If done correctly (which is pretty easy),
it automatically makes sure that only properly authenticated packages are installed (assuming you've told
it to trust the repo in question).
Another _vital_ aspect:
Operators usually don't have the time for reading tons upgade notifications on a daily basis and run upgrades
for dozens of packages on each single machine manually. That's what we have distros for (and for professional
commercial software, we just expect the vendor to do his homework properly!). And when it comes to security
fixes, that's what mechanisms like 'unattended-upgrades' are for, which deploy security fixes fully-automatically,
w/o having to wait for an operator to trigger the upgrade manually.
This is a pretty typical problem of many commercial vendors (also seen it at a lot of my clients - many even don't
know how to write proper Makefiles or use a decent SCM): they might produce pretty good software, but
deployment tends to be a total mess.
This mess is getting worse and worse over the years (well, I'm pretty curious how the situation becomes w/ JP,
haven't got access to the source for a review yet ...), and it _really_ should be cleaned up soon, otherwise I
see even more people switching to other (really opensource!) solutions like Kolab !
I can understand that such fundamental infrastructure things don't easily fit into product plans, and hilevel
decision makes usually don't know anything about that. But these things are really importan for stability
as well as TCO. It's like trying to build a skyscraper on thin sand ... either it's extremly expensive or it
will fall apart sooner or later ... ;-o
In case you're lacking proper resources (which is my _strong_ impression for years now), don't hesistate
to call me. I can arrange a whole team w/ very deep Zimbra knowledge (we're probably the ones who
do the deepest / most complex Zimbra customizations in whole Europe, if not world wide). Besides the
architect, who eg. developed zmpkg (which would by myself :p), we have a whole team of very
Zimbra-experienced developers, several system integrators / operators, lots of testers, etc - everything
that's needed to roll the whole show on our own
After all these years, I still belive that Zimbra has great potential, but it needs a change in development
management approaches. The mentioned deployment issues is just one part, the lack of a _real_
OSS community is another one (I guess, I already mentioned the problems w/ your SCM infrastructure
and workflows, which is really expensive ;-o)
cu
