Arch Linux

Upstream gitlab has an open merge request to update to grpc 1.52.0 which does not have this issue https://gitlab.com/gitlab-org/gitlab/-/merge_requests/114025

Attached diff applies the upstream merge request that updates grpc to 1.54.0. This would allow gitlab to be updated to 15.11.2+ which includes the fix for CVE-2023-2478.
Upstream is blocked waiting for grpc [1] which I believe does not apply to Arch which does no set any -I flags as part of CPPFLAGS.

[1] https://github.com/grpc/grpc/pull/32580

Upstream merge requests have been merged [1][2]. [3] Updates the package to 16.0.0 and applies [4] instead of [5] to avoid an unrelated hunk that removes puma_worker_killer from Gemfile.checksum

[6] Drops OpenSSL 3.0 compatibility changes that were merged upstream in 16.0.0 [7].

Additional suggested changes
[8] Drops all local Gemfile changes. bundler-audit was deprecated [9] then removed [10]. It is still in the development gem group which is why the update does not fail but that group is not installed so the update has no effect. [11] Now only causes a warning. If [12] is still an issue irb and its dependencies can be added back with [13] or [14]. [13] uses the same gem versions as 15.11.0-1, while [14] uses the gem versions from ruby2.7 2.7.8-1 so the gems will not be bundled which if I understand correctly was the original cause of the bug. rake is not included in the update fixes as it was already included as a dependency of multiple gems and so already in the package.

[15] Enable bundler checksum verification now there should no longer be any changes to the gems or their checksum's [16].

[1] https://gitlab.com/gitlab-org/gitlab/-/merge_requests/114025
[2] https://github.com/grpc/grpc/pull/32580
[3] PKGBUILD.diff.1
[4] https://gitlab.com/gitlab-org/gitlab/-/commit/5b9062832119599bf31ecca35e8fea74a9c1fe24.patch
[5] https://gitlab.com/gitlab-org/gitlab/-/commit/82be62d803d52d81a6a0aafc55a8f52af554a53a.patch
[6] PKGBUILD.diff.2
[7] https://gitlab.com/gitlab-org/gitlab/-/commit/7fb8faddef18f8f219565e1445f9583a3531e943
[8] PKGBUILD.diff.3
[9] https://gitlab.com/gitlab-org/gitlab/-/commit/7e80f2db213fc9b4e46964923f46ac4cd6ac31fe
[10] https://gitlab.com/gitlab-org/gitlab/-/commit/b0c20234c4c11634d5b3500d039f5991db4d2c40
[11] https://github.com/bundler/bundler/issues/6882
[12] https://bugs.archlinux.org/task/68569
[13] fixes.1.patch
[14] fixes.2.patch
[15] PKGBUILD.diff.4
[16] https://gitlab.com/gitlab-org/gitlab/-/commit/c557edde481cf3597b5401a8454c8e9b1bebca22

Thanks for the patches @loqs. I just jumped on this package (again, apparently I used to work on it in its AUR days too!) and Anatol asked me to check these out. It's going to take a bit to make sense of things though. It's hard jumping on to this package because it doesn't currently build in its last-released form so I can't make incremental changes looking for breakage/differences.

I *was* going to try to bump the 15.11.z patch releases first, then move on to 16. Off the top of your head does that sound like a good idea? Or would it be easier to move straight to 16.y.z to avoid Ruby version troubles?

BTW now that we have Git based packaging, feel free to fork the `gitlab` package[1] when you hack on it like this, then just make commits to your fork. We have MRs disabled for now (there are plans to change that) but if you just point me to your fork I'd be happy to review patch sets from there and cherry-pick whatever I can confirm works. I appreciate all the attachments here but the workflow is kind of rough on both ends.

[1] https://gitlab.archlinux.org/archlinux/packaging/packages/gitlab

> I *was* going to try to bump the 15.11.z patch releases first, then move on to 16. Off the top of your head does that sound like a good idea? Or would it be easier to move straight to 16.y.z to avoid Ruby version troubles?
I can not see an issue with that approach.

I get the first (grpc) patch going, that is in testing now. I'm playing around in a branch[1] with the other patches, but with all of them applied I get this build error:

> Cached checksum for puma_worker_killer-0.3.1 not found. Please (re-)generate Gemfile.checksum with `bundle exec bundler-checksum init`.

That sounds like your patch "[3] didn't apply [4] instead of [5]" as your comment suggested. Any insight into that? Or did I do it wrong?

[1] https://gitlab.archlinux.org/archlinux/packaging/packages/gitlab/-/commits/repatch

(Note the 16.x branch is just PoC at this point. I still want to try to bump to the patch releases first).

> That sounds like your patch "[3] didn't apply [4] instead of [5]" as your comment suggested. Any insight into that? Or did I do it wrong?
You did not do it wrong. I forgot I manually removed the hunk that dropped puma_worker_killer from Gemfile.checksum the attached 5b9062832119599bf31ecca35e8fea74a9c1fe24.patch matches the checksum in [3].

Split out restoring puma_worker_killer's checksum into a separate patch so 5b9062832119599bf31ecca35e8fea74a9c1fe24 from upstream can be used without changes.
Edit:
For reference this is the commit that dropped puma_worker_killer https://gitlab.com/gitlab-org/gitlab/-/commit/8ef0e7b5913fffdc1a991f0b2e56de857fa6c337 which missed removing the checksum so when 5b9062832119599bf31ecca35e8fea74a9c1fe24 was later committed and the checksums regenerated it included the removal of puma_worker_killer.

Thanks for the help with patches! My experimental branch now builds 16.0.0 successfully. I'll get that in [extra-testing] as soon as 15.11.6 gets out of the way.

BTW the gitlab-gitaly package looks like its going to have similar issues with grpc.

> BTW the gitlab-gitaly package looks like its going to have similar issues with grpc.
Ah I tested with gitlab-gitaly 16.0.0 which stopped using ruby. Attached diffs for both 15.11.0 and 16.0.0.

Thanks for all the patches loqs, clearly you know your way around GitLab internals and Ruby better than I.

I'm going to close out this bug now because I think it is all dealt with. GitLab (including Gitaly) 15.x has been patched up to build again and is in [extra]. Meanwhile all the patches for 16.x have been applied and builds of those are in [extra-testing]. At this point I think if anything else comes up it would be better to have it in a new bug report here.

Also you can ping me on IRC, email me patches (I'm not great about finding mail in the flood though), and as I mentioned fork the packaging on GitLab (or anywhere) and point me to the repo if there is more stuff you have to contribute.