Maldua's Pimbra - Patched Zimbra

[adrian.gibanel.btactic]

What is Pimbra?

Just a short way of saying patched Zimbra.

It's also a Github organisation that helps Zimbra builders to apply community based patches which are not found in the upstream repos in a timely manner.
For now it's only one repo: zm-web-client.

Maldua builds will be using those patches.

Usage example

Code: Select all

mkdir installer-build
cd installer-build
git clone --depth 1 --branch 10.1.5 git@github.com:Zimbra/zm-build.git
cd zm-build
# Use the version you want to build (Example: 10.1.5) in the new line
wget 'https://github.com/maldua-pimbra/maldua-pimbra-config/raw/refs/tags/10.1.5/config.build' -O config.build_pimbra
# If download fails check Issues to either complain or check if the new tag is actually not needed.
cat config.build_pimbra >> config.build
# Other of your changes (Optional)
# Your ./build.pl command

Just in case you're curious here's how the 10.1.5 config.build file contents look like:

Code: Select all

# Pimbra patches - BEGIN

## Pimbra org
%GIT_OVERRIDES          = maldua-pimbra.url-prefix=https://github.com/maldua-pimbra

## zm-web-client
### CVE-2025-27915 fix
%GIT_OVERRIDES          = zm-web-client.remote=maldua-pimbra
%GIT_OVERRIDES          = zm-web-client.tag=10.1.5-maldua

# Pimbra patches - END

Updates
Yes, each time a new Zimbra version is released new tags will need to be pushed to the patched repos and to the maldua-pimbra-config repo.

Is it overkill?
If you think this is overkill and you are only worried about the most recent CVE from January 2025 you can check: FOSS - How to patch/build source to include missing commits for 10.1.5/6 thread for a more simple method.

Feedback
The project is quite new so expect some bug or another. And, please report them either here or in the maldua-pimbra issues page.

Thank you!

Resources

• maldua-pimbra organisation
• Main maldua-pimbra repo
• maldua-pimbra-config repo with ready to use config.build files.

[JDunphy]

Trying to wrap my head around all this. I did this:

Code: Select all

#!/bin/sh
git clone --depth 1 --branch "9.0.0.p44" "git@github.com:Zimbra/zm-build.git"
cd zm-build

ENV_CACHE_CLEAR_FLAG=true ./build.pl \
  --ant-options -DskipTests=true \
  --git-default-tag="9.0.0.p43,9.0.0.p42,9.0.0.p41,9.0.0.p40,9.0.0.p39,9.0.0.p38,9.0.0.p37,9.0.0.p36,9.0.0.p34,9.0.0.p33,9.0.0.P33,9.0.0.p32.1,9.0.0.p32,9.0.0.p30,9.0.0.p29,9.0.0.p28,9.0.0.p27,9.0.0.p26,9.0.0.p25,9.0.0.p24.1,9.0.0.p24,9.0.0.p23,9.0.0.p22,9.0.0.p21,9.0.0.p20,9.0.0.p19,9.0.0.p18,9.0.0.p17,9.0.0.p16,9.0.0.p15,9.0.0.p14,9.0.0.p13,9.0.0.p12,9.0.0.p11,9.0.0.p10,9.0.0.p9,9.0.0.p8,9.0.0.p7,9.0.0.p6,9.0.0.p5,9.0.0.p4,9.0.0.p3,9.0.0.p2,9.0.0.p1,9.0.0" \
  --build-release-no="9.0.0" \
  --build-type=FOSS \
  --build-release="KEPLER_T090000p43C090000p44FOSS" \
  --build-thirdparty-server=files.zimbra.com \
  --no-interactive \
  --build-release-candidate=GA \
  --git-overrides maldua-pimbra.url-prefix="git@github.com:maldua-pimbra" \
  --git-overrides zm-web-client.remote="maldua-pimbra" \
  --git-overrides zm-web-client.tag="9.0.0.p44-maldua"

