On 11 June 2014 06:47, Otto Moerbeek o...@drijf.net wrote:
On Tue, Jun 10, 2014 at 11:35:06PM +0100, Matt Caswell wrote:
On 10 June 2014 21:52, Kurt Roeckx k...@roeckx.be wrote:
As far as I can see this is SSLv3 only, and only about the Finish
message.
So it seems that function return
Geoff,
we did not seem to be able to figure out what openssl Makefile actually builds
crypto/threads/th-lock.c
In our particular case we explicitly included that file when building our
server, but for “pure” OpenSSL, what make includes th-lock.c ?
Igor.
From:
On Tue, Jun 10, 2014 at 3:27 PM, Levin, Igor ile...@akamai.com wrote:
Geoff,
we did not seem to be able to figure out what openssl Makefile actually
builds crypto/threads/th-lock.c
In our particular case we explicitly included that file when building our
server, but for
...
Can you confirm that this resolves your problem:
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=5a0d057e49a6f7b5ee5ff6f8af5ae395abc7b918
...
I applied that patch, which corrected the problem on IRIX and didn't
break anything on the other OSes I build on.
Thanks,
Pieter
Hello everyone!
Discovered this problem while trying to fix
https://github.com/joyent/node/issues/7704.
Attached is a fix for it.
Cheers,
Fedor.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- From c6a4d5ff66cd886023f75780e876053f019ed8de Mon Sep 17 00:00:00 2001
From: Fedor Indutny
Discovered after configuring for Android x86 with -no-comp option.
The best I can tell, openssl/comp.h is not even needed for the enc
program. However, this is the probably the least intrusive change.
diff --git a/apps/enc.c b/apps/enc.c
index d84c51d..9cdbc57 100644
--- a/apps/enc.c
+++
It's a thread from a few months ago. OpenSSL needs to establish a default thread model in many cases.
The one we (IBM) hit is composite apps. Multiple independently developed lumps of code thrown together - someone has to set the locks, but deciding who is a problem. We deal with it easily as we
On 06/10/2014 03:31 PM, Bodo Moeller wrote:
The way we use the locks, in heavily multi-threaded applications, you
can have a lot of contention with mutexes that wouldn't exist with
read/write locks, because often all threads would only require the read
locks
What kinds of operations are
On 06/11/2014 10:24 AM, Peter Waltenberg wrote:
The one we (IBM) hit is composite apps. Multiple independently developed
lumps of code thrown together - someone has to set the locks, but
deciding who is a problem. We deal with it easily as we put a wrapper
around OpenSSL and do it there, but
What kinds of operations are protected by read locks?
Looking at almost any of the global data structures, such as error tables, OID
tables, and so on.
Often, RW locks aren't a win because maintaining just the read locks (without
any writers) introduces contention at the hardware level, and
Hi guys,
I know 0.9.7 is no longer under development, but for various reasons, I have an
app that is still using 0.9.7g.
Is 0.9.7g subject to the vulnerability from CVD-0214-0224?
Thanks,
ScottN
__
OpenSSL Project
Re- Often, RW locks aren't a win because maintaining just the read
locks (without any writers) introduces contention at the hardware level, and
parallelism does not increase all that much as a result. - Yes, RWlock has a
small price compared to no lock (it still stays in user space
Closing this ticket. Patch has been reported as working.
Matt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List
Hello,
Please see related RT openssl.org #3387
Error: Null pointer dereference (CWE 476)
Read from null pointer rctx
at line 114 of
components/openssl/openssl-1.0.1/build/sparcv9-wanboot/crypto/ocsp/ocsp_ht.c
in function 'OCSP_REQ_CTX_free'.
Function OCSP_sendreq_new
OpenSSL Support;
While waiting for the 0.9.8zb version to be released, I tried the latest
snapshot from ftp://ftp.openssl.org/snapshot/
openssl-0.9.8-stable-SNAP-20140611.tar.gz and got the exact same results. I'm
kind of dead in the water until I can compile, can you offer any advice
I am getting the same error on Win 8.1 32 bit with Visual Studio 2008 when
issuing 'ms\do_fips'.
Andrew Schmidt
On Tue, Jun 10, 2014 at 11:53 AM, Swenson, Ken_S. via RT r...@openssl.org
wrote:
OpenSSL Support;
I issued the command ms\do_fips (also tried w/ ‘no-ec’ option,) it
compiles
On Wed, Jun 11, 2014, Andy Schmidt wrote:
I am getting the same error on Win 8.1 32 bit with Visual Studio 2008 when
issuing 'ms\do_fips'.
You shouldn't be calling ms\do_fips from OpenSSL 0.9.8 only from the validated
module tarball.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core
Steve H has fixed this through this commit:
https://github.com/openssl/openssl/commit/447280ca7babd7532f23ab7afd9e8393f0b07fc0
Matt
__
OpenSSL Project http://www.openssl.org
Development Mailing
I just confirmed that the 'ms\do_fips no-asm' build on Win 8.1 Visual
Studio 2008 AMD64 build suffers from the same failure that Ken Swenson
describes, and that it is fixed by the same remedy as I described for Win32.
Andrew Schmidt
On Wed, Jun 11, 2014 at 4:24 PM, Andy Schmidt
Hi Ken, OpenSSL support,
I was able to get the 'ms\do_fips' build to succeed on Win 8.1, Visual
Studio 2008 32-bit by unconditionally compiling the function CRYPTO_memcmp
in crypto/cryptlib.c and removing the same function from crypto/o_init.c.
In the za source, a guard macro is set to only
On Tue Jun 10 20:53:31 2014, ken.swen...@ngc.com wrote:
OpenSSL Support;
I issued the command ms\do_fips (also tried w/ ‘no-ec’ option,) it
compiles for about 5 minutes, and then throws this error…
That's not the correct build procedure. You only call ms\do_fips from the
validated module
21 matches
Mail list logo
