OpenSSL version 1.1.0 pre release 3 published

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

OpenSSL version 1.1.0 pre release 3 published

openssl
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 1.1.0 pre release 3 (alpha)
   ===========================================

   OpenSSL - The Open Source toolkit for SSL/TLS
   http://www.openssl.org/

   OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 3 has now
   been made available. For details of changes and known issues see the
   release notes at:

        http://www.openssl.org/news/openssl-1.1.0-notes.html

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   The alpha release is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   http://www.openssl.org/source/mirror.html):

     * http://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.1.0-pre3.tar.gz
      Size: 5024305
      SHA1 checksum: 5b2257c1d7d8db6400c9951865bd7ef58dc758b3
      SHA256 checksum: bb0ead36155dcf6122bfb0555205ba562ad5a82bb6067f2bfc9111ca4a4e6442

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.1.0-pre3.tar.gz
    openssl sha256 openssl-1.1.0-pre3.tar.gz

   Please download and check this alpha release as soon as possible.
   Bug reports should go to [hidden email]. Please check the release
   notes and mailing lists to avoid duplicate reports of known issues.

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJWwhryAAoJENXp5D99+e6MnDwP/juSt7tF3GZRWnR9qVtJOOna
BI8xqEt18S0c396m51+kNJrZ6CMyPOLjA16Jwl+6YRdB634TlrVjxfbyTeMRKCjr
kXWloh/ntOSKEWUql7auJyMZYFnvHg+fwLWRBsmrqnoXmV6044tDIF168qW1i/Sm
9g0aCx2KIKyXkWZ6e6VXOzSIckCCQbzvxhgUAIAVRLTivOwQmCSVSnqI5XzNXhQR
Jm0j16ViMuHd1si/DsQDXtqFzygw6Gnh7IcLsC0S4DHcUKnli9mhcUk+AsiIqtAN
s5tYfZPzyoRbAgqrN4PDBaDMhSK6TFW7b5GmxJMjbEp1UFUxPO7XhyMg3OOL9kx3
MXpCvp7J+azvppXqFgcbRq097jRVv/eS45SA92y64ucZt0Wk6mdGIpD9UJQ6njxd
EiexAf3WwceLo8kxsBcIDayIzjb/HjqzUjHF2qcgfD0qQH19IYACVr2Mu4HyqDCx
GIx0IUg2oltjtynVkJeaTnoApgaUF5dPTgRLKyjir1gIYdquP0mEe35+3ubTNVci
n4X5FPog3U5lDHKMsHWywes8Gm8gynza6KxvaeIUTmQyWOIZwTMpvjKGuMMdyaH8
rEGJ8Xxv4WKmlJRKLrnU0KkICgEPT8sSNGQFABB4xLwxYGrHVOXVaZQ7FXvkEkZT
so0emsh4V0fnfx5rNuOX
=zaOF
-----END PGP SIGNATURE-----
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 3 published

Jouni Malinen-4
On Mon, Feb 15, 2016 at 07:04:20PM +0000, OpenSSL wrote:
>    OpenSSL version 1.1.0 pre release 3 (alpha)
>
>    OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 3 has now
>    been made available. For details of changes and known issues see the
>    release notes at:
>
>         http://www.openssl.org/news/openssl-1.1.0-notes.html

It looks like something in pre release 3 has changed behavior in a way
that results in SSL_CTX_new(SSLv23_method()) failing in some cases. I've
never seen this with earlier releases. It looks like the error within
SSL_CTX_new() is in EVP_get_digestbyname("ssl3-md5") returning NULL
suddenly after a process has called SSL_CTX_new() and SSL_CTX_free()
multiple times.

Based on a git bisect between OpenSSL_1_1_0-pre2 and OpenSSL_1_1_0-pre3
tags, it looks like the different behavior was triggered by commit
7fa792d14d06cdaca18f225b1d2d8daf8ed24fd7 ('Auto init/de-init libssl').
That does add a call to
OPENSSL_INIT_ssl_library_start(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL)
within SSL_CTX_new(), so I guess this is somehow messing up the
registered digests.

The program in question (wpa_supplicant) calls SSL_load_error_strings(),
SSL_library_init(), EVP_add_digest(EVP_sha256()),
EVP_add_cipher(EVP_rc2_40_cbc()), and PKCS12_PBE_add(), but commenting
these out did not change anything for the issue.

I could not find anything related to this in the release notes either.

Is this a bug somewhere in pre release 3 or is there supposed to be some
changes needed in applications using OpenSSL to work with this auto
init/de-init libssl change?
 
