In message
on Sun, 27 Mar 2016 06:09:39 -0400, Jeffrey Walton 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_free112 EXIST::FUNCTION:
util/libeay.num:PEM_SealInit372
EXIST::FUNCTION:RSA
util/ssleay.num:SSLv23_server_method112
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