[openssl.org #3964] Fix OPENSSL_NO_STDIO build

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[openssl.org #3964] Fix OPENSSL_NO_STDIO build

Rich Salz via RT
We fixed this in a slightly different way. We made BIO_new_file and BIO_s_file
return an alternate implementation that returns run-time failures. Almost all
of the OpenSSL code uses the BIO object, so we didn't have to remove that. We
did #ifdef out any routine that had a "FILE*" param or local variable.
--
Rich Salz, OpenSSL dev team; [hidden email]

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

Rich Salz via RT
On Wed, 2015-09-30 at 02:01 +0000, Rich Salz via RT wrote:
> We fixed this in a slightly different way. We made BIO_new_file and BIO_s_file
> return an alternate implementation that returns run-time failures. Almost all
> of the OpenSSL code uses the BIO object, so we didn't have to remove that. We
> did #ifdef out any routine that had a "FILE*" param or local variable.
> --
> Rich Salz, OpenSSL dev team; [hidden email]

If things like BIO_new_file() were inline, or macros, then the compiler
could *see* that they'd return NULL. And lots of code in the *calling*
functions (basically everything but the error path) could be elided
from the compiled result...

--
                  Sent with Evolution's ActiveSync support.

David Woodhouse                            Open Source Technology Centre
[hidden email]                              Intel Corporation







_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

Rich Salz via RT
In reply to this post by Rich Salz via RT
To question about OPENSSL_stderr() that was removed with "not used"
rationale. When it comes to a *library* you always run risk of finding
something that it not used by the library itself, something that is
meant to be used exclusively by somebody else's application. And
OPENSSL_stderr() is such thing. Well, for a Unix person it's really
meaningless function, but it was introduced to solve small but
irritating problem in FIPS module context on Windows.


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

Rich Salz via RT
In reply to this post by Rich Salz via RT
On Wed, Sep 30, 2015 at 02:01:54am +0000, Rich Salz via RT wrote:
> We fixed this in a slightly different way. We made BIO_new_file and BIO_s_file
> return an alternate implementation that returns run-time failures. Almost all
> of the OpenSSL code uses the BIO object, so we didn't have to remove that. We
> did #ifdef out any routine that had a "FILE*" param or local variable.

Note that commit 984d6c6 causes mingw shared builds to fail again:
https://travis-ci.org/openssl/openssl/jobs/82855661

The problem seems to be that entries 4991 and 4992 in libeay.num are used twice.

Since this is not the first time this happens, I was thinking that maybe having
a test for this would be useful.

Cheers


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

David Woodhouse-7
In reply to this post by Rich Salz via RT
See http://www.infradead.org/rpr.html


> To question about OPENSSL_stderr() that was removed with "not used"
> rationale. When it comes to a *library* you always run risk of finding
> something that it not used by the library itself, something that is
> meant to be used exclusively by somebody else's application. And
> OPENSSL_stderr() is such thing. Well, for a Unix person it's really
> meaningless function, but it was introduced to solve small but
> irritating problem in FIPS module context on Windows.


You'll note I left it well alone on my 1.0.2 backports; only changed it in
HEAD. If you want to keep it can we make it return a BIO? Many platforms
could use it then for serial debug output etc.


--
dwmw2

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

Rich Salz via RT
See http://www.infradead.org/rpr.html


> To question about OPENSSL_stderr() that was removed with "not used"
> rationale. When it comes to a *library* you always run risk of finding
> something that it not used by the library itself, something that is
> meant to be used exclusively by somebody else's application. And
> OPENSSL_stderr() is such thing. Well, for a Unix person it's really
> meaningless function, but it was introduced to solve small but
> irritating problem in FIPS module context on Windows.


You'll note I left it well alone on my 1.0.2 backports; only changed it in
HEAD. If you want to keep it can we make it return a BIO? Many platforms
could use it then for serial debug output etc.


--
dwmw2


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

Rich Salz via RT
> See http://www.infradead.org/rpr.html

Must be poor timing. First DNS took forever, then I get unable to
connect, connection time-outs...

>> To question about OPENSSL_stderr() that was removed with "not used"
>> rationale. When it comes to a *library* you always run risk of finding
>> something that it not used by the library itself, something that is
>> meant to be used exclusively by somebody else's application. And
>> OPENSSL_stderr() is such thing. Well, for a Unix person it's really
>> meaningless function, but it was introduced to solve small but
>> irritating problem in FIPS module context on Windows.
>
>
> You'll note I left it well alone on my 1.0.2 backports; only changed it in
> HEAD. If you want to keep it can we make it return a BIO? Many platforms
> could use it then for serial debug output etc.

BIO would be an overkill in the original context, i.e. in context for
irritating problem in FIPS module. But as current FIPS module is not
really supported option in HEAD and would need overhaul in either case,
let's let omission slide in HEAD. BTW, the comment was also meant to be
of a little bit more general character, i.e. just because something is
not used by the library itself, it doesn't have to be useless.


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

Matt Caswell-2
In reply to this post by Rich Salz via RT


On 30/09/15 10:22, Alessandro Ghedini via RT wrote:

> On Wed, Sep 30, 2015 at 02:01:54am +0000, Rich Salz via RT wrote:
>> We fixed this in a slightly different way. We made BIO_new_file and BIO_s_file
>> return an alternate implementation that returns run-time failures. Almost all
>> of the OpenSSL code uses the BIO object, so we didn't have to remove that. We
>> did #ifdef out any routine that had a "FILE*" param or local variable.
>
> Note that commit 984d6c6 causes mingw shared builds to fail again:
> https://travis-ci.org/openssl/openssl/jobs/82855661
>
> The problem seems to be that entries 4991 and 4992 in libeay.num are used twice.
>

Fixed:

https://github.com/openssl/openssl/commit/dd35486db671dca36caffecc7ee1f5f6483b3a4b

> Since this is not the first time this happens, I was thinking that maybe having
> a test for this would be useful.

Good idea:
https://github.com/openssl/openssl/commit/5530d5187c77877b610b11c4aadedd7107386afa

Matt


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

David Woodhouse-7
In reply to this post by Rich Salz via RT
On Wed, 2015-09-30 at 11:19 +0000, Andy Polyakov via RT wrote:
> > See http://www.infradead.org/rpr.html
>
> Must be poor timing. First DNS took forever, then I get unable to
> connect, connection time-outs...

Apologies. I'm travelling and in trying to avoid the mess of top-posted
HTML that would result from using the Android mailer, I was using
SquirrelMail. For reasons I will attempt to establish when I get home,
that results in a line of what *should* have been an RFC822 header,
being visible in the body of the email. Please ignore that.

(And yes, {ns1,www,ftp}.infradead.org is currently AWOL)

> BIO would be an overkill in the original context, i.e. in context for
> irritating problem in FIPS module. But as current FIPS module is not
> really supported option in HEAD and would need overhaul in either
> case,
> let's let omission slide in HEAD. BTW, the comment was also meant to
> be
> of a little bit more general character, i.e. just because something
> is
> not used by the library itself, it doesn't have to be useless.

I think my observation was more than "not used by the library itself".
It was also (in HEAD) not in an exported header file, and not
documented. And not actually used anywhere outside the FIPS module.

The BIO thing came to mind when fixing other no-stdio failures, with
code that thinks it's OK to fprintf(stderr, …). That code *could*
potentially use BIO_printf(OPENSSL_stderr(), …). Or could just be fixed
not to do that kind of thing at all.

--
dwmw2



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

Salz, Rich
In reply to this post by Rich Salz via RT

> If things like BIO_new_file() were inline, or macros, then the compiler could
> *see* that they'd return NULL. And lots of code in the *calling* functions
> (basically everything but the error path) could be elided from the compiled
> result...

Cool, will do that.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

Rich Salz via RT

> If things like BIO_new_file() were inline, or macros, then the compiler could
> *see* that they'd return NULL. And lots of code in the *calling* functions
> (basically everything but the error path) could be elided from the compiled
> result...

Cool, will do that.

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

Salz, Rich
In reply to this post by Rich Salz via RT
> OPENSSL_stderr() is such thing. Well, for a Unix person it's really meaningless
> function, but it was introduced to solve small but irritating problem in FIPS
> module context on Windows.

I removed it :)

Since 1.1 doesn't support FIPS, that's okay.  But we'll have something like that for stdin/stdout/stderr.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

Rich Salz via RT
> OPENSSL_stderr() is such thing. Well, for a Unix person it's really meaningless
> function, but it was introduced to solve small but irritating problem in FIPS
> module context on Windows.

I removed it :)