which built perfectly. Double checking what zm-web-client tag was used in the build:

Code: Select all

% cd zm-web-client
% git tag
9.0.0.p44-maldua

Seems like magic! I can see a lot of future functionality in this.

Now I need to incorporate this into ./build_zimbra.sh

Thank you for this!

Jim

[JDunphy]

Thinking out loud here as it's still not clear to me what is going on. Currently we have this:

Assume building the latest version so that would be tags: 10.1.6, 10.0.13, and 9.0.0.13.p43

If they choose to build 10.1 then the tag on pimbra's zm-web-client.git is 10.1.5-maldua (so look behind one for correct maldua tag)
if they choose to build 10.0 then the tag on pimbra's zm-web-client.git is 10.0.13-maldua (perfect)
if they choose to build 9.0 then the tag on pimbra's zm-web-client.git is 9.0.0.p44-maldua (look ahead one for tag for correct maldua tag)

I see that you have 10.1.6 config but there is no tag for the repository for 10.1.6-maldua. Can you give some guidance as I am attempting to come up with an algorithm given a version which represents the tag to build for the correct pimbra tag. If I understand what you are presenting, we will be able to build older versions also from this day forward.

Are we viewing this as a superset of the latest tag that represents the version to build ... meaning:

if the latest tag for a tag|version to build is 9.0.0.p43 then the superset is 9.0.0.p43-maldua
if the latest tag for a tag|version to build is 10.0.13 then the superset is 10.0.13-maldua (you have this)
if the latest tag for a tag|version to build is 10.1.6 then the superset is 10.1.6-maldua

So adding tags for 9.0.0.p43-maldua and 10.1.6-maldua to zm-web-client would fix this.

Where latest tag is from here:
--git-default-tag="10.1.6,10.1.5,10.1.4,10.1.3,10.1.2,10.1.1,10.1.0"

Would this work or were you trying to do something else?

Jim

[adrian.gibanel.btactic]

Trying to wrap my head around all this. I did this:

Code: Select all

#!/bin/sh
git clone --depth 1 --branch "9.0.0.p44" "git@github.com:Zimbra/zm-build.git"
cd zm-build

ENV_CACHE_CLEAR_FLAG=true ./build.pl \
  --ant-options -DskipTests=true \
  --git-default-tag="9.0.0.p43,9.0.0.p42,9.0.0.p41,9.0.0.p40,9.0.0.p39,9.0.0.p38,9.0.0.p37,9.0.0.p36,9.0.0.p34,9.0.0.p33,9.0.0.P33,9.0.0.p32.1,9.0.0.p32,9.0.0.p30,9.0.0.p29,9.0.0.p28,9.0.0.p27,9.0.0.p26,9.0.0.p25,9.0.0.p24.1,9.0.0.p24,9.0.0.p23,9.0.0.p22,9.0.0.p21,9.0.0.p20,9.0.0.p19,9.0.0.p18,9.0.0.p17,9.0.0.p16,9.0.0.p15,9.0.0.p14,9.0.0.p13,9.0.0.p12,9.0.0.p11,9.0.0.p10,9.0.0.p9,9.0.0.p8,9.0.0.p7,9.0.0.p6,9.0.0.p5,9.0.0.p4,9.0.0.p3,9.0.0.p2,9.0.0.p1,9.0.0" \
  --build-release-no="9.0.0" \
  --build-type=FOSS \
  --build-release="KEPLER_T090000p43C090000p44FOSS" \
  --build-thirdparty-server=files.zimbra.com \
  --no-interactive \
  --build-release-candidate=GA \
  --git-overrides maldua-pimbra.url-prefix="git@github.com:maldua-pimbra" \
  --git-overrides zm-web-client.remote="maldua-pimbra" \
  --git-overrides zm-web-client.tag="9.0.0.p44-maldua"

which built perfectly.

