search

besser82 / libxcrypt

Extended crypt library for descrypt, md5crypt, bcrypt, and others
GNU Lesser General Public License v2.1
189 stars 52 forks source link

Unexpected issue with gitlabs (ruby bcrypt) implementation #88

Closed MartB closed 5 years ago

MartB commented 5 years ago

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

besser82 commented 5 years ago

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?

solardiz commented 5 years ago

Maybe related: https://github.com/codahale/bcrypt-ruby/pull/166#issuecomment-446703448

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 5 years ago

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.

besser82 commented 5 years ago

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.

besser82 commented 5 years ago

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 5 years ago

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

besser82 commented 5 years ago

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 5 years ago

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.

besser82 commented 5 years ago

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 5 years ago

@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 5 years ago

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 commented 5 years ago

@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.