[RFE] Synacor Zimbra Source Code Only versions announcements

[adrian.gibanel.btactic]

When a new Zimbra NE version is released as a binary, a Zimbra FOSS equivalent version is released as source code in their Github repos.

The Zimbra NE version binary releases are available as the initial installation tgz and its associated Debian/RPM repo packages.

These Zimbra FOSS source code release:

• can happen days prior to the Zimbra NE binary release.
• can happen days after the Zimbra NE binary release.

We have had examples of both scenarios happening.

This thread is an invitation to Synacor to:

• either announce those new source code only versions here whenever they are ready.
• or specify what's the current behaviour/policy which we can rely on. Example: If a NE release is announced you can rely on the FOSS tags being published on Github one day prior to the announcement.

The most recent examples are these ones:

Zimbra NE 10.1.3 has been made public on November 12, 2024.
Has its associated FOSS source code been fully pushed with its appropriate tag to the Github repos?

Zimbra NE 10.0.11 has been made public on November 12, 2024.
Has its associated FOSS source code been fully pushed with its appropriate tag to the Github repos?

Thank you!

[adrian.gibanel.btactic]

Given that ZCS 10.1.8 and ZCS 10.1.9 are causing confusion regarding what ends up in Github repos or not and also given that I have had enough of waiting for any kind of feedback in this thread, well,...

Here there is: Zimbra Foss Source Code Only Releases wiki page.

Now we can update the actual status of the Zimbra Foss source code only releases instead of relying on random interpretations here on the forum regarding what tags end up or not in the Github repos.

Also... if you think some other relevant data, such as the CVEs that are embargoed, needs to be added there... well... go ahead and improve the page.

[BradC]

I composed a long a detailed response, but it got eaten with a 500 Bad Gateway.

I wouldn't expect any interaction from Zimbra on this. It would appear they purged the people who actually had an interest in the forum and community last year. Note pretty much any developer interaction is limited to one liners that then ghost the thread as soon as it's determined there isn't an NE customer involved.

Last year you'd have had a response explaining the timing of the embargo even if you didn't like the answer. This year it's radio silence. I'm starting to think Synacor believe if they ignore us long enough we'll all go away.

[adrian.gibanel.btactic]

So... what happened recently is quite peculiar.

10.1.9 security fixes have been lifted but not 10.1.8 security fixes (check linked thread for a workaround).

So... as ZCS NE 10.1.8 security fixes are included in ZCS NE 10.1.9 security fixes... this means that the embargo is not actually lifted for any of the two.
So... not going to say that the embargo was lifted for 10.1.9 in the wiki page.

[adrian.gibanel.btactic]

As a companion to the Zimbra Foss Source Code Only Releases wiki page I have created the:

Zimbra Foss CVE Commits wiki page

where we can track the NE security fixes and their counterparts in FOSS commits.

That way it's much easier to track if an embargo has ended or not.

[JDunphy]

Zimbra Foss CVE Commits wiki page

where we can track the NE security fixes and their counterparts in FOSS commits.

That is awesome!

[adrian.gibanel.btactic]

Here there is: Zimbra Foss Source Code Only Releases wiki page.

Now we can update the actual status of the Zimbra Foss source code only releases instead of relying on random interpretations here on the forum regarding what tags end up or not in the Github repos.

Given that ZCS NE 10.1.11 and ZCS NE 10.0.17 seem to only have NE changes I have added a new Status value: Ne only so that we can also keep track of them even if they are not FOSS releases in any way.

[JDunphy]

Here there is: Zimbra Foss Source Code Only Releases wiki page.

I am thinking of incorporating what tags are safe to build... I had claude code generate the bash function and I supplied the algorithm.

Code: Select all

% ./can-build-zimbra.sh 
Usage:
  ./can-build-zimbra.sh <version>

Examples:
  ./can-build-zimbra.sh 10.1.7
  ./can-build-zimbra.sh 10.1.15
  ./can-build-zimbra.sh 9.0.0.p46
%  ./can-build-zimbra.sh 10.1.7
✅ YES — '10.1.7' CAN be built.
%  ./can-build-zimbra.sh 10.1.15
❌ NO — '10.1.15' is still embargoed (last column = N/A).

It is keying off of your zimbra wiki page above.

Ref: https://raw.githubusercontent.com/JimDu ... -zimbra.sh

It's getting silly how hard it is becoming to build zimbra or deploy new versions into a working environment without causing some breakage so was thinking of add this functionality as a warning given build_zimbra.sh already will verify versions (thanks Vincent).

Jim

[adrian.gibanel.btactic]

It's getting silly how hard it is becoming to build zimbra or deploy new versions into a working environment without causing some breakage so was thinking of add this functionality as a warning given build_zimbra.sh already will verify versions (thanks Vincent).

Jim

You are right. Right now you can build 10.1.10 (or any other lower versions) but then when you install it you won't be able to use it.

Regarding your implementation it's interesting on how you check for the latest column for 'N/A' instead of checking for 'Released' in the Status column. I guess it's equivalent.