[openssl-dev] [openssl.org #4156] Wrong expectation of value of _IOB_ENTRIES with Visual Studio 2015

[Hannes Mezger via RT]

Hi,

thanks for the detailed explanation. We can change our code to use the
BIO-functionality instead of using FILE pointers, so far this works fine
and even simplifies our code.

But two issues remain:

1. There is still no explanation on why it worked fine with Visual
Studio 2005 - 2013 (yes, checked all of those). To me it seems that the
code either doesn't handle the changed _IOB_ENTRIES correctly or is not
prepared to work with the new Windows 10 SDK.

2. The more important issue: we use 'ERR_print_errors_fp(stderr)' to
print OpenSSL errors directly to stderr. This doesn't work, too. But it
can't be fixed by using the 'ERR_print_errors()' function instead, as
creating the BIO using 'BIO_new_fp(stderr, BIO_NOCLOSE)' also fails with
the same error (no Applink). Is there a recommentation what to use in
that case?

Best regards,

Hannes

*Hannes Mezger*
ascolab GmbH
Tel.: +49 9131 691 124
Fax: +49 9131 691 128
Web: http://www.ascolab.com
GPG-KeyId: 46EC1280
GPG-Fingerprint: D28A DE55 05FA 2FF3 8628 323A 1D6E 9EC8 46EC 1280

--
ascolab GmbH - Am Weichselgarten 7 - 91058 Erlangen - Germany
Handelsregister/Commercial Register: Amtsgericht Fürth HRB 9360
Geschäftsführer/Managing Directors: Gerhard Gappmeier, Matthias Damm,
Uwe Steinkrauß
This email contains confidential information and is for the exclusive
use of the addressee. If you are not the addressee, then any
distribution, copying or use of this email is prohibited. If received in
error, please advise the sender and delete immediately. We accept no
liability for any loss or damage suffered by any person arising from use
of this email.

Am 05.12.2015 um 11:13 schrieb Andy Polyakov via RT:
> Hi,
>
>> when using OpenSSL (1.0.1p) in our applications, we get the error 'No
>> OPENSSL_Applink' when calling PEM_read_X509_CRL. We build both OpenSSL
>> and the application using the same C runtime configuration (/MDd), using
>> Visual Studio 2015 on Windows 10.
> Original intention with OPENSSL_Applink was to facilitate certain things
> for old code. This kind of implies that new code should be written in
> such manner that would *avoid* Applink. For this reason I would
> recommend to modify application and switch to PEM_read_bio_X509_CRL. But
> the keyword is that you should let OpenSSL open the file for you by
> calling BIO_new_file. As opposite to opening yourself and calling
> BIO_new_fp that is.
>
>> After some hours of debugging and comparing with the same scenario using
>> Visual Studio 2010, I discovered that _IOB_ENTRIES is defined
>> differently in the two versions of Visual Studio:
>>
>> VS2015: c:\Program Files (x86)\Windows
>> Kits\10\Include\10.0.10150.0\ucrt\stdio.h: #define _IOB_ENTRIES 3
>> VS2010: c:\Program Files (x86)\Microsoft Visual Studio
>> 10.0\VC\include\stdio.h: #define _IOB_ENTRIES 20
>>
>> Now there's code in openssl-1.0.1p\crypto\bio\bss_file.c that seems to
>> expect _IOB_ENTRIES to have the value 20:
>>
>> #   if defined(__MINGW32__) && defined(__MSVCRT__) && !defined(_IOB_ENTRIES)
>> #    define _IOB_ENTRIES 20
>> #   endif
>> #   if defined(_IOB_ENTRIES)
>>         /* Safety net to catch purely internal BIO_set_fp calls */
>>         if ((size_t)ptr >= (size_t)stdin &&
>>             (size_t)ptr < (size_t)(stdin + _IOB_ENTRIES))
>>             BIO_clear_flags(b, BIO_FLAGS_UPLINK);
>> #   endif
>> #  endif
>> #  ifdef UP_fsetmod
>>         if (b->flags & BIO_FLAGS_UPLINK)
>>             UP_fsetmod(b->ptr, (char)((num & BIO_FP_TEXT) ? 't' : 'b'));
>>         else
>> #  endif
>>
>> The 'safety net' does not work here, as _IOB_ENTRIES is too small in
>> VS2015 and the flags don't get cleared (as for VS2010), so UP_fsetmod is
>> being called which leads to the 'No OPENSSL_Applink' error.
> Well, commentary is probably misleading in the context, because "purely
> internal BIO_set_fp" refers to BIO_set_fp called with FILE * created
> internally, rather than just any BIO_set_fp called internally. So that
> if application passes FILE * it created itself, it should expect UPLINK
> calls. The fact that it worked for you without applink.c in VS2010 is
> circumstantial.
>
>> We kindly ask you to provide a solution for our problem, as we currently
>> are not able to use OpenSSL in combination with VS2015. Linking the
>> applink.c into our applications is no option for us, as we would have to
>> deploy multiple C runtimes (one for OpenSSL and one for the application).
> Last sentence is false in sense that linking applink.c into application
> does *not* force you into using multiple C runtimes. It allows to use
> multiple runtimes, but does not prohibit/prevent using single one. In
> other words if this is the only reason for not linking the applink.c,
> then it should be disregarded. But, once again, the right thing to do is
> to adhere to PEM_read_bio_X509_CRL. This applies to all interfaces that
> accept FILE *.
>
>