I initially thought of using --git-overrides in the command line but later on I discarded it.
The problem regarding using --git-overrides is that you have to maintain it each time there is a new release.
If only there was a way of adding additional build customization to the command line customization... wait... that's what config.build is meant for.
If config.build config choices are different than the command line config choices the command line config choices are not ignored or overwritten.
More on that later.

Thinking out loud here as it's still not clear to me what is going on. Currently we have this:

Assume building the latest version so that would be tags: 10.1.6, 10.0.13, and 9.0.0.13.p43

This seems like a typo and you actually meant 10.1.6, 10.0.13, and 9.0.0.p43. I'll quote you again next with that part fixed.

Thinking out loud here as it's still not clear to me what is going on. Currently we have this:

Assume building the latest version so that would be tags: 10.1.6, 10.0.13, and 9.0.0.p43

That's not actually right, the latest version for 9.0.0 would be 9.0.0.p44. As we have discussed in another thread you just have to make sure to include the zm-build repo so that you get that tag as the latest one.

If I understand what you are presenting, we will be able to build older versions also from this day forward.

Maldua scripts have a new switch pimbra-enabled.
You are supposed to be using pimbra-enabled from versions 10.1.5, 10.0.13, 9.0.0.p44 or newer.
For older versions than 10.1.5, 10.0.13, 9.0.0.p44 you are supposed to turn it off with pimbra-disabled so that you fallback to whatever we were doing before pimbra appeared.

If they choose to build 10.1 then the tag on pimbra's zm-web-client.git is 10.1.5-maldua (so look behind one for correct maldua tag)
if they choose to build 10.0 then the tag on pimbra's zm-web-client.git is 10.0.13-maldua (perfect)
if they choose to build 9.0 then the tag on pimbra's zm-web-client.git is 9.0.0.p44-maldua (look ahead one for tag for correct maldua tag)

I see that you have 10.1.6 config but there is no tag for the repository for 10.1.6-maldua. Can you give some guidance as I am attempting to come up with an algorithm given a version which represents the tag to build for the correct pimbra tag.

The way it's designed right now once you choose the actual tag/version you need to check for it in the maldua-pimbra-config repo.
I guess I should rewrite the maldua-pimbra READMEs so that I make more clear that you need to go ahead to the maldua-pimbra-config repo and read/use the examples there.

Here there are some working examples that should clarify it:

• maldua-pimbra-config 10.1.5 tag config.build enforces 10.1.5-maldua tag from maldua-config's zm-web-client repo.
• maldua-pimbra-config 10.0.13 tag config.build enforces 10.0.13-maldua tag from maldua-config's zm-web-client repo.
• maldua-pimbra-config 9.0.0.p44 tag config.build enforces 9.0.0.p44-maldua tag from maldua-config's zm-web-client repo.

The newest 10.1.6 does not have any specific 10.1.6 zm-web-client change so it should enforce the old 10.1.5. Here:

• maldua-pimbra-config 10.1.6 tag config.build enforces 10.1.5-maldua tag from maldua-config's zm-web-client repo.

[zmcontrol]

The newest 10.1.6 does not have any specific 10.1.6 zm-web-client change so it should enforce the old 10.1.5. Here:

adrian.gibanel.btactic,

Back in January a branch 'hotfix/10.1.6' was created but without a tag since 10.1.5 is missing.
If a hotfix/10.1.6-maldua branch is created and the 10.1.5 patch applied, a proper 10.1.6-maldua tag could be quickly made.

[adrian.gibanel.btactic]

Trying to wrap my head around all this. I did this:

Code: Select all

#!/bin/sh
git clone --depth 1 --branch "9.0.0.p44" "git@github.com:Zimbra/zm-build.git"
cd zm-build

