In message <CAH8yC8kKb=7SvEs687HL-mw7cbSe+oNw9=eld5jwx0tbxtb...@mail.gmail.com> on Sun, 27 Mar 2016 06:09:39 -0400, Jeffrey Walton <noloa...@gmail.com> said:
noloader> It looks like ordinals are changing and/or being removed for functions noloader> exported by the Windows DLL. Its causing pain points for users in the noloader> field, and it appears to be trending. Confer: noloader> noloader> * WAMP OpenSSL ordinal 372 error, http://stackoverflow.com/q/36238887 noloader> * The Ordinal 112 could not be located in dynamic link library…, noloader> http://stackoverflow.com/q/36163468 I sure hope noone is using OpenSSL 1.1.0 in production. The .num files were recreated entirely just before beta1. So, if we assume that this is about 1.0.2, this is what I can grep: : ; egrep '\s(112|372)\s' util/*.num util/libeay.num:BN_MONT_CTX_free 112 EXIST::FUNCTION: util/libeay.num:PEM_SealInit 372 EXIST::FUNCTION:RSA util/ssleay.num:SSLv23_server_method 112 EXIST::FUNCTION:RSA util/ssleay.num:SSL_CONF_cmd_argv 372 EXIST::FUNCTION: You notice the ":RSA" at the end? That means that if the library was created with the 'no-rsa' config option, those locations will be empty in the transfer table. I can't say for sure that's the case, but it's a possible lead to follow. Either way, it does seem to me that someone didn't keep the OpenSSL libraries in check, somehow. Btw, when it comes to OpenSSL 1.1.0, the DLLs have embedded version numbers in the file name. noloader> I think ordinals were meant to speed up loading of shared resources in noloader> the 16-bit Windows days. They fell out of favor circa Windows 95. noloader> According to Jeffrey Richter and in his book Programming Applications noloader> for Microsoft Windows, page 701 (http://www.amazon.com/dp/1572319968): noloader> noloader> The second form [of the function GetProcAddress] ... noloader> [and the] pszSymbolName parameter indicates the noloader> ordinal number of the symbol whose address you noloader> want... noloader> noloader> Again, let me reiterate that Microsoft strongly noloader> discourages the use of ordinals. noloader> noloader> Richter then goes on to discuss getting the wrong function address noloader> because ordinals have changed. noloader> noloader> It seems like the changes should have been caught in the engineering noloader> process during QA or testing. Perhaps an explicit step should be added noloader> to avoid the problems in the future? Possbly. Either way, it's a bit late in the game to make that change. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