--
Jouni Malinen                                            PGP id EFC895FA
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 3 published

Matt Caswell-2


On 15/02/16 20:52, Jouni Malinen wrote:

> On Mon, Feb 15, 2016 at 07:04:20PM +0000, OpenSSL wrote:
>>    OpenSSL version 1.1.0 pre release 3 (alpha)
>>
>>    OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 3 has now
>>    been made available. For details of changes and known issues see the
>>    release notes at:
>>
>>         http://www.openssl.org/news/openssl-1.1.0-notes.html
>
> It looks like something in pre release 3 has changed behavior in a way
> that results in SSL_CTX_new(SSLv23_method()) failing in some cases. I've
> never seen this with earlier releases. It looks like the error within
> SSL_CTX_new() is in EVP_get_digestbyname("ssl3-md5") returning NULL
> suddenly after a process has called SSL_CTX_new() and SSL_CTX_free()
> multiple times.
>
> Based on a git bisect between OpenSSL_1_1_0-pre2 and OpenSSL_1_1_0-pre3
> tags, it looks like the different behavior was triggered by commit
> 7fa792d14d06cdaca18f225b1d2d8daf8ed24fd7 ('Auto init/de-init libssl').
> That does add a call to
> OPENSSL_INIT_ssl_library_start(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL)
> within SSL_CTX_new(), so I guess this is somehow messing up the
> registered digests.
>
> The program in question (wpa_supplicant) calls SSL_load_error_strings(),
> SSL_library_init(), EVP_add_digest(EVP_sha256()),
> EVP_add_cipher(EVP_rc2_40_cbc()), and PKCS12_PBE_add(), but commenting
> these out did not change anything for the issue.
>
> I could not find anything related to this in the release notes either.
>
> Is this a bug somewhere in pre release 3 or is there supposed to be some
> changes needed in applications using OpenSSL to work with this auto
> init/de-init libssl change?
>  
>
Do you call EVP_cleanup() at any point between creating the SSL_CTX objects?

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 version 1.1.0 pre release 3 published

Jouni Malinen-4
In reply to this post by Jouni Malinen-4
On Mon, Feb 15, 2016 at 10:52:27PM +0200, Jouni Malinen wrote:
> On Mon, Feb 15, 2016 at 07:04:20PM +0000, OpenSSL wrote:
> >    OpenSSL version 1.1.0 pre release 3 (alpha)

> It looks like something in pre release 3 has changed behavior in a way
> that results in SSL_CTX_new(SSLv23_method()) failing in some cases. I've
> never seen this with earlier releases. It looks like the error within
> SSL_CTX_new() is in EVP_get_digestbyname("ssl3-md5") returning NULL
> suddenly after a process has called SSL_CTX_new() and SSL_CTX_free()
> multiple times.

Found the trigger.. When adding and removing a network interface,
wpa_supplicant ends up going through OpenSSL library init and deinit.
One part of that deinit is a call to EVP_cleanup(). Init on the other
hand is calling SSL_library_init(). The difference between pre release 2
and 3 is in the SSL_library_init() call after EVP_cleanup() call not
adding back the needed digest registration.

Is this change in OpenSSL behavior expected? Is it not allowed to call
EVP_cleanup() and then re-initialize OpenSSL digests with
SSL_library_init()?

I can "fix" this by removing the EVP_cleanup() call in wpa_supplicant,
but that does not sound like the best thing to do here since it was
needed to avoid leaving allocated memory behind during process deinit
(i.e., getting memory leak reports from valgrind).

The way the ossl_init_ssl_base() function is "hidden" within
ssl_init.c, the application cannot even call it again, so other than
duplicating the contents of that function after that EVP_cleanup() call,
I don't see how this could be fixed cleanly without an OpenSSL change.

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

Re: OpenSSL version 1.1.0 pre release 3 published

Matt Caswell-2


On 15/02/16 21:25, Jouni Malinen wrote:

> On Mon, Feb 15, 2016 at 10:52:27PM +0200, Jouni Malinen wrote:
>> On Mon, Feb 15, 2016 at 07:04:20PM +0000, OpenSSL wrote:
>>>    OpenSSL version 1.1.0 pre release 3 (alpha)
>
>> It looks like something in pre release 3 has changed behavior in a way
>> that results in SSL_CTX_new(SSLv23_method()) failing in some cases. I've
>> never seen this with earlier releases. It looks like the error within
>> SSL_CTX_new() is in EVP_get_digestbyname("ssl3-md5") returning NULL
>> suddenly after a process has called SSL_CTX_new() and SSL_CTX_free()
>> multiple times.
>
> Found the trigger.. When adding and removing a network interface,
> wpa_supplicant ends up going through OpenSSL library init and deinit.
> One part of that deinit is a call to EVP_cleanup(). Init on the other
> hand is calling SSL_library_init(). The difference between pre release 2
> and 3 is in the SSL_library_init() call after EVP_cleanup() call not
> adding back the needed digest registration.
>
> Is this change in OpenSSL behavior expected? Is it not allowed to call
> EVP_cleanup() and then re-initialize OpenSSL digests with
> SSL_library_init()?

