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

Reply via email to