ENV_CACHE_CLEAR_FLAG=true ./build.pl \
  --ant-options -DskipTests=true \
  --git-default-tag="9.0.0.p43,9.0.0.p42,9.0.0.p41,9.0.0.p40,9.0.0.p39,9.0.0.p38,9.0.0.p37,9.0.0.p36,9.0.0.p34,9.0.0.p33,9.0.0.P33,9.0.0.p32.1,9.0.0.p32,9.0.0.p30,9.0.0.p29,9.0.0.p28,9.0.0.p27,9.0.0.p26,9.0.0.p25,9.0.0.p24.1,9.0.0.p24,9.0.0.p23,9.0.0.p22,9.0.0.p21,9.0.0.p20,9.0.0.p19,9.0.0.p18,9.0.0.p17,9.0.0.p16,9.0.0.p15,9.0.0.p14,9.0.0.p13,9.0.0.p12,9.0.0.p11,9.0.0.p10,9.0.0.p9,9.0.0.p8,9.0.0.p7,9.0.0.p6,9.0.0.p5,9.0.0.p4,9.0.0.p3,9.0.0.p2,9.0.0.p1,9.0.0" \
  --build-release-no="9.0.0" \
  --build-type=FOSS \
  --build-release="KEPLER_T090000p43C090000p44FOSS" \
  --build-thirdparty-server=files.zimbra.com \
  --no-interactive \
  --build-release-candidate=GA \
  --git-overrides maldua-pimbra.url-prefix="git@github.com:maldua-pimbra" \
  --git-overrides zm-web-client.remote="maldua-pimbra" \
  --git-overrides zm-web-client.tag="9.0.0.p44-maldua"

Seems like magic! I can see a lot of future functionality in this.

Git overrides, either in the form of command line switches or config.build contents have been there in zm-build since ever. You can check default config.build.in contents.

It's probably used by Zimbra developers everyday so that an specific core repo is not fetched from default sources but from their own local repo which might have new features or fixes to be implemented.

So, yeah, I mean, if you want to explore wild customizations on core Zimbra packages that's one of the cleanest ways of doing it.

The only new thing here is --git-overrides being integrated onto ZCS build wrapper scripts so that some of the Zimbra core packages are not strictly from official upstream repos.

Ianw1974's zimbra-build-scripts uses an alternate method of applying changes based on a patches directory but, you know, unless it's strictly a Debian package I don't like keeping track of several patch files. I prefer to maintain git commits on branches.

[adrian.gibanel.btactic]

The newest 10.1.6 does not have any specific 10.1.6 zm-web-client change so it should enforce the old 10.1.5. Here:

adrian.gibanel.btactic,

Back in January a branch 'hotfix/10.1.6' was created but without a tag since 10.1.5 is missing.
If a hotfix/10.1.6-maldua branch is created and the 10.1.5 patch applied, a proper 10.1.6-maldua tag could be quickly made.

Yeah, I saw that branch but... you know... it's a bit tricky. A branch it's supposed to be used as a work-in-progress. Why should we imply that the 'hotfix/10.1.6' branch should have ended onto '10.1.6' tag as is ?

Also what you are suggesting (right now) is that I force push '10.1.6-maldua' tag on the maldua-pimbra-config repo so that it enforces a zm-web-client 10.1.6-maldua tag instead of a zm-web-client 10.1.5-maldua tag. And, well, git force-push are kind of forbidden in public repos and, well, you know, Maldua builds for 10.1.6 are already there based on that specific tag so... I'm not going to force-push.

Given that those 'hotfix/10.1.6' branch hotfixes seem not be critical let's postpone the decision of using them till 10.1.7 tags appear in Zimbra repos after a Zimbra NE 10.1.7 release.

[JDunphy]

Assume building the latest version so that would be tags: 10.1.6, 10.0.13, and 9.0.0.p43

That's not actually right, the latest version for 9.0.0 would be 9.0.0.p44. As we have discussed in another thread you just have to make sure to include the zm-build repo so that you get that tag as the latest one.

Without a p44 in any repositories other than zm-build.git (build system), how sure are you that they will not eventually add the patch you have added and tag zm-web-client p44? I had always thought it was incoming myself.

Adding p44 to --git-default-tag seems wrong to me since there are no repositories that would have that tag so it would have no benefit. Aren't we just doing git clone -b <tags> repository - meaning there are no p44 repositories so why have it listed with --git-default-tag if it's not present?