Correct, you cannot reinit once you have deinit.

>
> I can "fix" this by removing the EVP_cleanup() call in wpa_supplicant,
> but that does not sound like the best thing to do here since it was
> needed to avoid leaving allocated memory behind during process deinit
> (i.e., getting memory leak reports from valgrind).
>
> The way the ossl_init_ssl_base() function is "hidden" within
> ssl_init.c, the application cannot even call it again, so other than
> duplicating the contents of that function after that EVP_cleanup() call,
> I don't see how this could be fixed cleanly without an OpenSSL change.
>

You should not need to explicitly init or deinit at all. Try removing
all such calls. If you are getting memory leaks not caused by your
application then that is a bug in OpenSSL.

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 version 1.1.0 pre release 3 published

Jouni Malinen-4
On Mon, Feb 15, 2016 at 09:34:33PM +0000, Matt Caswell wrote:
> On 15/02/16 21:25, Jouni Malinen wrote:
> > Is this change in OpenSSL behavior expected? Is it not allowed to call
> > EVP_cleanup() and then re-initialize OpenSSL digests with
> > SSL_library_init()?
>
> Correct, you cannot reinit once you have deinit.

OK.. That used to work, though, so it would be good to mention this
clearly in the release notes since this can cause a difficult to find
issues for existing programs. Luckily I happened to have automated test
cases that found this now with wpa_supplicant.

> You should not need to explicitly init or deinit at all. Try removing
> all such calls. If you are getting memory leaks not caused by your
> application then that is a bug in OpenSSL.

I agree with the "should not need" part, but there is a reason why I
added those calls in the first place, i.e., these were needed with older
OpenSSL releases (well, all releases so far since 1.1.0 has not been
released). I guess I can remove these calls with #ifdef
OPENSSL_VERSION_NUMBER < 0x10100000L to maintain support for older
versions.

I'd also recommend updating EVP_cleanup man page to be clearer about
EVP_cleanup() being something that must not be called if there is going
to be any future calls to OpenSSL before the process exits.
 
--
Jouni Malinen                                            PGP id EFC895FA
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 3 published

Matt Caswell-2


On 15/02/16 21:50, Jouni Malinen wrote:

> On Mon, Feb 15, 2016 at 09:34:33PM +0000, Matt Caswell wrote:
>> On 15/02/16 21:25, Jouni Malinen wrote:
>>> Is this change in OpenSSL behavior expected? Is it not allowed to call
>>> EVP_cleanup() and then re-initialize OpenSSL digests with
>>> SSL_library_init()?
>>
>> Correct, you cannot reinit once you have deinit.
>
> OK.. That used to work, though, so it would be good to mention this
> clearly in the release notes since this can cause a difficult to find
> issues for existing programs. Luckily I happened to have automated test
> cases that found this now with wpa_supplicant.
>
>> You should not need to explicitly init or deinit at all. Try removing
>> all such calls. If you are getting memory leaks not caused by your
>> application then that is a bug in OpenSSL.
>
> I agree with the "should not need" part, but there is a reason why I
> added those calls in the first place, i.e., these were needed with older
> OpenSSL releases (well, all releases so far since 1.1.0 has not been
> released). I guess I can remove these calls with #ifdef
> OPENSSL_VERSION_NUMBER < 0x10100000L to maintain support for older
> versions.
>
> I'd also recommend updating EVP_cleanup man page to be clearer about
> EVP_cleanup() being something that must not be called if there is going
> to be any future calls to OpenSSL before the process exits.

Maybe EVP_cleanup() and other similar explicit deinit functions should
be deprecated, and do nothing in 1.1.0? The auto-deinit capability
should handle it. That way you would not need to do anything "special"
for 1.1.0 with "#ifdef" etc. What do you think?

If applications *must* do explicit cleanup they can always use the new
OPENSSL_cleanup() function (which is clear in the docs that you cannot
reinit afterwards).

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 version 1.1.0 pre release 3 published