Since 1.1 doesn't support FIPS, that's okay.  But we'll have something like that for stdin/stdout/stderr.


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

Salz, Rich
In reply to this post by Rich Salz via RT

> If you want to keep it can we make it return a BIO? Many platforms could use
> it then for serial debug output etc.

That's what I'm going to do.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

Rich Salz via RT

> If you want to keep it can we make it return a BIO? Many platforms could use
> it then for serial debug output etc.

That's what I'm going to do.


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

Rich Salz via RT
In reply to this post by Rich Salz via RT
On 09/30/2015 10:12 AM, Salz, Rich via RT wrote:
>> If things like BIO_new_file() were inline, or macros, then the compiler could
>> *see* that they'd return NULL. And lots of code in the *calling* functions
>> (basically everything but the error path) could be elided from the compiled
>> result...
> Cool, will do that.
>
Making things inline functions or macros requires exposing their
implementation details to consumers of the header in question.  That
seems at odds with the goal of making structures opaque, though I don't
know whether making BIO opaque was one of the targets for that project.

-Ben


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

Salz, Rich
No, it's this
        #ifdef OPENSSL_NO_STDIO
        #define BIO_new_file(f,m) NULL
        #endif
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

Benjamin Kaduk
On 09/30/2015 12:53 PM, Salz, Rich wrote:
> No, it's this
> #ifdef OPENSSL_NO_STDIO
> #define BIO_new_file(f,m) NULL
> #endif
>

That looks like the library is conditionally exporting different symbols
depending on the build configuration, which I considered doing for my
work on OpenAFS but eventually decided that it would cause too many
problems and pulled out.  I guess this particular case might be
reasonable for UEFI use, but I am unconvinced that it's a good idea in
general.

-Ben
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

Salz, Rich
> That looks like the library is conditionally exporting different symbols
> depending on the build configuration

No more than any other compile-time control.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3964] Fix OPENSSL_NO_STDIO build

Benjamin Kaduk
On 09/30/2015 12:59 PM, Salz, Rich wrote:
>> That looks like the library is conditionally exporting different symbols
>> depending on the build configuration
> No more than any other compile-time control.
>

Okay, I guess you have convinced me, in that the ship has already sailed.

-Ben
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
12