So... ZCS 10.1.5 has been published by Synacor some weeks ago without releasing their vulnerability fix to the Github repos.
---
We already maintain an OnlyOffice pseudo fork (It's a pseudo fork because not all the repos are cloned, and it's not up to date) with unlimited connections. If you check the public big howto you can learn how to fetch OnlyOffice (upstream) updated branches, fetch bTactic patches, push everything onto your own Github repo and then build onlyOffice binaries from there.
It is based on three points:
Going back to build Zimbra,... I'm not very sure if a new organisation (acme-open-patch) should be created, if we should create repos with suffixes (zm-web-client-acme) (see below on the notes) or if we should go with repos and tags with special suffixes (10.1.5-acme).
In any case you can check GIT_OVERRIDES on config.build.in where you can override for a given repo its remote url, branch and tag. I guess you are supposed to copy config.build.in as config.build so that it's taken onto account.
There might also be an alternate way of doing the same thing from the ./build.pl arguments too.
So I think this is the way forward:
I am busy with other projects so I won't be able to tackle on this in the short term.
Notes:
---
We already maintain an OnlyOffice pseudo fork (It's a pseudo fork because not all the repos are cloned, and it's not up to date) with unlimited connections. If you check the public big howto you can learn how to fetch OnlyOffice (upstream) updated branches, fetch bTactic patches, push everything onto your own Github repo and then build onlyOffice binaries from there.
It is based on three points:
- Reusing some specific commits that are needed for unlimited connections (akin to patch non-public CVEs)
- Hacking the official build system so that some specific packages are fetched from custom Github repos
- Using tags with specific suffixes so that unlimited connections related commits are actually used.
Going back to build Zimbra,... I'm not very sure if a new organisation (acme-open-patch) should be created, if we should create repos with suffixes (zm-web-client-acme) (see below on the notes) or if we should go with repos and tags with special suffixes (10.1.5-acme).
In any case you can check GIT_OVERRIDES on config.build.in where you can override for a given repo its remote url, branch and tag. I guess you are supposed to copy config.build.in as config.build so that it's taken onto account.
There might also be an alternate way of doing the same thing from the ./build.pl arguments too.
So I think this is the way forward:
- Maintain our own forks of Zimbra repos with our own crafted vulnerability fixes.
- Create branches or tags each a time a new release is published with the crafted-vulnerability fixes being cherry-pick on the top.
- Publish documentation on how to build Zimbra with all of the above applied.
I am busy with other projects so I won't be able to tackle on this in the short term.
Notes:
- This is not about having an equivalent to the zimbra-patch package .
- Zimbra has recently implemented an improvement to zm-build itself so that you can have a common suffix to the modified repos. E.g. zm-web-client-acme.
Statistics: Posted by adrian.gibanel.btactic — Tue Mar 11, 2025 1:08 pm