Fix FIPS builds not working with Ruby gpgme update
What does this MR do?
In the Ruby gpgme
gem v2.0.22, https://github.com/ueno/ruby-gpgme/pull/166 modified the building of the C extension library to use pkg-config
instead of gpgme-config
since Debian has dropped the gpgme-config
binary from its install.
However, this change quietly ignores failures when pkg-config
does not include the gpgme.pc
in its PKG_CONFIG_PATH
(https://github.com/ueno/ruby-gpgme/issues/167). When this happens, the C extension library omits a dependency on the gpgme
library and
causes unresolved symbols to occur when the gpgme
Ruby library is loaded.
This only happens in our FIPS builds because PKG_CONFIG_PATH
is overridden with OpenSSLHelper.pkg_config_dirs
, but /opt/gitlab/embedded/lib/pkgconfig
needs to be included for other libraries that need pkg-config
.
We can drop this workaround if Omnibus drops managing of the gpgme dependencies, since the gem will download and statically link the versions it needs automatically (#7344).
Related issues
- #7344
- #7345 (closed)
- Upstream fix: https://github.com/ueno/ruby-gpgme/pull/168
Checklist
See Definition of done.
For anything in this list which will not be completed, please provide a reason in the MR discussion
Required
-
Merge Request Title, and Description are up to date, accurate, and descriptive -
MR targeting the appropriate branch -
MR has a green pipeline on GitLab.com -
Pipeline is green on dev.gitlab.org if the change is touching anything besides documentation or internal cookbooks -
trigger-package
has a green pipeline running against latest commit
Expected (please provide an explanation if not completing)
-
Test plan indicating conditions for success has been posted and passes -
Documentation created/updated -
Tests added -
Integration tests added to GitLab QA -
Equivalent MR/issue for the GitLab Chart opened