[MIR] galera-4

Bug #2122096 reported by Otto Kekäläinen
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
galera-4 (Ubuntu)
Incomplete
Undecided
Unassigned

Bug Description

[Availability]
The package `galera-4` has been in Ubuntu universe since 19.10 (Eoan Ermine), replacing the older `galera-3` package, which itself has been available in Ubuntu since 15.10 (Wily Werewolf).
The package `galera-4` builds for the architectures it is designed to work on.
It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/galera-4

[Rationale]
- The package `galera-4` is required in Ubuntu main for MariaDB high-availability (HA) clustering.
- The package `galera-4` will generally be useful for a large part of our user base, particularly those deploying MariaDB in production environments requiring HA.
- It is a key component for cloud deployments and enterprise setups requiring database HA.
- This enables the creation of fully supported, highly available MariaDB clusters on Ubuntu.
- The package `galera-4` is a runtime dependency for the clustering features of `mariadb-server`, which is concurrently proposed for inclusion in main.
- There is no other/better way to solve MariaDB multi-master replication that is already in main. Galera is the canonical solution for this.
- This is the first time this package will be in main.
- The binary packages `galera-4` and `galera-arbitrator-4` need to be in main to provide a supported HA solution for MariaDB. The `galera-4` package provides the core replication library (`libgalera_smm.so`), while the `galera-arbitrator-4` package provides the arbitrator daemon, an important component for robust cluster deployments.
- All binary packages built by the `galera-4` source package need to be in main to achieve this.

[Security]
- The `galera-4` source package has a clean security history with no CVEs. The older `galera` (v3) package had some vulnerabilities, but `galera-4` is a newer codebase. Security maintenance is handled by backporting fixes from upstream. While some vulnerabilities have been associated with MariaDB's use of Galera (e.g., `wsrep` API), these have been in MariaDB's codebase, not `galera-4` itself.
- CVEs: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=galera
- Ubuntu CVE tracker: https://ubuntu.com/security/cve?package=galera-4
- Debian Security Tracker: https://security-tracker.debian.org/tracker/source-package/galera-4
- No `suid` or `sgid` binaries. The `garbd` binary is installed in `/usr/sbin` and can be run as a non-root user.
- This Galera Arbitrator daemon can be used in small clusters to avoid split-brain scenarios, but it is fully optional and requires explicit configuration to enable.
- The package provides an optional service (`garbd.service`) that is not enabled by default.
- The package does not open privileged ports (< 1024). The default Galera port is 4567.
- The package exposes external endpoints for cluster communication. These endpoints should be protected by firewall rules.
- The package contains a plugin for MariaDB, a security-sensitive application. It relies on the security features of the database server.

[Quality assurance - function/usage]
- The package needs post-install configuration. Setting up a database cluster is a complex task that depends on the specific network environment and desired topology. There can be no "safe" default that works out of the box. Extensive documentation is available from upstream and as part of MariaDB documentation.

[Quality assurance - maintenance]
- The package is actively maintained by upstream (Codership), in Debian, and in Ubuntu. The packages are maintained by the same team in both Debian and Ubuntu.
  - Ubuntu: https://bugs.launchpad.net/ubuntu/+source/galera-4/+bugs
  - Debian: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=galera-4
  - Upstream: https://github.com/codership/galera/issues
- There are no known critical open bugs that would block its inclusion in main.
- The package does not deal with exotic hardware we cannot support.
- The package has a Stable Release Update (SRU) exception, allowing for regular microrelease updates, which demonstrates its stability and the established process for its maintenance in Ubuntu. See https://documentation.ubuntu.com/sru/en/latest/reference/exception-MariaDB-Galera-Updates/

[Quality assurance - testing]
- The package runs a test suite at build time. A failure in the test suite will cause the build to fail.
  - Example build log: https://launchpad.net/ubuntu/+source/galera-4/26.4.23-1/+build/31080416
- The package has autopkgtests which are passing on all supported architectures.
  - Autopkgtest logs: https://autopkgtest.ubuntu.com/packages/g/galera-4
- The package does not have failing autopkgtests right now.
- Health in Debian is good: https://tracker.debian.org/pkg/galera-4
  - Autopkgtest logs: https://ci.debian.net/packages/g/galera-4/
