Stephen Henson via RT wrote:
SSL structures should only ever be initialised by calling SSL_new().
Allocating and initialising an SSL structure manually in an application
is itself a very non-portable thing to do and requires setting of many
undocumented internal fields which will change across major versions.
Are you aware of any applications that do that?
Yes I agree with this too.
In the case of (struct ssl_st) from what I have seen the storage and
initialization of it is managed wholly by libssl.
But given the choice of using some unused bits of ssl_st.new_session or
extending the size of the struct.
Maybe some guidelines should be stated in the ssl(3) man page (where
types are discussed).
* That storage of the X,Y and Z struct types should be managed by
libssl. A portable application should not attempt to allocate storage,
initialize types, modify types or deallocate storage directly from
bespoke application code. A portable application is expected to make
use of the OpenSSL API for these purposes.
* However should an application find itself needing to access data
from internal OpenSSL types directly. That application should not
expect other versions of OpenSSL to be compatible and must review that
access with every OpenSSL release they consume. It would be desirable
if such application developers could submit a usage case to the
openssl-dev mailing list so that wider understanding of this behavior
with a view that additional API coverage to support that case.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org