GitLab Shell now has the go.mod and go.sum files in the root of the
repo; the go subdirectory has been removed and all the code in it has
been moved up to the root.
For some reason this untagged commit is the one referred to in the
main repository; this might be a mistake, but we'll have to package it
for now to follow upstream.
https://about.gitlab.com/blog/2019/12/10/critical-security-release-gitlab-12-5-4-released/
Insufficient parameter sanitization for Maven package registry could lead to privilege escalation and remote code execution vulnerabilities under certain conditions. The issue is now mitigated in the latest release and is assigned CVE-2019-19628.
When transferring a public project to a private group, private code would be disclosed via the Group Search API provided by Elasticsearch integration. The issue is now mitigated in the latest release and is assigned CVE-2019-19629.
The Git dependency has been upgraded to 2.22.2 in order to apply security fixes detailed here.
CVE-2019-19604 was identified by the GitLab Security Research team. For more information on that issue, please visit the GitLab Security Research Advisory
closes #75506.
Hydra fails to build the assets on i686 - it runs out of memory. If we
limit the max consumption to 2048MB the assets still build, and will
hopefully also build on hydra.
For some reason hydra seems to have issues downloading the
gitlab-workhorse source on macOS. Since we don't build the rails app
for macOS, the other components seem a bit useless there, so we
limit them to linux for now.
- gitlab-shell no longer requires ruby for anything else than the
install script, so the bundlerEnv stuff could be dropped
- gitlab-shell and gitlab-workhorse now report their versions
correctly
On start, unicorn, sidekiq and other parts running ruby code emits
quite a few warnings similar to
/var/gitlab/state/config/application.rb:202: warning: already initialized constant Gitlab::Application::LOOSE_EE_APP_ASSETS
/nix/store/ysb0lgbzxp7a9y4yl8d4f9wrrzy9kafc-gitlab-ee-12.3.5/share/gitlab/config/application.rb:202: warning: previous definition of LOOSE_EE_APP_ASSETS was here
/var/gitlab/state/lib/gitlab.rb:38: warning: already initialized constant Gitlab::COM_URL
/nix/store/ysb0lgbzxp7a9y4yl8d4f9wrrzy9kafc-gitlab-ee-12.3.5/share/gitlab/lib/gitlab.rb:38: warning: previous definition of COM_URL was here
This seems to be caused by the same ruby files being evaluated
multiple times due to the paths being different - sometimes they're
loaded using the direct path and sometimes through a symlink, due to
our split between config and package data. To fix this, we make sure
that the offending files in the state directory always reference the
store path, regardless of that being the real file or a symlink.
GitLab recently restructured their repos; whereas previously they had
one gitlab-ce and one gitlab-ee repo, they're now one and the
same. All proprietary components are put into the ee subdirectory -
removing it gives us the foss / community version of GitLab. For more
info, see
https://about.gitlab.com/2019/02/21/merging-ce-and-ee-codebases/
This gives us the opportunity to simplify things quite a bit, since we
don't have to keep track of two separate versions of either the base
data or rubyEnv.
Instead of extracting prebuilt assets from the debian build, build
them from the source. This should give faster package updates and
reduces the amount of data needed to be downloaded by more than 500MB.
Split the remove-hardcoded-locations patch into two separate patches,
one for the ruby package and one for the go package. This is clearer
and results in fewer rebuilds.
- Update GitLab to 12.3.4
- Update update.py to cope with the new upstream repository structure
- Refactor gitlab-shell to use buildGoPackage and bundlerEnv for
dependencies
- Refactor gitlab-workhorse to use buildGoPackage for dependencies
- Make update.py able to update gitlab-shell and gitlab-workhorse
dependencies
- Various fixes necessary for update to work
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