- Salsa CI is extensive and maintained: https://salsa.debian.org/mariadb-team/galera-4/-/commits/debian/latest
  - Link to definition: https://git.launchpad.net/ubuntu/+source/galera-4/tree/debian/salsa-ci.yml

[Quality assurance - packaging]
- debian/watch is present and works.
- debian/control defines a correct Maintainer field ("Ubuntu Developers <email address hidden>") for uploads in Ubuntu.
- The package is maintained to the smallest details. The output of `lintian --pedantic` reports very few issues and will be attached to the bug.
- Lintian overrides are not present.
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies.
- The package will not be installed by default.
- Packaging is standard for a C++ project using cmake.
  - Link to debian/rules: https://git.launchpad.net/ubuntu/+source/galera-4/tree/debian/rules

[UI standards]
- Application is not end-user facing (it is a database cluster replication library).
- It is a server-side component and does not require a .desktop file.

[Dependencies]
- All runtime dependencies are in main. Running `check-mir` does not raise any issues.

[Standards compliance]
- This package correctly follows FHS and Debian Policy (Standards-Version: 4.7.2).

[Maintenance/Owner]
- I suggest the owning team to be the Ubuntu Server team. The expertise they already have in maintaining the MySQL packaging directly carries over to MariaDB/Galera packaging. I am committed to continue contributing and in general it seems that MariaDB/Galera packaging has many more contributors than MySQL packaging.
- The future owning team is not yet subscribed, but will subscribe to the package before promotion.
- This package does not use static builds.
- This package does not use vendored code.
- This package is not based on Rust or Go.
- The package is regularly built in the archive.
  - Build history on Launchpad: https://launchpad.net/ubuntu/+source/galera-4/+publishinghistory

[Background information]
- The package description explains the package well.
- Upstream Name: Galera Cluster
- Link to upstream project: https://galeracluster.com/ (commercial/docs) and https://github.com/codership/galera (code)
- The packaging is designed to replace the older `galera-3` and conflicts with other non-standard implementations (e.g., from Percona), positioning it as the canonical version for Ubuntu.
- This package is the essential component to enable High Availability (HA) clustering for MariaDB, a key feature for enterprise and cloud database deployments. Its inclusion in main is critical for providing a fully supported HA database solution in Ubuntu.

Tags: sec-7520

CVE References

Changed in galera-4 (Ubuntu):
assignee: nobody → Myles Penner (mylesjp)
Revision history for this message
Myles Penner (mylesjp) wrote :
Download full text (5.3 KiB)

Review for Source Package: galera-4

[Summary]
The essence of the review result from the MIR POV
MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.
This does need a security review, so I'll assign ubuntu-security
List of specific binary packages to be promoted to main: galera-4, galera-arbitrator-4

Notes:
Required TODOs:
- The embedded asio package should be unbundled if possible and the Ubuntu version should be used instead for the purpose of maintainability. Can the submitter please comment on the feasibility of unbundling asio and using the Ubuntu version instead?

Recommended TODOs:
- The package should get a team bug subscriber before being promoted

[Rationale, Duplication and Ownership]
A team is committed to own long term maintenance of this package - Ubuntu Server Team suggested in the MIR. Requires subscription before promotion.
The rationale given in the report seems valid and useful for Ubuntu

[Dependencies]
OK:
- no other Dependencies to MIR due to this
  - SRCPKG checked with `check-mir`
  - all dependencies can be found in `seeded-in-ubuntu` (already in main)
  - none of the (potentially auto-generated) dependencies (Depends
    and Recommends) that are present after build are not in main
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
(Rules from MIR reviewer template left in for reference)
RULE: - Embedding a library source increases the maintenance burden of a package
RULE: since that source needs to be maintained separately from the source in
RULE: the Ubuntu archive. If a source embeds another package, in general the
RULE: embedded package should not be used and the packaging should be modified
RULE: to use the Ubuntu archive version. When this is not possible, the
RULE: security team must agree to using the embedded source.

- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard
- Does embed asio, a package which is also in Ubuntu and should be used rather than being embedded in galera-4.

