On ZCS FOSS Source Code releases rewriting history

[adrian.gibanel.btactic]

One of the problems with ZCS FOSS Source code not being released at the same time as its NE counterpart ( as a consequence of the embargo commits) it's that Zimbra have to publish later on those embargo commits.

And, man, they are not doing that as well was I expected.

This is funny because it's about the second time I am about to fix a CVE in my own and they push the embargoed commits making my work almost obsolete.

I have this bad luck on working on those fixes one or two days before they lift the embargo.

Anyways, jokes aside (we prefer the embargoes to be lifted better than anything) this is where our joy ends.

Let's examine the 10.1.10 tag before the embargo lift (it was good luck that I had it snapshotted into one of the maldua-pimbra repos) and 10.1.10 after the embargo lift (be warned this snapshot is from zimbra itself and might be rewritten after this post).

So... some key differences:

- ZCS-16965 Replacing all with Chat keyword is the common ancestor.
- ZCS-16138 to ZCS-16669 commits. Here the history diverges. Old snapshot ones were commited on 2025 04 29. New snapshot ones were commited on 2025 04 30. The ZCS-16138 commit in one snapshot has an specific commit hash, the other snapshot has another commit hash. Same thing with the rest of commits from now on.
- ZCS-17206, ZCS-17098 and ZCS-17246. These are unexpected new commits that only exist in the newer snapshot which were commited on 2025 04 30 date too. Two possible reasons that I can think of. The first reason is that those commits are not supposed to be in 10.1.10 but in a newer tag version. The second reason is that they were supposed to be in 10.1.10 but somehow they forgot to push them the first time. Which one is it?
- ZBUG-4886 to ZCS-17304. Both of these are commited in both old and new snapshot on 2025 06 30 date. Different hashes as you might have expected.
- ZBUG-4911: This is the CVE fix we were expecting. It was commited on 2025 06 30. Thank you. This is only found in the new snapshot.
- ZBUG-4892 and ZCS-15353: Both of these are commited in both old and new snapshot on 2025 07 01 date. Different hashes as you might have expected.

I wonder how many times in the past they have done the same thing and... well... I cannot dive in the ZCS-17206, ZCS-17098 and ZCS-17246 newer commits (not related to any CVE) right now to understand what was going here but I might do it if Zimbra does not explain to us what actually happened in here.

Let me clear it's ok if they rewrite the history of a tag if something is missing but, come on, if common commits like ZCS-16138 to ZCS-16669 commits don't have the same exact hash then it means that they are cherry-picking the same commits over and over more than they should. That's not usually right.

---

Just for you to know... I'm slowly working on a Zimbra Github repos Tracker. Given what happened here I might add it some snapshot capabilities to it so that we don't miss these nuanced changes.

---

If only they had an official way on releasing the FOSS source code only versions. Maybe a zcs-foss-releases repo with suggested tags ready to be used that it's only updated when everything has been put properly in the Github repos.

[adrian.gibanel.btactic]

- ZCS-17206, ZCS-17098 and ZCS-17246. These are unexpected new commits that only exist in the newer snapshot which were commited on 2025 04 30 date too. Two possible reasons that I can think of. The first reason is that those commits are not supposed to be in 10.1.10 but in a newer tag version. The second reason is that they were supposed to be in 10.1.10 but somehow they forgot to push them the first time. Which one is it?

Those commits, which were present previously in 10.1.8 tag are needed so that the build is successful. That's why they added there. So it's the second reason... they forgot to push them there in the first place.

Let me clear it's ok if they rewrite the history of a tag if something is missing but, come on, if common commits like ZCS-16138 to ZCS-16669 commits don't have the same exact hash then it means that they are cherry-picking the same commits over and over more than they should. That's not usually right.

Well, as I have checked right now the 10.1.10 tag they have pushed right now it's much better than the original one because I think it shares as many tags with 10.1.8 tag as it is possible. So... they did the right thing after all. Well, actually checking 10.0.14 and 10.0.16, well, some commits are repeated but with different hashes. They need to improve these bits.

[jered]

I have nothing to really add, other than sharing your frustration.

It is unproductive to simply fork the Zimbra projects and try to maintain this as a community effort -- there is not a large-enough installed base that depends on the ZCS suite but is fine with not getting enterprise-grade support.

Synacor is at least kind enough to continue to maintain public repos, but does not have interest (perhaps legitimately) in building a contributor community.

I wish we could convince them to at least allow some community participation, in the form of being able to interact with issues and make PRs. I use and maintain my install for friends&family as an alternative to the Gmail spyware hegemony, but I definitely can't pay 5-figures yearly for that. But I'd love to fix some fundamental bugs, like the lack of emoji rendering in message bodies...