Tomas Mraz-2
On Po, 2016-02-15 at 22:17 +0000, Matt Caswell wrote:

>
> On 15/02/16 21:50, Jouni Malinen wrote:
> > On Mon, Feb 15, 2016 at 09:34:33PM +0000, Matt Caswell wrote:
> > > On 15/02/16 21:25, Jouni Malinen wrote:
> > > > Is this change in OpenSSL behavior expected? Is it not allowed
> > > > to call
> > > > EVP_cleanup() and then re-initialize OpenSSL digests with
> > > > SSL_library_init()?
> > >
> > > Correct, you cannot reinit once you have deinit.
> >
> > OK.. That used to work, though, so it would be good to mention this
> > clearly in the release notes since this can cause a difficult to
> > find
> > issues for existing programs. Luckily I happened to have automated
> > test
> > cases that found this now with wpa_supplicant.
> >
> > > You should not need to explicitly init or deinit at all. Try
> > > removing
> > > all such calls. If you are getting memory leaks not caused by
> > > your
> > > application then that is a bug in OpenSSL.
> >
> > I agree with the "should not need" part, but there is a reason why
> > I
> > added those calls in the first place, i.e., these were needed with
> > older
> > OpenSSL releases (well, all releases so far since 1.1.0 has not
> > been
> > released). I guess I can remove these calls with #ifdef
> > OPENSSL_VERSION_NUMBER < 0x10100000L to maintain support for older
> > versions.
> >
> > I'd also recommend updating EVP_cleanup man page to be clearer
> > about
> > EVP_cleanup() being something that must not be called if there is
> > going
> > to be any future calls to OpenSSL before the process exits.
>
> Maybe EVP_cleanup() and other similar explicit deinit functions
> should
> be deprecated, and do nothing in 1.1.0? The auto-deinit capability
> should handle it. That way you would not need to do anything
> "special"
> for 1.1.0 with "#ifdef" etc. What do you think?

+1
I think this is "no brainer" change as the semantics of these functions
changed anyway due to the auto-initialization.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)



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

Re: OpenSSL version 1.1.0 pre release 3 published

David Woodhouse-7
In reply to this post by Matt Caswell-2
On Mon, 2016-02-15 at 22:17 +0000, Matt Caswell wrote:
>
> Maybe EVP_cleanup() and other similar explicit deinit functions should
> be deprecated, and do nothing in 1.1.0? The auto-deinit capability
> should handle it. That way you would not need to do anything "special"
> for 1.1.0 with "#ifdef" etc. What do you think?
>
> If applications *must* do explicit cleanup they can always use the new
> OPENSSL_cleanup() function (which is clear in the docs that you cannot
> reinit afterwards).

What about libraries?

If a library (or loadable plugin within an application) uses OpenSSL,
how should it clean up after itself?

It has no control over, and no visibility into, whether another library
or the application itself might subsequently use OpenSSL again.

Any cleanup function which, as a side-effect, means that nobody can
ever use OpenSSL for the remainder of the lifetime of the running
process, seems entirely broken.

--
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 (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 3 published

Viktor Dukhovni

> On Feb 16, 2016, at 11:17 AM, David Woodhouse <[hidden email]> wrote:
>
> If a library (or loadable plugin within an application) uses OpenSSL,
> how should it clean up after itself?

I must do nothing.  That's what auto-initialization is for.  It is
wrong for libraries to initialize OpenSSL, because that can't be
done safely.  So in libraries that use OpenSSL, no OpenSSL initialization,
and no cleanup.

--
        Viktor.

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

Re: OpenSSL version 1.1.0 pre release 3 published

Matt Caswell-2
In reply to this post by David Woodhouse-7


On 16/02/16 16:17, David Woodhouse wrote:

> On Mon, 2016-02-15 at 22:17 +0000, Matt Caswell wrote:
>>
>> Maybe EVP_cleanup() and other similar explicit deinit functions should
>> be deprecated, and do nothing in 1.1.0? The auto-deinit capability
>> should handle it. That way you would not need to do anything "special"
>> for 1.1.0 with "#ifdef" etc. What do you think?
>>
>> If applications *must* do explicit cleanup they can always use the new
>> OPENSSL_cleanup() function (which is clear in the docs that you cannot
>> reinit afterwards).
>
> What about libraries?
>
> If a library (or loadable plugin within an application) uses OpenSSL,
> how should it clean up after itself?
>
> It has no control over, and no visibility into, whether another library
> or the application itself might subsequently use OpenSSL again.
>
> Any cleanup function which, as a side-effect, means that nobody can
> ever use OpenSSL for the remainder of the lifetime of the running
> process, seems entirely broken.
>

The whole concept of a library cleaning up is broken. If a library
de-inits OpenSSL it cannot know if the application has finished using it
or not.

This is explicitly pointed out in the docs:

"The OPENSSL_cleanup() function deinitialises OpenSSL (both libcrypto
and libssl). All resources allocated by OpenSSL are freed. Typically
there should be no need to call this function directly as it is
initiated automatically on application exit. This is done via the
standard C library atexit function. In the event that the application
will close in a manner that will not call the registered atexit()
handlers then the application should call OPENSSL_cleanup() directly.
Developers of libraries using OpenSSL are discouraged from calling this
function and should instead, typically, rely on auto-deinitialisation.
This is to avoid error conditions where both an application and a
library it depends on both use OpenSSL, and the library deinitialises it
before the application has finished using it."