Problems:
 - This package embeds asio which is also available in the Ubuntu archive (https://launchpad.net/ubuntu/+source/asio). When possible, the Ubuntu version should be used for the purpose of maintainability. If this is not possible, the Security team will need to comment on the maintainability of this package. Can the original MIR submitter please comment on the embedded asio package and whether the Ubuntu version can be used instead?

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source - this package participates in Galera group communication and parses replication traffic from peers. I feel this should be treated as an untrusted source and warrants a security review.
- does e...

Read more...

Changed in galera-4 (Ubuntu):
assignee: Myles Penner (mylesjp) → nobody
assignee: nobody → Ubuntu Security Team (ubuntu-security)
Revision history for this message
Otto Kekäläinen (otto) wrote :

Ack, I've read the review and AFAIK the only action item for me is to update the build to use system ASIO. Tracking that in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1115369.

Myles Penner (mylesjp)
Changed in galera-4 (Ubuntu):
status: New → Incomplete
tags: added: sec-7520
Revision history for this message
Hlib Korzhynskyy (hlibk) wrote :
Download full text (4.9 KiB)

I reviewed galera-4 26.4.23-1 as checked into questing. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

galera-4 is a high availability database solution that provides scalability
for database growth.

- CVE History
  - `CVE-2023-5157`
    - The CVE mentioned mariadb but seems to be a vulnerability in
      `galera-4`. Fixed in 26.4.12.
  - There seem to have been CVEs assigned for mariadb-galera, however
    they seem to be MariaDB package specific. These seem to have been
    handled properly.
- Build-Depends
  - Normal build depends.
- pre/post inst/rm scripts
  - Creates a default galera system user in preinst script for
    `galera-arbitrator-4.deb`.
  - Other scripts are automatically generated to manage the systemd
    service by `dh_installsystemd`.
- init scripts
  - ./etc/init.d/garb
- systemd units
  - `galera-arbitrator-4`
    - ./usr/lib/systemd/system/garb.service
    - ./usr/lib/systemd/system/garbd.service -> garb.service
    - The systemd services seem to be rather basic, launching the
      garb-systemd executable as the newly created `_galera` system user.
      The service doesn't provide any additional protections or rules,
      which is something to keep in mind.
- dbus services
  - None
- setuid binaries
  - None
- binaries in PATH
  - ./usr/bin/garbd
  - ./usr/bin/garb-systemd
- sudo fragments
  - None
- polkit files
  - None
- udev rules
  - None
- unit tests / autopkgtests
  - There seem to be a few (7) unit tests running at build time.
  - For autopkgtests, there seems to only be a smoke test.
    - It seems to execute `garbd` and displays the usage information about
      the program.
  - It would be appreciated if more tests could be included in the package.
- cron jobs
  - None
- Build logs
  - Seem fine.

- Processes spawned
  - None
- Memory management
  - Memory management seems fine, the size during memcpy and malloc seems
    to be checked. There seem to be some custom implementation of malloc
    (such as RingBuffer) which also seem to do some size checks.
- File IO
  - Vendors ASIO library
    - It is recommended to not vendor code unless necessary. This would
      simplify the security team's ability to provide updates in case ASIO
      contains a vulnerability.
    - It appears like `galera-4` does not build with ASIO version 1.33+.
      There are issues tracking this upstream. Ubuntu currently ships ASIO
      1.30, but an update to the version could break `galera-4`.
      - https://jira.mariadb.org/browse/MDEV-36926
      - https://github.com/codership/galera/issues/679
    - ASIO is currently in universe.
- Any significant shellcheck results
- Logging
  - Seems fine. Extensive logging for debug purposes exists, and it is
    handled without issues.
- Environment variable usage
  - None
- Use of privileged functions
  - None
- Use of cryptography / random number sources etc
  - Seems to support TLS (not enabled by default). Code refers to SSL when
    talking about TLS.
    - mariadb-server needs to be compiled with TLS support (configuration
      option) on all nodes. On Ubuntu, TLS support is enabled for both
      mariadb-server and galera-4 and so it is...

Read more...

Changed in galera-4 (Ubuntu):
assignee: Ubuntu Security Team (ubuntu-security) → nobody
Revision history for this message
Otto Kekäläinen (otto) wrote :

Thanks for the review and ACK from security point of view!

Extending autopkgtests is tracked in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053333 and pending upstream to make their post-build test suite runnable independently.

If you have the logs from the cppcheck and Coverity runs, maybe we should submit them upstream even if the findings are tiny?

Revision history for this message
Hlib Korzhynskyy (hlibk) wrote (last edit ):

Thanks for the confirmation about the autopkgtests.

Sending the results upstream doesn't sound like a bad idea. Would you happen to have an upstream contact for security issues? From the README in the upstream repository there is the email `<email address hidden>`.

I can also see that the owner of the repository is now "mariadb-corporation" (the link is now https://github.com/mariadb-corporation/galera), so perhaps the reporting of security issues is now the same as for MariaDB (sending an email to <email address hidden>).

Revision history for this message
Otto Kekäläinen (otto) wrote : Re: [Bug 2122096] Re: [MIR] galera-4

I am not sure, but sending to <email address hidden> sounds like a good
start. Since the finding are minor and I assume anyone running those
scanners can find them anyway, reporting them in GitHub issues as normal
quality issues would probably also be fine.

Revision history for this message
Otto Kekäläinen (otto) wrote :

Are you also going to review related MariaDB MIR (https://bugs.launchpad.net/ubuntu/+source/mariadb/+bug/2122095) or is that a different Security Team person?

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Hlib has volunteered to work on the MariaDB review, yes.

Revision history for this message
Hlib Korzhynskyy (hlibk) wrote :

I have sent the results to <email address hidden> .

And yes, as Seth mentioned, I will also review MariaDB. It will take some time though due to the size of the package.

Revision history for this message
Otto Kekäläinen (otto) wrote :

Did you get replies? What is the security disclosure policy, can you now or in 1 or 2 months post the list of the findings in this issue publicly so that it is easier to track if they were fixed/mitigated?

Revision history for this message
Hlib Korzhynskyy (hlibk) wrote :

I received confirmation that they received the results and were taking a look at them.

For the disclosure policy, as this is not precisely a "security vulnerability" but rather reports from a scanner, where we did not find anything problematic, and mariadb upstream already does coverity scanning of their repository (https://scan.coverity.com/projects/mariadb) it is unclear whether this should be reported publicly after a certain time.

From the last upstream coverity report (from the link above, dated what appears to be march 2023) there were also quite a few hits from the scanner, so it is likely that mariadb upstream deemed them to be false positives. I can always follow up on this to see if mariadb has a specific disclosure policy when it comes to scanner findings.

Revision history for this message
Hlib Korzhynskyy (hlibk) wrote :

Just an update for the above.

Upstream has stated that they triggered their own coverity scanner analysis and fixed the high severity issues in the 26.4.25 release. As far as I know these did not get assigned a CVE number, but I will confirm.

Revision history for this message
Otto Kekäläinen (otto) wrote :

Status update: Both of the requests that came out of this review have a MR pending: https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/38 for using system ASIO and https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/39 for extending the autopkgtest. Once they are merged and uploaded the open Galera bugs in Debian drops to zero.

Thus nothing in Galera should be blocking the MIR, and it mainly depends on if the main MariaDB MIR at https://bugs.launchpad.net/ubuntu/+source/mariadb/+bug/2122095 is accepted or not.

Revision history for this message
Christian Ehrhardt (paelzer) wrote :

I had some time for an interim update:

- #1 Main MariaDB MIR (https://bugs.launchpad.net/ubuntu/+source/mariadb/+bug/2122095) is ready

- #2 https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/38 got merged in salsa, but isn't yet in an upload. That would reslove the MIR requirement raised by Myles (having that is required).

- #3 https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/39 is still open but recently got a positive reply (having them would be recommended, but not hard required)

- #4 The security report finding was resolved upstream in 26.4.25 which isn't yet uploaded either (but those are non blocking and not strictly needed)

Once that is done this should be able to migrate the two galera+maria together.

@Otto - could we get the changes for #2 and (and if trivial also #3 + #4) uploaded to resolute? Or am I overlooking a blocker that makes this harder than it seems and/or not as useful as we think it would be?

@Ubuntu Release team - the changes we have in mind would be:
- changing a vendored lib to a system lib (same but better maintenance)
- adding more autopkgtests
- fixing a minor security issue in 26.4.25
Could you bless this with "no need for a full FFE for this" please?

Revision history for this message
Otto Kekäläinen (otto) wrote :

I am in the process of importing latest Galera version 26.4.25 and will upload it, which takes care of #2 and #4, which after I will wait a few days for unexpected regressions and then continue by merging #3 and uploading it, which will go via the NEW queue due to the new galera-test binary package. I will be doing everything in my powers to have all 1-4 done as soon as as possible without unnecessary regression risk.

Revision history for this message
Otto Kekäläinen (otto) wrote :

Note to Release team that both MariaDB and Galera have extensive Salsa CI suites that also cover Ubuntu releases, and a track record of having multiple people review and bless all MRs before upload, so risks of regressions are minimized to the degree possible with good engineering practices.

Revision history for this message
Utkarsh Gupta (utkarsh) wrote :

Hello Christian and Otto,

> @Ubuntu Release team - the changes we have in mind would be:
> - changing a vendored lib to a system lib (same but better maintenance)
> - adding more autopkgtests
> - fixing a minor security issue in 26.4.25
> Could you bless this with "no need for a full FFE for this" please?

Right, approved. Thank you for checking in and giving a heads up. Please land this sooner though.

Revision history for this message
Otto Kekäläinen (otto) wrote :

I don't find that I got any CCs on the emails regarding Galera coverity scan results, but I confirm I see these commits in Galera in November 2025, and included inthe 26.4.25 release:

± git log --oneline release_26.4.25
5d07ad0a (tag: release_26.4.25) Bump Galera version to 26.4.25
099568d2 MGL-104 Analyze and fix coverity uncaught exception issues
6dc337f8 Replace singleton pointer with pointer to an array to silence coverity out-of-bounds access issue.
fb0dec66 Silence coverity resource leak issue by adding list from ListParse to head of existing list or head.
44122c7a Fixed integer overflow in fragment size calculation by changing type to ssize_t and asserting that calculated value remains positive.
23b18881 Fixed integer arithmetic operation overflow case.
68933b03 Fix possible inconsistent view of fc_resume_factor on concurrent threads
54d9f746 Fix possible inconsistent view of send_buf_len on concurrent threads
104dc51d Fix file handle leak on error case by closing them.
e0502a94 Fix invalid memory access after free.
cbad9056 Fix parameter can't be negative on posix_fallocate
c40d7173 Fix resource leak on error case.

Revision history for this message
Otto Kekäläinen (otto) wrote :

These two uploads landed in Debian this week, and with them all 1-4 issues are resolved:

 galera-4 (26.4.25-1) unstable; urgency=medium
 .
   * New upstream release 26.4.25. Includes multiple bug fixes, see
     https://mariadb.com/docs/release-notes/galera-cluster/26.4/26.4.25
   * Build using system ASIO, currently 1.30 in Debian (Closes: #1115369)
   * Start using MariaDB as upstream as they acquired Galera

 galera-4 (26.4.25-2) unstable; urgency=medium
 .
   * Add upstream autopkgtest to run installed test binaries (Closes: #1053333),
     and introduce new binary package 'galera-test'
   * Update machine readable copyright based on Debian DFSG NEW queue review
   * Salsa CI: Remove stretch/buster/bullseye upgrade jobs due to Boost 1.90
   * Salsa CI: Disable cross-builds that can't be fixed in Galera
   * Salsa CI: Disable debrebuild job that is failing on unrelated issues

I also have an extra Ubuntu-specific CI at https://salsa.debian.org/otto/galera/-/pipelines/1038187 that is passing (except for Jammy, but those failures are not a sign of any regressions).

With this, everything in this MIR is done as far as I am aware.

I will now wait for 24-48h to verify that everything is good in Debian, and then following the policy at https://documentation.ubuntu.com/project/release-team/request-a-freeze-exception/#request-a-freeze-exception file a "FFE: Sync galera-4 26.4.25-2 (universe) from Debian unstable (main)" for the Release Team to approve and sync, unless of course someone else triggers a sync some other path before that.

Revision history for this message
Otto Kekäläinen (otto) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.