Installation fails on OS X with clang-aliased gcc about lua-bcrypt HOT 26 CLOSED

Looks like this also affects gcc anyway. Thanks for bringing it up.

I don't have a Mac to test this on. Can you try building with the scm rockspec and let me know how it goes?

from lua-bcrypt.

I initially got the same output as above when installing through luarocks. Tried it with the SCM rockspec and got the output below saying it can't find lua.h:

Using https://raw.githubusercontent.com/mikejsavage/lua-bcrypt/master/rockspec/bcrypt-scm-1.rockspec... switching to 'build' mode
Cloning into 'lua-bcrypt'...
remote: Counting objects: 31, done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 31 (delta 9), reused 24 (delta 6)
Receiving objects: 100% (31/31), 30.84 KiB | 0 bytes/s, done.
Resolving deltas: 100% (9/9), done.
Checking connectivity... done.
Warning: variable CFLAGS was not passed in build_variables
export MACOSX_DEPLOYMENT_TARGET=10.5; gcc -O2 -shared -fPIC -std=c99 -D_GNU_SOURCE -Wall -Wextra -Wno-nonnull -Wwrite-strings -Wformat=2 -DNDEBUG -Ilib/bcrypt -bundle -undefined dynamic_lookup   -c -o src/main.o src/main.c
clang: warning: argument unused during compilation: '-shared'
clang: warning: argument unused during compilation: '-bundle'
clang: warning: argument unused during compilation: '-undefined dynamic_lookup'
src/main.c:6:10: fatal error: 'lua.h' file not found
#include <lua.h>
         ^
1 error generated.
make: *** [src/main.o] Error 1

Error: Build error: Failed building.

from lua-bcrypt.

The scm rockspec was missing a few lines. It should work now.

from lua-bcrypt.

The Makefile ifdef for Darwin also requires removal of '-shared' from CFLAGS.

It is unclear from the existing Makefile and the ifneq for Windows exactly what platforms should be supported, but the Darwin ifdef is slightly brittle - the problem probably occurs only on systems with gcc aliased to clang (was it OS X 10.6 or 10.7 when gcc was replaced by clang?). I don't have a system earlier than OS X 10.8 to test with.

from lua-bcrypt.

From the above outputs, it looks like clang ignores the -shared. Let me know if this is wrong and it actually does need removing.

The Windows check is there so we don't try to call uname on systems that definitely don't have it, but I guess it's pointless because it's almost certainly going to fail to build anyway.

Is not supporting older versions a problem? The impression I get, as someone who has never owned a Mac, is that everyone drops support for older releases very quickly.

from lua-bcrypt.

If it supports all the way up to Snow Leopard then it's probably fine to treat it like clang is the default going forward on OSX.

Building with the scm now yields:

Using https://raw.githubusercontent.com/mikejsavage/lua-bcrypt/master/rockspec/bcrypt-scm-1.rockspec... switching to 'build' mode
Cloning into 'lua-bcrypt'...
remote: Counting objects: 31, done.
remote: Compressing objects: 100% (24/24), done.
remote: Total 31 (delta 9), reused 24 (delta 4)
Receiving objects: 100% (31/31), 30.79 KiB | 0 bytes/s, done.
Resolving deltas: 100% (9/9), done.
Checking connectivity... done.
Warning: variable CFLAGS was not passed in build_variables
export MACOSX_DEPLOYMENT_TARGET=10.5; gcc -O2 -shared -fPIC -std=c99 -D_GNU_SOURCE -Wall -Wextra -Wno-nonnull -Wwrite-strings -Wformat=2 -DNDEBUG -Ilib/bcrypt -I/usr/local/opt/lua/include -bundle -undefined dynamic_lookup   -c -o src/main.o src/main.c
clang: warning: argument unused during compilation: '-shared'
clang: warning: argument unused during compilation: '-bundle'
clang: warning: argument unused during compilation: '-undefined dynamic_lookup'
make -C lib/bcrypt
export MACOSX_DEPLOYMENT_TARGET=10.5; gcc -c -W -Wall -Wbad-function-cast -Wcast-align -Wcast-qual -Wmissing-prototypes -Wstrict-prototypes -Wshadow -Wundef -Wpointer-arith -O2 -fomit-frame-pointer -funroll-loops -fPIC crypt_blowfish.c
crypt_blowfish.c:898:24: warning: cast from 'const char *' to 'const BF_word *' (aka 'const unsigned int *') increases required
      alignment from 1 to 4 [-Wcast-align]
        BF_encode(&output[7], (const BF_word *)input, 16);
                              ^~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
