bcrypt 3.1.15 failing on FreeBSD 12

[benpratt]

Metasploit just unlocked bcrypt after #217 was pulled. Unfortunately I am again getting an error when trying to install bcrypt 3.1.15.

Here's what I see when trying to 'bundle install':

--
Fetching bcrypt 3.1.15
Installing bcrypt 3.1.15 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

current directory: /tmp/bundler20200804-6811-ucupibcrypt-3.1.15/gems/bcrypt-3.1.15/ext/mri

/usr/local/bin/ruby26 -I /usr/local/lib/ruby/site_ruby/2.6 -r ./siteconf20200804-6811-wn0otw.rb
extconf.rb
creating Makefile

current directory: /tmp/bundler20200804-6811-ucupibcrypt-3.1.15/gems/bcrypt-3.1.15/ext/mri
make "DESTDIR=" clean

current directory: /tmp/bundler20200804-6811-ucupibcrypt-3.1.15/gems/bcrypt-3.1.15/ext/mri
make "DESTDIR="
compiling bcrypt_ext.c
compiling crypt_blowfish.c
cc -fPIC -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -fPIC -c
x86.S -o x86.o
compiling crypt_gensalt.c
compiling wrapper.c
wrapper.c:182:7: error: conflicting types for 'crypt_r'
char *crypt_r(const char *key, const char *setting, void *data)
^
/usr/include/unistd.h:499:7: note: previous declaration is here
char *crypt_r(const char *, const char *, struct crypt_data *);
^
1 error generated.
*** Error code 1

Stop.
make: stopped in /tmp/bundler20200804-6811-ucupibcrypt-3.1.15/gems/bcrypt-3.1.15/ext/mri

make failed, exit code 1

Gem files will remain installed in /tmp/bundler20200804-6811-ucupibcrypt-3.1.15/gems/bcrypt-3.1.15 for
inspection.
Results logged to
/tmp/bundler20200804-6811-ucupibcrypt-3.1.15/extensions/amd64-freebsd-12/2.6/bcrypt-3.1.15/gem_make.out

An error occurred while installing bcrypt (3.1.15), and Bundler cannot continue.
Make sure that gem install bcrypt -v '3.1.15' --source 'https://rubygems.org/' succeeds before
bundling.

In Gemfile:
metasploit-framework was resolved to 5.0.102, which depends on
bcrypt

It seems like a similar issue to #196.

[tosmi]

just a me too. tried to update a rails app from 3.1.13 to 3.1.15, and it seems to be broken again. confirmed that 3.1.13 compiles, 3.1.15 fails with the error above. i'm on freebsd 12.1-p8.

[glaszig]

same here.

current directory: /usr/home/starve/.gem/ruby/2.6/gems/bcrypt-3.1.15/ext/mri
/usr/local/bin/ruby26 -I /usr/local/lib/ruby/site_ruby/2.6 -r ./siteconf20200809-45681-1p5z07r.rb extconf.rb
creating Makefile

current directory: /usr/home/starve/.gem/ruby/2.6/gems/bcrypt-3.1.15/ext/mri
make "DESTDIR=" clean

current directory: /usr/home/starve/.gem/ruby/2.6/gems/bcrypt-3.1.15/ext/mri
make "DESTDIR="
compiling bcrypt_ext.c
compiling crypt_blowfish.c
cc -fPIC -O2 -pipe  -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  -fPIC   -c x86.S -o x86.o
compiling crypt_gensalt.c
compiling wrapper.c
wrapper.c:182:7: error: conflicting types for 'crypt_r'
char *crypt_r(const char *key, const char *setting, void *data)
      ^
/usr/include/unistd.h:499:7: note: previous declaration is here
char    *crypt_r(const char *, const char *, struct crypt_data *);
         ^
1 error generated.
*** Error code 1

Stop.
make: stopped in /usr/home/starve/.gem/ruby/2.6/gems/bcrypt-3.1.15/ext/mri

make failed, exit code 1

[glaszig]

#232 resolves the issue for me.

[jlduran]

This is a recurring issue. References:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212304#c5
#232
#188
#189

[michelboaventura]

I think de last argument's type is wrong. If you look at the documentation for crypt_r it should be struct crypt_data *, not void *. https://linux.die.net/man/3/crypt_r. If you change just this type it compiles both on FreeBSD and Linux.

[meanphil]

FYI - The Python bcrypt equivalent of this Gem dropped the OpenWall implementation for the OpenBSD one...

pyca/bcrypt#68

[benpratt]

I think de last argument's type is wrong. If you look at the documentation for crypt_r it should be struct crypt_data *, not void *. https://linux.die.net/man/3/crypt_r. If you change just this type it compiles both on FreeBSD and Linux.

@michelboaventura Could you create a pull request for this change? Maybe it'll get selected over #232 I'm not exactly sure what is the process for selecting which pull requests make it into a release.