Bart, I was hoping to discuss with you on IRC; but, you're not online. On Sun, Apr 22, 2018, at 4:10 PM, Bart Van Assche wrote: > On 04/22/18 08:35, Keith Mendoza wrote: > > Bart, > > I was actually working on this yesterday. This is what I know so far after > > a few hours of digging into this: It appears that there's an issue with > > getting to the memory address that EVP_sha512() returns when it's called in > > sc_get_openssl_hashfn(). Why this is so, I don't know. Below are details of > > what I've figured out so far: > > > > On my environment, I'm using OpenSSL 1.0.2o installed using mac ports. > > EVP_sha512() simply returns the address of a static const struct env_md_st > > instance once you expand the EVP_MD typedef (see the source here: > > https://github.com/openssl/openssl/blob/3ce7bc40a3c48da1c96c2d04c10045bd797c6aa3/crypto/evp/m_sha1.c#L216). > > When I was stepping through using the lldb debugger, when I inspect the > > value of hashfn after the call to EVP_sha512() it actually reports an error > > that the address is inaccessible. That one's got me stumped. In line 192, > > the call EVP_DigestInit() happens and the address returned by EVP_sha512() > > is passed as the 2nd parameter to that function. Kaboom for obvious reasons. > > > > I'm no expert on the rules of accessing memory space from dynamic > > libraries. Hopefully, someone else can chime in. My next step is to write > > a small test program to isolate the digest initialization code to see if I > > can replicate the issue outside of Net-SNMP. > > Hello Keith, > > Can you have a look at the openssl/evp.h header file? The following > warning appears in the OS/X build output, which is suspicious: > > > scapi.c:88:12: warning: implicit declaration of function 'EVP_sha224' is > invalid in C99 [-Wimplicit-function-declaration] > return EVP_sha224(); > ^
I actually stumbled on include/net-snmp/system/darwin*.h files while figuring out why things are crashes when I thought that EVP_DigestInit() wanted a function pointer. I've used EVP_DigestInit_ex() in the past which would normally pass the address of EVP_*() functions as it's 3rd parameter. Since I wanted to assign the address of the functions in sc_get_openssl_hashfn() I got an undeclared error. Based on the comments on those files it feels like making sure that Net-SNMP doesn't try to use functions that are not present in the OpenSSL version available for the given macOS versions, I feel that should have been a function check in automake and sc_get_openssl_hashfn() whould have #ifdef HAVE_<funcname> on them instead. On another note, I thought that Net-SNMP has to use C89 thanks to Microsoft deciding they're not going to support anything past that? I feel mixing C versions between targets could cause us maintenance issues. > > Thanks, > > Bart. This is what I'm going to do: I'm going to add --with-cflags='-std=c89' in configureu and see if we stumbled on something that clang does differently with the ABI when its compiling in C99 vs C89. -- Thanks, Keith (pantherse) ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders