This doesn't seem to be the case any more.
Closing.
Matt
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1833
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Stephen Henson via RT wrote:
SSL structures should only ever be initialised by calling SSL_new().
Allocating and initialising an SSL structure manually in an application
is itself a very non-portable thing to do and requires setting of many
undocumented internal fields which will change across
Robin Seggelmann via RT wrote:
The latest patch was modified to maintain the previous values of new_session
for legacy applications. We can either break compatibility of a few
applications, if any, by adding a new field or by adding new values. I don't
see any possibility to avoid this at
On Sep 6, 2010, at 10:39 AM, Darryl Miles wrote:
The only user of these field(s) is libssl.so itself. The exact
meaning, usage and interpretation of the field(s) is a matter of
implementation detail which is encapsulated and presented to the
application via the document OpenSSL APIs.
On Sep 6, 2010, at 10:39 AM, Darryl Miles wrote:
The only user of these field(s) is libssl.so itself. The exact
meaning, usage and interpretation of the field(s) is a matter of
implementation detail which is encapsulated and presented to the
application via the document OpenSSL APIs.
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
[darryl-mailingli...@netbauds.net - Mon Sep 06 13:48:47 2010]:
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
[seggelm...@fh-muenster.de - Sun Sep 05 19:44:26 2010]:
The latest patch was modified to maintain the previous values of
new_session for legacy applications. We can either break
compatibility of a few applications, if any, by adding a new field
or by adding new values. I don't see
On 05.09.2010, at 02:08, Stephen Henson via RT wrote:
[seggelm...@fh-muenster.de - Mon Aug 30 16:26:24 2010]:
On Aug 27, 2010, at 2:32 PM, Stephen Henson via RT wrote:
[seggelm...@fh-muenster.de - Fri Aug 27 11:34:17 2010]:
Unfortunately, there was newer code which was not yet covered
[seggelm...@fh-muenster.de - Mon Aug 30 16:26:24 2010]:
On Aug 27, 2010, at 2:32 PM, Stephen Henson via RT wrote:
[seggelm...@fh-muenster.de - Fri Aug 27 11:34:17 2010]:
Unfortunately, there was newer code which was not yet covered by
the
patch. This caused an abbreviated
On Aug 27, 2010, at 2:32 PM, Stephen Henson via RT wrote:
[seggelm...@fh-muenster.de - Fri Aug 27 11:34:17 2010]:
Unfortunately, there was newer code which was not yet covered by the
patch. This caused an abbreviated handshake to fail.
Applied now, thanks.
Note that since we need to
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
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
[seggelm...@fh-muenster.de - Fri Aug 27 11:34:17 2010]:
Unfortunately, there was newer code which was not yet covered by the
patch. This caused an abbreviated handshake to fail.
Applied now, thanks.
Note that since we need to retain binary compatibility between 1.0.0 and
1.0.1 we will
Updated version. The variable new_session is now set during a full handshake as
before, to avoid breaking applications which access it directly instead using
SSL_renegotiate_pending() to determine whether a handshake is in progress.
--- ssl/d1_clnt.c 26 Jan 2010 19:46:29 -
Here is an up to date version of the patch for OpenSSL 1.0.1.
This patch adds the new variable 'renegotiate' to the SSL struct. Until now the
variable 'new_session' is used to indicate if a renegotiation is in progress
AND if a new session has to be created, i.e. a full handshake has to be
Updated version for compatibility with 1.0.0beta1:
--- ssl/d1_clnt.c 2008-06-02 00:33:24.0 +0200
+++ ssl/d1_clnt.c 2009-04-16 09:41:59.0 +0200
@@ -169,7 +169,7 @@
switch(s-state)
{
case SSL_ST_RENEGOTIATE:
-
Whenever a handshake is initiated, the variable s-new_session is set
to indicate that a handshake is being performed. This is not the
correct context because a handshake can also be abbreviated and will
not create a new session then. This variable is also used in the right
context to
18 matches
Mail list logo