Jim

[adrian.gibanel.btactic]

Assume building the latest version so that would be tags: 10.1.6, 10.0.13, and 9.0.0.p43

That's not actually right, the latest version for 9.0.0 would be 9.0.0.p44. As we have discussed in another thread you just have to make sure to include the zm-build repo so that you get that tag as the latest one.

Without a p44 in any repositories other than zm-build.git (build system), how sure are you that they will not eventually add the patch you have added and tag zm-web-client p44? I had always thought it was incoming myself.

Jim

Well, 10.0.13 is a counter example of what you are saying here.
10.0.13 does not have the CVE patch but it appears to you as the latest tag of 10.0.x because it actually appears as a tag in other repos different than zm-build.

Anyways what you're saying it's true. They might add that fix later on as a 9.0.0.p44 tag.

Given how git overrides work if you try to build 9.0.0.p44 in a hipothetic future where they have pushed an official 9.0.0.p44 tag for zm-web-client repo... well... it will be still using the pimbra patch instead.

Also if an official 9.0.0.p44 tag for zm-web-client repo is pushed as the Maldua 9.0.0.p44, 10.0.13, 10.1.5 builds have been built against pimbra I would have to say that those specific versions should be built against pimbra and then fallback to the default Zimbra upstream repos onwards. It's a maintainer nightmare if some versions should use pimbra and some of them not, I know.

Pimbra is here to stay either active (if CVE-2025-27915 is never pushed to upstream Zimbra repos) or paused (we need to be ready if they do something similar in the future).

Additional note: The nice thing about Pimbra is that given that it is based on config.build files you can track several patches among several repos at once which you cannot discard you needing in the future.

[adrian.gibanel.btactic]

Assume building the latest version so that would be tags: 10.1.6, 10.0.13, and 9.0.0.p43

That's not actually right, the latest version for 9.0.0 would be 9.0.0.p44. As we have discussed in another thread you just have to make sure to include the zm-build repo so that you get that tag as the latest one.

Adding p44 to --git-default-tag seems wrong to me since there are no repositories that would have that tag so it would have no benefit. Aren't we just doing git clone -b <tags> repository - meaning there are no p44 repositories so why have it listed with --git-default-tag if it's not present?

Jim

We wouldn't have these discussions if Zimbra had just pushed 9.0.0.p44 tag to zm-web-client repo.
Look, I have created 9.0.0.p44-maldua tags instead of 9.0.0.p43-maldua tags because NE release that fixes CVE-2025-27915 is 9.0.0.p44.

You are right, adding 9.0.0.p44 to --git-default-tag is the same thing as not adding it but, who cares? When building 9.0.0.p44 will be probed, ignored by not existing, then 9.0.0.p43 and so on.

I am using '9.0.0.p44' by the means of overriding it thanks to pimbra tags.

Ok, let's see... the way I fetch tags I can avoid non existant tags to be used (E.g. 10.1.8 does not exist nowadays). In other words if the tag does not exist the build fails. So 10.1.8 would fail for me nowadays.
So... if 9.0.0.p44 does not exist for me... well... I cannot build 9.0.0.p44, that's why I have to add zm-build repo into the repos that I fetch tags from so that 9.0.0.p44 exists for me. Then if 9.0.0.p44 exists for me... I am going to include it on the --git-default-tags because that's how I coded it.

In other words... Unless it's much easier to fix than I suspect Maldua builds will keep using --git-default-tag starting with 9.0.0.p44 even if 9.0.0.p44 tag does not exist outside zm-build repo.

Go ahead and use 9.0.0.p43 as the starting --git-default-tag in this specific 9.0.0.p44 scenario if you wish. You should be fine.

Now that I think about it... Another argument in favour of adding zm-build repo to the repos to fetch tags from is that you were missing that 9.0.0.p44 tag was there and you thought that 9.0.0.p43 tag was the last one.