Results 1 to 9 of 9

Thread: Horrible security "patching"

  1. #1
    metux is offline Loyal Member
    Join Date
    Feb 2012
    Posts
    81
    Rep Power
    3

    Default Horrible security "patching"

    Hi folks,

    I'm really getting fed up w/ your way of doing security "patches".
    Things like this:

    https://www.zimbra.com/forums/announ...erability.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 :P

    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 ), 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 :P

    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

  2. #2
    phoenix is offline Zimbra Consultant & Moderator
    Join Date
    Sep 2005
    Location
    Vannes, France
    Posts
    23,580
    Rep Power
    57

    Default

    Instead of ranting in the forums you'd be far better providing a well described description and possible solution to the 'problem' in bugzilla, possibly an RFE.
    Regards


    Bill


    Acompli: A new adventure for Co-Founder KevinH.

  3. #3
    bandaram is offline Zimbra Employee
    Join Date
    Aug 2013
    Location
    San Mateo
    Posts
    1
    Rep Power
    2

    Default

    I agree with Bill here. Zimbra being an open source product, we would love to leverage the experience and commitment of the community for the benefit of everyone. Obviously 'metux' has good ideas and passion for improvement, so I would like to work with these ideas if anyone is willing to start a discussion and help with implementation.

  4. #4
    quanah is offline Zimbra Employee
    Join Date
    May 2007
    Location
    Zimbra
    Posts
    1,284
    Rep Power
    10

    Default

    Quanah Gibson-Mount
    Server Architect
    Zimbra, Inc
    --------------------
    Zimbra :: the leader in open source messaging and collaboration

  5. #5
    metux is offline Loyal Member
    Join Date
    Feb 2012
    Posts
    81
    Rep Power
    3

    Default

    Quote Originally Posted by phoenix View Post
    Instead of ranting in the forums you'd be far better providing a well described description and possible solution to the 'problem' in bugzilla, possibly an RFE.
    Also did so quite some time ago.

    There's not much to explain, as it's pretty trivial and obvious:
    in case of such an hotfix case occours, fork off at the latest release, fix the bug, then rebuild and publish that.

    And, of course, for automatic updates (which should be the standard for such immediate hotfixes),
    put the packages into an repo and tell the world it's url, so package manager and usual tools
    like `unattended-upgrades` (which every decent operator activates) will automatically handle
    the security fix upgrade.

    What is so complicated here ?

  6. #6
    quanah is offline Zimbra Employee
    Join Date
    May 2007
    Location
    Zimbra
    Posts
    1,284
    Rep Power
    10

    Default

    As you yourself note, you've already asked this, and it has been answered, in the bug. It's also been answered offline for you in direct email as well. I don't see much point to your posting here other than some need to grandstand. But just in case a 3rd time is a charm:

    The installer is monolithic and ancient (virtually unchanged since about 2005). It's not currently possible with the way it is designed to use repositories. This has already been identified as an issue that needs immediate attention, as noted in https://bugzilla.zimbra.com/show_bug.cgi?id=87788. The plan is to rework the installer as part of the ZCS 8.6 release. One issue using repositories does not address is our clients that have servers with no external internet access. The current installer resolves this by including everything it needs as part of the package. I.e., we are going to likely still need to bundle a "complete" installer vs one that relies on repositories. Either way, you are already quite aware of the fact that Zimbra knows this is an issue, and that Zimbra already has plans to address it. Ranting on the forums does nothing in terms of resolving an already identified issue.

    --Quanah
    Quanah Gibson-Mount
    Server Architect
    Zimbra, Inc
    --------------------
    Zimbra :: the leader in open source messaging and collaboration

  7. #7
    metux is offline Loyal Member
    Join Date
    Feb 2012
    Posts
    81
    Rep Power
    3

    Default

    Quote Originally Posted by quanah View Post
    As you yourself note, you've already asked this, and it has been answered, in the bug.
    Not completely answered.

    But that's not the main issue here. You already have a build system, which creates packages.
    Even it's not yet suited for initial deployment or larger upgrades (like from helix to ironmaiden),
    but certainly enough for such relatively small things.

    In this case, you just had to run a usual rebuild and publish the packages to some repo,
    and point people to it. And at this point you also optionally could even have added your repo url
    and key to the system.

    Having to run the installer on initial deployments and major upgrades, is still acceptable.
    But such security-fixes should really run automatically.

    Instead of writing a script that downloads some tarball and directly unpacks it completely
    outside the package management, you could instead at least have it download upgraded
    .deb/.rpm and install it - this at least would have left the package manager database
    in an consistent state.

    > It's not currently possible with the way it is designed to use repositories.

    Simply put the upgraded .deb's / .rpm's in a repository and point people to it.
    The installer doesn't have much to do with that. (in the case in question, it didn't
    even have to be run)

    After that point, the actual packages can be removed from the installer tarball - the installer
    then just needs to add the repositories, and change certain calls (eg. on Debian, call apt
    instead of dpkg).

    Yet again: I'm currently just talking about upgrades within an major release line.

    The plan is to rework the installer as part of the ZCS 8.6 release.
    So, in several years ? ;-o

    One issue using repositories does not address is our clients that have servers with no external internet access.
    Mirroring package repositories is rather trivial. Can be done w/ some lines of shell script.
    Same for automatically generating an installer tarball that includes the repo mirror.
    (local mirrors aren't that unusual, in fact quite standard for decades, eg. w/ CD installations)

    I.e., we are going to likely still need to bundle a "complete" installer vs one that relies on repositories.
    Pretty trivial, can be automatically generated, pretty easily.

  8. #8
    quanah is offline Zimbra Employee
    Join Date
    May 2007
    Location
    Zimbra
    Posts
    1,284
    Rep Power
    10

    Default

    It would take distributing zimbra-core, which is a massive package full of a million different things. Installing a new version of this on top of an existing install could wreak havoc for customers that apply their own custom patches on top of what Zimbra ships (and there are plenty that do that). It is not a workable solution. Again, the current system is perfect, but it also isolates the the update to what's required without touching large portions of the product unnecessarily.
    Quanah Gibson-Mount
    Server Architect
    Zimbra, Inc
    --------------------
    Zimbra :: the leader in open source messaging and collaboration

  9. #9
    metux is offline Loyal Member
    Join Date
    Feb 2012
    Posts
    81
    Rep Power
    3

    Default

    > It would take distributing zimbra-core, which is a massive package full of a million different things.

    In case of such an security fix, most of these things would remain the same. Where's the problem ?

    > Installing a new version of this on top of an existing install could wreak havoc for customers that
    > apply their own custom patches on top of what Zimbra ships (and there are plenty that do that).

    If course, they'll have to rebase their customizations onto the new version (which in that case
    would be an no-op).

    By the way: we're one of these people doing pretty many core customizations.
    And we have pretty much automatized the whole process. (on minor upgrades, it's just a
    matter of a few minutes manual stuff)

    Oh, and why havent't you split it already in several smaller packages ?
    Even with the horribly broken IronMaiden buildsystem, it's not that difficult (once you've got
    the build system working at all ;-o). You're already building several packages - just add
    add another one ...

    EDIT: with some package manager magic, you could even split it out within an minor
    upgrade - without overwriting the other stuff ...

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Zimbra 8 spam filtering HORRIBLE
    By ditto in forum Administrators
    Replies: 5
    Last Post: 10-24-2012, 12:40 AM
  2. Domino Wizard: Horrible HTML conversion
    By fedya in forum Migration
    Replies: 0
    Last Post: 05-13-2011, 09:59 PM
  3. Horrible Experince - How do I completely remove ZD?
    By rustyw007 in forum General Questions
    Replies: 1
    Last Post: 05-09-2011, 11:04 PM
  4. Pulling/patching 5.0.3
    By Rich Graves in forum Administrators
    Replies: 7
    Last Post: 03-24-2008, 01:10 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •