Changing the movzwl to movzbl in bn_get_bits5 eliminates the valgrind
error. But this isn't a valid fix since bn_get_bits5 no longer returns
the correct data. My assembly skills are near nil. Maybe someone else
can propose a valid fix.
Having said this, this does show the problem
Thanks for the timely response... below is version we are using. I
also must point out that we are currently using 0.9.8g for several
years, I tried to upgrade to .9.8zf, and several 1.0.x versions and
had the same error. The ./Configure solaris-x86-cc was used to
install openssl.
But the
Andy Polyakov ap...@openssl.org writes:
Changing the movzwl to movzbl in bn_get_bits5 eliminates the valgrind
error. But this isn't a valid fix since bn_get_bits5 no longer returns
the correct data. My assembly skills are near nil. Maybe someone else
can propose a valid fix.
Having
On 18/05/15 23:58, George Wang wrote:
The variable causing problem is
tot = 32768
tot should be less than len, while, len = 332
analyzing the code change between 1.0.1m and 1.0.2a, the following code
should be the source of the problem,
/*
* first check if there is a
Objective also is to pinpoint the problem to specific algorithm on
specific platform. Mentioning two distinct platforms running different
versions, like SPARC running 1.0.2 and x86 0.9.8g, does not make things
clearer. You have to present evidence that directly supports given
assumption, i.e.
Hi Harri,
We've compared the code coverage of the tests between the 1.0.2a release
and today's master state: it rose from 28.1% to 29.6%!
I believe you did that by using your internal commercial product by Froglogic…
Any good free software alternative out there?
Thanks,
- Andrejs
On
I don't think its optimizing it out I agree with you, but your
suggested change resolved the error so Wim was right about it being
undefined behaviour, and the tool which uses clang 3.4 was warning us
about that.
I added my own debugging statement and ran ectest and it is indeed
undefined
I am reattaching previous communication for reference.
1) They are not two different platforms, merely same command executed for 2
different versions of openssl.. please see attachment 1 below. It is possible
that 1.0.2a was configured use config where openssl picked defaults and 0.9.8g
was
Saw this one after responding to the later one.
I have already tried using gcc instead cc to rule out compiler bug but only on
server program. I will install openssl using gcc and dropping optimization.
Will also verify that server/client programs are not optimized.
Thanks
Shailender
I am reattaching previous communication for reference.
1) They are not two different platforms, merely same command executed for 2
different versions of openssl.. please see attachment 1 below. It is possible
that 1.0.2a was configured use config where openssl picked defaults and 0.9.8g
was
Saw this one after responding to the later one.
I have already tried using gcc instead cc to rule out compiler bug but only on
server program. I will install openssl using gcc and dropping optimization.
Will also verify that server/client programs are not optimized.
Thanks
Shailender
Hello,
i've just read on the Lynx list about compilation error because of
a missing SSLv23_method() and indeed [1] says it is deprecated and
a new TLS_client_method() is to be used instead. Now i've
searched on Gmane but i couldn't find just any word. (Let's just
hope that there will be TLS
On Tue, May 19, 2015 at 05:03:12PM +0100, Matt Caswell wrote:
No. The change is not a property of the version number.
I have OpenSSL 0.9.7 (plus patches...) without SSLv{2,3}.
Index: HTTP.c
===
RCS file:
Kurt Roeckx k...@roeckx.be wrote:
|I think that we should just provide the SSLv23_client_method define
|without the need to enable something, and I guess I missed
|something during the review in that case.
Thanks for the clarification.
--steffen
___
Version: 1.0.1f to 1.0.2a
OS: Linux/Ubuntu (not relevant)
Type: enhancement request
Hello,
First here is the setup I'm confronted with (not mine just have to work
with it) :
Root
CA
On 19/05/15 16:28, Steffen Nurpmeso wrote:
Hello,
i've just read on the Lynx list about compilation error because of
a missing SSLv23_method() and indeed [1] says it is deprecated and
a new TLS_client_method() is to be used instead. Now i've
searched on Gmane but i couldn't find just any
Found by the https://github.com/xiw/stack tool and then I checked the
generated asm (gcc and clang) to confirm.
In the check if (d0 tmp_ulong) tmp_ulong always evaluates to true
because the compiler optimizes out the tmp_ulong value to true because
(tmp_ulong = zz d1;) zz d1 has according
Matt Caswell wrote:
I just posted the following to lynx-dev:
I didn't get that post.
The OP suggested this:
+#if (OPENSSL_VERSION_NUMBER = 0x1010L)
+ ssl_ctx = SSL_CTX_new(TLSv1_client_method());
+#else
ssl_ctx = SSL_CTX_new(SSLv23_client_method());
+#endif
This is not
Steffen Nurpmeso sdao...@yandex.com wrote:
|Kurt Roeckx k...@roeckx.be wrote:
||I think that we should just provide the SSLv23_client_method define
||without the need to enable something, and I guess I missed
||something during the review in that case.
|
|Thanks for the clarification.
Ehm,
On Tue, May 19, 2015 at 08:03:05PM +0200, Steffen Nurpmeso wrote:
Steffen Nurpmeso sdao...@yandex.com wrote:
|Kurt Roeckx k...@roeckx.be wrote:
||I think that we should just provide the SSLv23_client_method define
||without the need to enable something, and I guess I missed
||something
20 matches
Mail list logo
