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
