On 12/08/2011 03:34 PM, Dr. Stephen Henson wrote:
On Thu, Dec 08, 2011, Peter Sylvester wrote:

Hello,

I am actually makeing corrections to the SRP/TLS code. One of them
removes an unnecessary callback. There is a pointer in a SRP_CTX that
is no longer necessary.

I wonder what is the current policy concerning a stable branch and
the head? It seems that one simply would leave the useless pointer
in the stable branch and remove it from the head?

/* set SRP client username callback */
   char *(*SRP_TLS_ext_missing_srp_client_username_callback)(SSL *, void *);

The function can be deleted from HEAD and 1.0.1 as there haven't been any
stable releases from the 1.0.1 branch yet. Once 1.0.1 is released then changes
which would make 1.0.1a binary incompatible with 1.0.1 would be prohibited
unless there was a compelling reason to do so: e.g. it was essential to fix a
security problem.
Ok. Anyway, regarding the following, there is no problem at all since the
structures in question are not used directly by an application.


An additional snippet... there is a new experimental feature in 1.0.1 and
later which will make all SSL related structures opaque. If an application
compiles when OPENSSL_NO_SSL_INTERN is #defined it should be immune to any
changes in the SSL internals.

It is quite likely that we need some more functions for this to work with some
applications: any feedback would be welcomed so we can add them.
There are already a lot of special access functions to various data objects,
I wonder whether it wouldn't be better not to use functions but rather
a   CTRL function for setters, and one generic new INFO function
for getters. considering types, curl has a nice way to do handle them


The long term aim (quite possibly several years away) is to make this setting
the default.



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [email protected]
Automated List Manager                           [email protected]

Reply via email to