export MACOSX_DEPLOYMENT_TARGET=10.5; gcc -c x86.S
export MACOSX_DEPLOYMENT_TARGET=10.5; gcc -c -W -Wall -Wbad-function-cast -Wcast-align -Wcast-qual -Wmissing-prototypes -Wstrict-prototypes -Wshadow -Wundef -Wpointer-arith -O2 -fomit-frame-pointer -funroll-loops -fPIC crypt_gensalt.c
export MACOSX_DEPLOYMENT_TARGET=10.5; gcc -c -W -Wall -Wbad-function-cast -Wcast-align -Wcast-qual -Wmissing-prototypes -Wstrict-prototypes -Wshadow -Wundef -Wpointer-arith -O2 -fomit-frame-pointer -funroll-loops -fPIC wrapper.c
export MACOSX_DEPLOYMENT_TARGET=10.5; gcc -o bcrypt.so src/main.o lib/bcrypt/crypt_blowfish.o lib/bcrypt/x86.o lib/bcrypt/crypt_gensalt.o lib/bcrypt/wrapper.o -O2 -shared -fPIC -std=c99 -D_GNU_SOURCE -Wall -Wextra -Wno-nonnull -Wwrite-strings -Wformat=2 -DNDEBUG -Ilib/bcrypt -I/usr/local/opt/lua/include -bundle -undefined dynamic_lookup
clang: error: invalid argument '-bundle' not allowed with '-dynamiclib'
make: *** [bcrypt.so] Error 1

Error: Build error: Failed building.

I think I was able to get past this by taking away the -shared attribute, however I get this when I try to require("bcrypt")

lua: Bad entropy source
stack traceback:
    [C]: ?
    [C]: in function 'require'
    test.lua:1: in main chunk
    [C]: ?

In case it helps, I'm on Yosemite (10.10) right now.

from lua-bcrypt.

Ok, the make issues should be fixed.

That second one is because of some dumb checks I added after the urandom drama posts. At some point I would like to drop in arc4random and do things properly. For now, you can get by with compiling 1.4 with the new Makefile as that version doesn't bother with the checks.

from lua-bcrypt.

I found the motivation to finish my rewrite, which should literally both compile and work on OSX.

from lua-bcrypt.

Nice! Build works much better now, there are a few warnings about unknown pragma statements (which are posted below) that are probably not a big deal.

Running the example in the readme, the assertion now fails. Should this be it's own issue? I assume there are a few kinks that need to be ironed out with the rewrite. I'm able to run tests.lua, however that appears to use pre-made hashes. Will there still be an option to create a salt?

Warning: variable CFLAGS was not passed in build_variables
export MACOSX_DEPLOYMENT_TARGET=10.5; gcc -DOPENSSL_cleanse=explicit_bzero  -D__BSD_VISIBLE -DHAVE_STRNDUP -I/usr/local/opt/lua/include -Iinclude -Wall -Wno-pointer-sign -O2 -fPIC -DNDEBUG   -c -o compat/safebfuns.o compat/safebfuns.c
compat/safebfuns.c:11:17: warning: unknown pragma ignored [-Wunknown-pragmas]
                #pragma clang optimize off
                              ^
compat/safebfuns.c:103:16: warning: unknown pragma ignored [-Wunknown-pragmas]
        #pragma clang optimize on
                      ^
2 warnings generated.

from lua-bcrypt.

Those warnings may (depending on what clang feels like optimising) allow for:

• A timing attack to reveal information about the hash. This doesn't especially matter because they would have to brute force the hash if they did find it.
• Hashes/entropy buffers not being zeroed out after you use them. This also doesn't matter because Lua's interning is going to keep unhashed passwords in memory anyway, and ChaCha isn't a horrible RNG.

It's not something to worry about in the context of a bcrypt library. None of the previous versions even attempted to fix the above, and I would expect that most other bcrypt wrappers don't try either. Still, it would be nice to fix my bfuns library for other projects. What version of clang are you running?

The example was failing because I put the arguments in the wrong order. It's fixed now. :D

I don't think we should expose anything beyond generating/verifying hashes. Generating salts is an extra step to get wrong, and I can't think of any reason why someone would want to do it.

from lua-bcrypt.

Sounds good to me. Changed the arguments and the sample works now.

from lua-bcrypt.

What version of clang are you running? I'd be interested in seeing when #pragma clang optimize push got deprecated.

from lua-bcrypt.

From clang -v

Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

from lua-bcrypt.

Realized that verify seems to return true no matter what I pass to it:

local bcrypt = require( "bcrypt" )

-- Bigger numbers here will make your digest exponentially harder to compute
local log_rounds = 9

local digest = bcrypt.digest( "password", log_rounds )

assert( bcrypt.verify( digest, "pass") ) -- returns true

from lua-bcrypt.

Ack! Well spotted. I missed a !...

This means that the README did have the arguments in the right order originally. Not sure how I came to the conclusion that it was wrong.

from lua-bcrypt.

I'm not sure what to do about the pragmas either.

• I don't see any way of feature testing for it.
• Version number testing is unreliable because I don't know exactly when it got added and then changed, and you are running version 600(????)
• The llvm IRC channel is absolutely worthless
• The clang mailing list is broken

from lua-bcrypt.

Now it looks like old hashes are unverifiable.

edit: OpenBSD's bcrypt doesn't support 2x/2y hashes.

