On Wed, 2016-02-17 at 17:43 +, Salz, Rich wrote:
> > It looks like we're in fairly good shape for the OpenSSL 1.1.0 release
> > to work "out of the box".
>
> That will be great.
>
> > I would like to see what we can do in the way of automated testing,
> > though. It should be possible to at
> It looks like we're in fairly good shape for the OpenSSL 1.1.0 release
> to work "out of the box".
That will be great.
> I would like to see what we can do in the way of automated testing,
> though. It should be possible to at least have Travis-CI make
> libcrypto.so for the Linux target,
On Tue, 2016-02-09 at 02:57 +, Long, Qin wrote:
> these two weeks.>
>
> David, I agree it's really horrid to include those _lcl.h to meet
> EDK2 API requirement. I am thinking it's better to re-design some
> APIs to align the new opaque structure style. E.g. replacing the
>
This has been fixed. Still some work to do for UEFI, but that will be separate
RT's and/or PR's.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
-
http://rt.openssl.org/Ticket/Display.html?id=3964
Please log in as guest
On Thu, 2016-02-04 at 03:04 +, Rich Salz via RT wrote:
> So guys, sorry for dropping the ball. Where are we on this now?
Dropping rt@ since the OPENSSL_NO_STDIO build is actually solved now so
RT#3964 looks like it can be closed. I'm choosing to interpret your
question in the wider sense of
On Thu, 2016-02-04 at 03:04 +, Rich Salz via RT wrote:
> So guys, sorry for dropping the ball. Where are we on this now?
I see four patches still at the top of
http://git.infradead.org/users/dwmw2/openssl.git but I've completely
forgotten.
I'll update and rebase my patches on both the
On Thu, 2016-02-04 at 03:04 +, Rich Salz via RT wrote:
> So guys, sorry for dropping the ball. Where are we on this now?
I see four patches still at the top of
http://git.infradead.org/users/dwmw2/openssl.git but I've completely
forgotten.
I'll update and rebase my patches on both the
On Thu, 2016-02-04 at 03:04 +, Rich Salz via RT wrote:
> So guys, sorry for dropping the ball. Where are we on this now?
Going backwards. I don't seem to be able to configure with
'no-ui no-engines' any more. :)
--
David WoodhouseOpen Source Technology Centre
So guys, sorry for dropping the ball. Where are we on this now?
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> 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:
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
On Wed, 2015-09-30 at 17:45 +, Kaduk, Ben via RT wrote:
> 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
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
On Wed, 2015-09-30 at 17:45 +, Kaduk, Ben via RT wrote:
> 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
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
On Wed, 2015-09-30 at 02:01 +, 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.
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
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
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
> 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
On Wed, Sep 30, 2015 at 02:01:54am +, 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
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
>>
On 30/09/15 10:22, Alessandro Ghedini via RT wrote:
> On Wed, Sep 30, 2015 at 02:01:54am +, 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_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
On Wed, 2015-09-30 at 11:19 +, 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
> 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
> 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
> 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
> 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.
> 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.
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
Please pull the following fixes from
git://git.infradead.org/users/dwmw2/openssl-nostdio.git
These are browsable in gitweb at
http://git.infradead.org/users/dwmw2/openssl-nostdio.git
This removes a number of functions which require file access, which is not
possible when OPENSSL_NO_STDIO
This is the full patch, in case that's easier to read.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
commit 422b63a1fd1f4ba6620429fa16cd995f6aff760c
Author: David Woodhouse
33 matches
Mail list logo
