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