I think that 2b and 2y hashes are identical but if I make that assumption in the code and it turns out to be wrong, things could get messier. If I don't make that assumption, I can either revert to crypt_blowfish and try to shoehorn arc4random/explicit_bzero/etc in there, or declare 2.0 as entirely incompatible with previous versions.

edit2: crypt_blowfish treats 2b/2y in the same way and my library was never capable of creating 2x hashes, so I don't think it matters enormously if we can't verify them. It's a 1-liner to add 2y support, so I will go ahead and do that.

from lua-bcrypt.

Let's see if this goes anywhere!

from lua-bcrypt.

The latest commit should fix those warnings. Can you please test it?

from lua-bcrypt.

Output is now:

Warning: variable CFLAGS was not passed in build_variables
export MACOSX_DEPLOYMENT_TARGET=10.5; gcc -DOPENSSL_cleanse=explicit_bzero  -D__BSD_VISIBLE -DHAVE_STRNDUP -I/usr/local/opt/lua/include -Iinclude -Wall -Wno-pointer-sign -O2 -fPIC -DNDEBUG   -c -o compat/safebfuns.o compat/safebfuns.c
compat/safebfuns.c:14:4: error: "require clang with noinline and optnone attributes"
                #error "require clang with noinline and optnone attributes"
                 ^
compat/safebfuns.c:32:1: error: unknown type name 'NOOPT'
NOOPT NOINLINE void explicit_bzero( void * const buf, const size_t n ) {
^
compat/safebfuns.c:32:15: error: expected ';' after top level declarator
NOOPT NOINLINE void explicit_bzero( void * const buf, const size_t n ) {
              ^
              ;
compat/safebfuns.c:41:1: error: unknown type name 'NOOPT'
NOOPT NOINLINE int timingsafe_bcmp( const void * const b1, const void * const b2, const size_t n ) {
^
compat/safebfuns.c:41:15: error: expected ';' after top level declarator
NOOPT NOINLINE int timingsafe_bcmp( const void * const b1, const void * const b2, const size_t n ) {
              ^
              ;
compat/safebfuns.c:74:1: error: unknown type name 'NOOPT'
NOOPT NOINLINE int timingsafe_memcmp( const void * const b1, const void * const b2, const size_t len ) {
^
compat/safebfuns.c:74:15: error: expected ';' after top level declarator
NOOPT NOINLINE int timingsafe_memcmp( const void * const b1, const void * const b2, const size_t len ) {
              ^
              ;
7 errors generated.
make: *** [compat/safebfuns.o] Error 1

Error: Build error: Failed building.

from lua-bcrypt.

Looks like optnone only got added very recently then. How annoying.

Is it unreasonable to expect people to update their Clangs on OSX?

from lua-bcrypt.

Can you test again please? It shouldn't require bleeding-edge clang anymore.

from lua-bcrypt.

Now it's

Warning: variable CFLAGS was not passed in build_variables
export MACOSX_DEPLOYMENT_TARGET=10.5; gcc -DOPENSSL_cleanse=explicit_bzero  -D__BSD_VISIBLE -DHAVE_STRNDUP -I/usr/local/opt/lua/include -Iinclude -Wall -Wno-pointer-sign -O2 -fPIC -DNDEBUG -O0 -c -o compat/safebfuns.o compat/safebfuns.c
compat/safebfuns.c:14:4: error: "require clang with noinline and optnone attributes"
                #error "require clang with noinline and optnone attributes"
                 ^
compat/safebfuns.c:32:1: error: unknown type name 'NOOPT'
NOOPT NOINLINE void explicit_bzero( void * const buf, const size_t n ) {
^
compat/safebfuns.c:32:15: error: expected ';' after top level declarator
NOOPT NOINLINE void explicit_bzero( void * const buf, const size_t n ) {
              ^
              ;
compat/safebfuns.c:41:1: error: unknown type name 'NOOPT'
NOOPT NOINLINE int timingsafe_bcmp( const void * const b1, const void * const b2, const size_t n ) {
^
compat/safebfuns.c:41:15: error: expected ';' after top level declarator
NOOPT NOINLINE int timingsafe_bcmp( const void * const b1, const void * const b2, const size_t n ) {
              ^
              ;
5 errors generated.
make: *** [compat/safebfuns.o] Error 1

Honestly, I wouldn't worry about too much about those compiler warnings. I was posting those as an FYI as they don't seem crucial to fix.

from lua-bcrypt.

oops. This time it should work alright.

I added a rule to compile that file with -O0, which is what the NOOPT stuff is doing anyway. I just forgot to take out some of the preprocessor stuff which is making it die.

from lua-bcrypt.

Works much better now, no warnings. Tried everything and the library appears to be working fine on my Mac. Thank you :)

from lua-bcrypt.

Finally.

Thanks for all the feedback. Closing!

On Sun, Jan 04, 2015 at 04:36:05PM -0800, Zach wrote:

Works much better now, no warnings. Tried everything and the library appears to be working fine on my Mac. Thank you :)

---

Reply to this email directly or view it on GitHub:
#6 (comment)

from lua-bcrypt.