Bodo Moeller wrote:
Ideally this would be true, but in practice various applications do
access some fields directly.
The big change to stop that would be to move all the struct details
completely out of the externally visible header files. Of course, that
change too would be rather painful for such applications.
Which applications do you know about doing this ? are they public ?
Shouldn't there be something to take from that, if the existing APIs do
not provide enough feature coverage shouldn't those users be encouraged
to document their "use case" and provide application code "test cases"
where information is needed to allow somebody to understand and
implement suitable API.
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.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
