I used to feel exactly like what you have articulated about the build process when 9.0 FOSS binaries were no longer provided. It appeared complicated and coupled with bad documentation that made building a source release feel more like trial and error than reproducible at times. That changed when Adrian came up with some helper scripts to generate the Maldua builds. Previous to that, we had Ian's build script that would generate a build from the current branch in github. Both of them then produced binaries for those that didn't want to build their own releases from source code. A major concern I had and I believe they also had was that we have had companies jump in and claim they will support the FOSS builds and then it was silence and they never seem to share the build process they used.
Having said that, Zimbra/Synacor since version 10 has attempted to tag the repositories in a sane fashion in contrast to version 8.8.15 and 9.0 for build releases and also updates the github README.md file with the syntax and tags needed to build by tags.
A quick note on the tags... there are approx 54+ repositories and the build.pl script that runs everything will attempt the highest numbered tag (--git-default-tag) and if that doesn't exist, use the next highest, etc. Here is an example:That script above will go through all the repositories and determine the best zm-build.git repository (tools to build a release) to use AND generate a list of the tags required for the latest version 10.1
Here is another example building a specific version 10.1.0Notice that the list of tags has changed but also the zm-build.git branch to checkout has changed. Tools like this can validate what the zm-build.git documentation says for building releases. If you leave off the --dry-run then it will build a tarball.
In other words, we have tools that can generate reproducible FOSS builds. We have at least 2 builders that are providing full binaries and have documented how they build their binaries. This uncertainty of building FOSS was a major reason I wanted to understand the build process and ended up with this build_zimbra.sh script to verify that FOSS wasn't dead. I also documented this in the wiki page below. One other piece of the puzzle is that Zimbra still provides the repositories for the 3rd party open source binaries (nginx,ldap, etc) meaning that most if not all of the FOSS binaries and builds will use these when you execute install.sh to install or update your FOSS zimbra.
Having said that, I still and have always used the network version in production so the above script while it works and generates FOSS tarballs are not production builds I use. They are on test machines and is my canary in the coal mine to know if something drastically changes within Zimbra.
Your point of verification of the security patches for FOSS is valid. It would seem like any tool we come up with could be abused by bad actors.
Ref: https://wiki.zimbra.com/wiki/JDunphy-Co ... mbraScript
Having said that, Zimbra/Synacor since version 10 has attempted to tag the repositories in a sane fashion in contrast to version 8.8.15 and 9.0 for build releases and also updates the github README.md file with the syntax and tags needed to build by tags.
A quick note on the tags... there are approx 54+ repositories and the build.pl script that runs everything will attempt the highest numbered tag (--git-default-tag) and if that doesn't exist, use the next highest, etc. Here is an example:
Code:
% ./build_zimbra.sh --dry-run --version 10.1#!/bin/shgit clone --depth 1 --branch "10.1.1" "git@github.com:Zimbra/zm-build.git"cd zm-buildENV_CACHE_CLEAR_FLAG=true ./build.pl --ant-options -DskipTests=true --git-default-tag="10.1.2,10.1.1,10.1.0" --build-release-no="10.1.2" --build-type=FOSS --build-release="DAFFODIL_T100102C100101FOSS" --build-thirdparty-server=files.zimbra.com --no-interactive --build-release-candidate=GAHere is another example building a specific version 10.1.0
Code:
% /build_zimbra.sh --dry-run --version 10.1.0#!/bin/shgit clone --depth 1 --branch "10.1.0" "git@github.com:Zimbra/zm-build.git"cd zm-buildENV_CACHE_CLEAR_FLAG=true ./build.pl --ant-options -DskipTests=true --git-default-tag="10.1.0" --build-release-no="10.1.0" --build-type=FOSS --build-release="DAFFODIL_T100100C100100FOSS" --build-thirdparty-server=files.zimbra.com --no-interactive --build-release-candidate=GAIn other words, we have tools that can generate reproducible FOSS builds. We have at least 2 builders that are providing full binaries and have documented how they build their binaries. This uncertainty of building FOSS was a major reason I wanted to understand the build process and ended up with this build_zimbra.sh script to verify that FOSS wasn't dead. I also documented this in the wiki page below. One other piece of the puzzle is that Zimbra still provides the repositories for the 3rd party open source binaries (nginx,ldap, etc) meaning that most if not all of the FOSS binaries and builds will use these when you execute install.sh to install or update your FOSS zimbra.
Having said that, I still and have always used the network version in production so the above script while it works and generates FOSS tarballs are not production builds I use. They are on test machines and is my canary in the coal mine to know if something drastically changes within Zimbra.
Your point of verification of the security patches for FOSS is valid. It would seem like any tool we come up with could be abused by bad actors.
Ref: https://wiki.zimbra.com/wiki/JDunphy-Co ... mbraScript
Statistics: Posted by JDunphy — Thu Oct 10, 2024 2:27 pm