Robin Seggelmann via RT wrote:
Note that since we need to retain binary compatibility between 1.0.0 and
1.0.1 we will need to either avoid having to add a new field to ssl.h or
move it to the end of the structure.
As things are any application accessing a field after the new member
would misbehave.
Can you cite the mechanism via which an application achieves this
(misbehaving) ?
Do you need a patch which moves the "int renegotiate;" to the end of the struct
for 1.0.1?
Which internal members of the openssl/ssl.h (struct ssl_st) are visible
outside of the OpenSSL implementation (i.e. by the application) ?
My understanding is that providing there are no macro's directly
accessing members of the struct from application code the order issue is
moot.
If the application programmer has read ssl.h and decided he is going to
access internal members of (struct ssl_st) directly, when it has not
been documented as safe to do so; should he not be left to burn ?
If there are functions/macros/mechanisms that can be compiled into
application code which do access and expect structure members to be at
specific offsets, WHY IS THIS THE DEFAULT ANYWAY ? i.e. why doesn't the
application programmer have to define some
-DOPENSSL_UNSAFE_DIRECT_ACCESS disable those accesses that indirect
through a function (inside the OpenSSL implementation library) to those
implemented as macros and therefore embedded inside applications.
But first please confirm the API calls "put at risk" with you concern
with this patch/feature.
A larger concern to me is the increasing of the size of the (struct
ssl_st) a matter you seem to place at a lower priority than struct
member order.
If it is possible and accepted usage that an application might allocate
a fixed amount of storage, such as static global variables, local stack
variables, embedding the (SSL) inside another application defined struct
and use of sizeof(SSL).
If this is a concern might it be useful to both:
* Implement an API call that allows an application program to check
the sizeof(SSL) it was compiled with against the runtime libraries
implementation size (preferably in a convenient way, mostly assisted by
header files and man page copy'n'paste snippet with a view of being
future proof).
* Reserve some extra headroom in the struct, if you think you need to
increase the size during the lifetime of the ABI compatibility you wish
to retain.
* Document any restriction placed on the programmer when using the
library. For example if storage for a specific type is not to be
allocated statically (at compiled time).
If you increase the size of the struct those applications that do
allocate a fixed amount of storage based on openssl-1.0.0 will find that
the OpenSSL library is scribbling on memory when it accesses the
locations at the highest offsets of the new larger structure.
The application will not have allocated quite enough memory and so
random problems will occur.
Can I suggest you combine the storage area used by these flags so no
size increase is necessary. The extra instruction Logical And/Or
masking of a register value can be done very cheaply and the patch does
not appear to affect any critical performance path with bulk transfer.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
