On Tue, 2012-04-24 at 00:11 +0200, Andy Polyakov via RT wrote:
Per your suggestion, I replaced 16+9 with 16 and got the results
attached in the spreedsheet.
I can't read your spreadsheets, not this one nor one you've sent
earlier. It says file corrupted and fails to repair it. Could you
John Gardiner Myers via RT wrote:
There's no good reason for SSL_shutdown() to ever return a value of 0.
The attached patch simplifies things.
One point of view is:
Maybe so. But this is how it has always worked and is documented as
such. Your patch does not attempt to update the
John Gardiner Myers via RT wrote:
There's no good reason for SSL_shutdown() to ever return a value of 0.
The attached patch simplifies things.
One point of view is:
Maybe so. But this is how it has always worked and is documented as
such. Your patch does not attempt to update the
[openssl-dev@openssl.org - Wed Apr 25 00:33:54 2012]:
Hi,
1.0.0 had this:
/* SSL_OP_ALL: various bug workarounds that should be rather harmless.
* This used to be 0x000FL before 0.9.7. */
#define SSL_OP_ALL 0x8FFFL
1.0.1 now has:
On Wed, 2012-04-25 at 10:35 +0200, Andy Polyakov via RT wrote:
more secure protocols. Trade-off. As 1.0.0 application is not in
position to expect anything above TLS1.0, trade-off can as well be
resolved in favor of interoperability. Note that there is not such
trade-off in 1.0.1 application
[tm...@redhat.com - Wed Apr 25 12:10:34 2012]:
On Wed, 2012-04-25 at 10:35 +0200, Andy Polyakov via RT wrote:
more secure protocols. Trade-off. As 1.0.0 application is not in
position to expect anything above TLS1.0, trade-off can as well be
resolved in favor of interoperability. Note
On 4/25/2012 1:21 AM, Darryl Miles via RT wrote:
John Gardiner Myers via RT wrote:
There's no good reason for SSL_shutdown() to ever return a value of 0.
The attached patch simplifies things.
One point of view is:
Maybe so. But this is how it has always worked and is documented as
such.
About a year ago, building on some work by Yoni Londner, I posted some patches
to add more accurate debug information, mostly describing stack unwinding, to
the hand-optimized x86 assembly code. This is especially helpful when profiling
or debugging, since otherwise the debugger does not know
