besser82/libxcrypt

Unexpected issue with gitlabs (ruby bcrypt) implementation

Closed this issue · 12 comments

MartB commented

More details here:
https://gitlab.com/gitlab-org/gitlab-ce/issues/61857

Not quite sure where the issue is at the moment but it seems like :__bc_salt is bevaving differently.

https://github.com/codahale/bcrypt-ruby/blob/12a50f4ff20c1723cc08b3f3c5dcd257c305172c/ext/mri/bcrypt_ext.c#L9 is the calling code, apparently it works fine on older fedora versions without libxcrypt

Okay, I have a suspicion, where the problem comes from… Can you please provide me with details about how (is there a guide or any unofficial rpm around) gitlab-ce was installed on Fedora 30?

Maybe related: bcrypt-ruby/bcrypt-ruby#166 (comment)

bcrypt-ruby uses crypt_blowfish's wrapper code that I originally only intended for use by libc's, and then works around symbol clashes and function prototype differences between it and the systems' actual libc's. That's a problematic approach that's bound to cause more trouble. I don't know if that's what we have here, but I wouldn't be surprised if libxcrypt's use of crypt_blowfish now exposes even more clashes with bcrypt-ruby's.

What bcrypt-ruby should do is use crypt_blowfish's native interfaces instead, not the wrapper code intended for libc's.

MartB commented

Okay, I have a suspicion, where the problem comes from… Can you please provide me with details about how (is there a guide or any unofficial rpm around) gitlab-ce was installed on Fedora 30?

What people on fedora must do for gitlab is setup the repo for el7 and use their pre-built rpm files.
You can obtain them here (select the el7 version) https://packages.gitlab.com/gitlab/gitlab-ce

However after this gitlab-ctl reconfigure will fail, so before that you need to install libxcrypt-compat
Theoretically, after an systemctl start gitlab-runsvdir.service the normal gitlab install steps should work then.

The issue should be fixed in libxcrypt-4.4.6-2.fc30, which will be available in the Fedora updates stable repository within the next 8 days. In the mean time it can be installed using sudo dnf --enablerepo=*testing upgrade libxcrypt.

It would be nice to get some feedback here, whether the issue is really fixed with that update.

Anyways, users are required to have the libxcrypt-compat package installed, too. Preferrably before updating to the new build of libxcrypt, as the compat package will be updated automatically along.

zackw commented

It's starting to sound to me like libxcrypt-compat should be installed by default for fresh installs of, and upgrades to, Fedora 30.

It's starting to sound to me like libxcrypt-compat should be installed by default for fresh installs of, and upgrades to, Fedora 30.

Well, actually not, as the third-party rpm for gitlab should have automatically generated

Requires: libcrypt.so.1()
Requires: libcrypt.so.1(GLIBC_2.2.5)

which in turn would make the package manager (yum or dnf) to pull libxcrypt-compat.

If those requirements are not generated by rpmbuild, something is fishy with the spec file and/or the dependency generator has been disabled on purpose…

MartB commented

Thanks for fixing it, i will give it a try in a few hours.

Issue with that rpm is, that its not meant for fedora and theres no official fedora rpm atm.

You're welcome.

Anyways, even an rpm build on/targeting RHEL 7 / CentOS 7 should have these requires present and automatically generated, otherwise sth. is fishy.

Maybe you want to have look at COPR to deliver gitlab CE rpms for the various Fedora and/or RHEL / CentOS versions. It is less restrictive than official builds on Fedora infrastructure, e.g. allows for internet access during rpm builds to use pip or gem.

MartB commented

@besser82 Seems like the package did not reach updates-testing yet for fedora30, i can see it on a fedora 29 instance though. Do you mind making it available for f30?

Edit:
I found the package you build but it was not available in the repo using your command, weird stuff.

MartB commented

I can confirm that the upgrade to .2 fixed the issue, i am now able to log in to gitlab without any additional steps.

Thanks yet again.

@besser82 Seems like the package did not reach updates-testing yet for fedora30, i can see it on a fedora 29 instance though. Do you mind making it available for f30?

Edit:
I found the package you build but it was not available in the repo using your command, weird stuff.

The push to the f30 update-testing repo will be today around 0:00 to 3:00 UTC. Sometimes it takes a bit until the packages are pushed to the mirrors.

I can confirm that the upgrade to .2 fixed the issue, i am now able to log in to gitlab without any additional steps.

Thanks yet again.

Yay! =) I'll close here, then.