On Sat, 13 Oct 2018 at 23:37, William A Rowe Jr <[email protected]> wrote: > > On Sat, Oct 13, 2018 at 2:06 PM Ivan Zhakov <[email protected]> wrote: >> >> On Sat, 13 Oct 2018 at 20:00, Gregg Smith <[email protected]> wrote: >>> >>> On 10/13/2018 8:32 AM, William A Rowe Jr wrote: >>> > Sorry, I don't understand. >>> > >>> > Gregg, can you shed some insight here? For both, applink.c is helpful if >>> > the OpenSSL .dll files are created with a different VC compiler than >>> > abs.exe was compiled with. >>> >>> Not true, OSSL 1.0.2 I know from experience if applink.c is not included >>> it will still err even if both ab.c & OSSL are compiled with the same VC >>> version (14 & 15). I never tested 1.1.0. >>> >> That's true: since OpenSSL 1.0.2 applink.c is required even if OpenSSL и >> application uses same VC toolchain. > > > That's very interesting, not observed here. Second request... pointers please?
https://github.com/openssl/openssl/blob/32f803d88ec3df7f95dfbf840c271f7438ce3357/NOTES.WIN#L137: [[[ If you link with OpenSSL .DLLs, then you're expected to include into your application code small "shim" snippet, which provides glue between OpenSSL BIO layer and your compiler run-time. See the OPENSSL_Applink manual page for further details. ]]] In case of abs.exe problem is triggered by call to BIO_new_fp() which sets flag BIO_FLAGS_UPLINK [1]. Then BIO_read() invokes UP_fread() try to find OpenSSL_AppLink in the application module (!) and aborts if function is not found. [1] https://github.com/openssl/openssl/blob/32f803d88ec3df7f95dfbf840c271f7438ce3357/crypto/bio/bss_file.c#L103 > > I'm strongly suspecting an /MD /MT mismatch. I only build the 'ntdll' style > of OpenSSL, and never bother to mix linkage models or build abs.c static > against openssl etc. Or perhaps this speaks to specific, buggy releases of > 1.0.2? > > [Something for the audience; applink.c redirects all of the "standard c > library" API's used by OpenSSL into the flavor in use by the version of the > MSVC runtime linked to the primary .exe file. And in it's absence, the flavor > OpenSSL was built against. Why we almost never care? These apply to basic > input/output, the BIO layer of OpenSSL, which mod_ssl hardly touches. But > apps using classic C stdio functionality like ab.c care a great deal. Which > leads us to Ivan's comment;] > >> >> Alternative solution to including applink.c could stop using OpenSSL APIs >> that uses stdio and provide APR based BIO implementation. In this case >> OpenSSL will never use stdio functions. > > > Indeed! That's a complete solution. But a lot of effort if Boring/Libre/etc > "just work" and only OpenSSL falls down on doing the simplest BIO functions. > I'd have to fault OpenSSL, and not promote workarounds. Again I need some > citations about the "defect" which makes zero sense here. > >> It would also support building mod_ssl with OpenSSL compiled with option >> --no-stdio. > > > Indeed, I'm shocked if we can't build mod_ssl with --no-stdio today! Those > would be some odd quirks in mod_ssl/openssl (discounting ab.c)... but that's > certainly another thread. It seems like a worthwhile goal, nothing should > speak stdio within mod_ssl's structure. > -- Ivan Zhakov
