Hello,
I would like to understand in general how are most people dealing with older versions of git rpms, my main concern is that recently git had some vulnerabilities, for example CVE-2023-23946 , which will be fixed in v2.39.2, v2.38.4, v2.37.6, v2.36.5, v2.35.7, v2.34.7, v2.33.7, v2.32.6, v2.31.7, and v2.30.8, but in Rocky 8, latest available version is 2.31.1 , so it seems to me, that git package in official repos are still without fixes for such vulnerabilities.
Only viable option I see is to build from source, but I am interested in how do people deal with such situations in general, not only for git package, but for other packages?
Are your really building a lot of different tools from source in order to keep up with latest vuln fixes?
If yes, then how do you manage this at scale, let’s say for hundreds of systems ?
I would appreciate any examples that you use, because at the moment I have only an option to build things from source or wait for vendor package update. (am I missing some other option? )
P.S. I know that for some software there are 3rd party repos, but for smaller tooling or some packages, there are either none or they are not listed as trusted vendor anywhere, so there are other risks involved here.
Red Hat backports fixes to the versions of software they provide. Eg, OpenSSL is one they backport fixes for mainly because upgrading OpenSSL to a later version could break a lot of software that is provided in RHEL that relies on the version that is already there. Backporting has been common on RHEL for a long time to address issues, bug fixes, security fixes, etc.
Whether they will backport for that particular git version, or update to a later version, I guess we’ll see when that issue is addressed by Red Hat. That will then filter down to Rocky and other derivatives. There is an issue open on RH Bugzilla for that particular CVE: 2168161 – (CVE-2023-23946) CVE-2023-23946 git: git apply: a path outside the working tree can be overwritten with crafted input
Other options are using git from eg Fedora src rpm’s and then building that with mock for example. This can also be done for packages that don’t exist in RHEL/Rocky or EPEL for that matter. Package requests can be made to EPEL to get them to maintain and provide. That way saves compiling yourself. I do have some packages that I have my own repo for that I use for a number of systems. So there are a number of options until the vendor makes a release/update/backport.
1 Like
The backporting means that the “git-2.31.1-3.el8_7” that is in EL8 distros is not the upstream “git-2.3.1”; it is a branch originally forked from the upstream “git-2.3.1”.
Granted, changelog of the “branch” is short:
$ rpm -q --changelog git | head -13
* Wed Jan 25 2023 Ondřej Pohořelský <opohorel@redhat.com> - 2.31.1-3
- Fixes CVE-2022-23521 and CVE-2022-41903
- Tests: try harder to find open ports for apache, git, and svn
- Resolves: #2162063
* Thu Nov 25 2021 Ondrej Pohorelsky <opohorel@redhat.com> - 2.31.1-2
- Remove perl(Email::Valid) require from git-email
- Related: rhbz#2021547
* Fri Nov 19 2021 Ondrej Pohorelsky <opohorel@redhat.com> - 2.31.1-1
- Update to release 2.31.1
- Resolves: rhbz#2021547
No, I do not.
If Red Hat deems their version sufficiently safe for their paying RHEL customers, then it is sufficiently safe for me too.
For CVE-2023-23946 Red Hat says: “Moderate Impact – Will not fix” cve-details
2 Likes