> [darryl-mailingli...@netbauds.net - Mon Sep 06 13:48:47 2010]: > > The suggestion I have thrown in, will not alter the meaning of the > lowest 2 bits of ssl_st.new_session (between older versions of OpenSSL > and future versions of OpenSSL). So it would be possible for a user > doing this to write code that works for all versions of OpenSSL alike > (all versions that have ssl_st.new_session at least). > > The suggestion I have thrown in will not affect anybody who is using > OpenSSL in a portable way (I think we should have more consideration for > those users, than those who access internal structures directly). > > > The choice: > > * Enlarge the structure and cause breakage for all users of OpenSSL > that allocate a storage in the application for struct ssl_st (affecting > both: the group that uses the documented APIs and the group that uses > undocumented direct access to internal structure) > > * Modify the purpose of some of the bits in ssl_st.new_session. This > change only affects the group of users that access internal structures > directly and only if they happen to access the "new_session" member > itself. However the proposed way forward will allow them to fix their > code in such a way that same code will work with version 1.0.0 at > runtime alike. > > > I see the "modify the purpose" option as affecting the least number of > users. >
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? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