i.e. libraries should not explicitly deinit.

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 version 1.1.0 pre release 3 published

Jouni Malinen-4
In reply to this post by Matt Caswell-2
On Mon, Feb 15, 2016 at 10:17:15PM +0000, Matt Caswell wrote:

> Maybe EVP_cleanup() and other similar explicit deinit functions should
> be deprecated, and do nothing in 1.1.0? The auto-deinit capability
> should handle it. That way you would not need to do anything "special"
> for 1.1.0 with "#ifdef" etc. What do you think?

That may be a reasonable approach to avoid unexpected failures with
existing users. As far as wpa_supplicant is concerned, I ran quite a bit
of valgrind testing with the OpenSSL init/deinit calls commented out.
While I did find some memory leaks, those were not caused by the OpenSSL
library itself. As such, I've already added the #ifdef based on OpenSSL
version. This has the additional benefit of marking up code for cleanup
once OpenSSL 1.0.2 support terminates in the future.

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

Re: [openssl-users] OpenSSL version 1.1.0 pre release 3 published

Salz, Rich
In reply to this post by openssl

>    OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 3 has now
>    been made available. For details of changes and known issues see the
>    release notes at:

Just to emphasize one important point:  Our next release is planned to be Beta-1, in about a month.  After that, no new API's or features will be added to OpenSSL 1.1

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

Re: OpenSSL version 1.1.0 pre release 3 published

Howard Chu
In reply to this post by Viktor Dukhovni
Viktor Dukhovni wrote:

>
>> On Feb 16, 2016, at 11:17 AM, David Woodhouse <[hidden email]> wrote:
>>
>> If a library (or loadable plugin within an application) uses OpenSSL,
>> how should it clean up after itself?
>
> I must do nothing.  That's what auto-initialization is for.  It is
> wrong for libraries to initialize OpenSSL, because that can't be
> done safely.  So in libraries that use OpenSSL, no OpenSSL initialization,
> and no cleanup.
>
I like this direction, but is it actually stable? There are programs out there
that dynamically load and then unload modules repeatedly thru their life. We
see libldap getting loaded and unloaded this way a lot, and that naturally
means libssl/libcrypto go along for the ride too.

--
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 3 published

Viktor Dukhovni
On Tue, Feb 16, 2016 at 11:06:32PM +0000, Howard Chu wrote:

> >I[t] must do nothing.  That's what auto-initialization is for.  It is
> >wrong for libraries to initialize OpenSSL, because that can't be
> >done safely.  So in libraries that use OpenSSL, no OpenSSL initialization,
> >and no cleanup.
>
> I like this direction, but is it actually stable? There are programs out
> there that dynamically load and then unload modules repeatedly thru their
> life. We see libldap getting loaded and unloaded this way a lot, and that
> naturally means libssl/libcrypto go along for the ride too.

Nico Williams has some cool ideas for keeping a library from getting
unloaded, but regardless deinitialization is only for the application,
and only really to appease valgrind and the like.  

De-initialization is not intended to happen when the library gets
unloaded, Nico assures me that there's no safe way to do that, and
the only safe thing to do when a library is unloaded is to leak!
However, we may be able to arrange for the library to never be
unloaded once it is loaded and initialized.

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

Re: [openssl-users] OpenSSL version 1.1.0 pre release 3 published

Dmitry Belyavsky-3
In reply to this post by Salz, Rich
Dear Rich,


Just to emphasize one important point:  Our next release is planned to be Beta-1, in about a month.  After that, no new API's or features will be added to OpenSSL 1.1


If so, could you take a look at RT#4267?

Thank you!

--
SY, Dmitry Belyavsky

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