RE: [openssl.org #2988] Makefiles should (usually) remove target before re-generating

2013-02-13 Thread Salz, Rich via RT
> Unfortunately some platforms can't automatically build the files e.g. WIN32, > VMS. Okay, so those targets shouldn't get invoked? Or are you saying that you WANT the build to fail on those platforms? > # objects.pl both reads and writes obj_mac.num > obj_mac.h: objects.pl objects.txt obj_ma

Re: [openssl.org #2981] BUG: 1.0.1e 64-bit C implementation ECDHE* chiphersuites incompatible with https://google.com

2013-02-13 Thread Serguei E. Leontiev
Hi, Andy, > For reference. Why does it show up with no-asm? bn_nist.c is collection > of functions for specific moduli, but it's perfectly possible to > calculate the result using general-purpose subroutines. It was found > that general-purpose *assembly* code paths deliver better performance > an

Re: [openssl.org #2981] BUG: 1.0.1e 64-bit C implementation ECDHE* chiphersuites incompatible with https://google.com

2013-02-13 Thread Serguei E. Leontiev via RT
Hi, Kurt, > On Wed, Feb 13, 2013 at 12:19:19PM +0100, Andy Polyakov via RT wrote: >> >>> Probably this "strict aliasing" 64-bit optimization bug for >>> "crypto/bn/bn_nist.c" > What bug are you talking about? There doesn't seem to be a strict > aliasing warning in that file, and they use a unio

[openssl.org #2988] Makefiles should (usually) remove target before re-generating

2013-02-13 Thread Stephen Henson via RT
On Wed Feb 13 20:28:12 2013, rs...@akamai.com wrote: > Some targets need to be removed before rebuilding them: > Unfortunately some platforms can't automatically build the files e.g. WIN32, VMS. Also: > > # objects.pl both reads and writes obj_mac.num > obj_mac.h: objects.pl objects.txt obj_mac.

[openssl.org #2989] OpenSSL-1.0.1e fails test suite on OSX

2013-02-13 Thread David Favor via RT
David-Favor-iMac# xcodeversion Xcode 4.6 Build version 4H127 David-Favor-iMac# uname -a Darwin David-Favor-iMac.local 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 Attached is the test log. -- Love feeling your best ever, all day

Re: [openssl.org #2981] BUG: 1.0.1e 64-bit C implementation ECDHE* chiphersuites incompatible with https://google.com

2013-02-13 Thread Kurt Roeckx via RT
On Wed, Feb 13, 2013 at 12:19:19PM +0100, Andy Polyakov via RT wrote: > > > Probably this "strict aliasing" 64-bit optimization bug for > > "crypto/bn/bn_nist.c" What bug are you talking about? There doesn't seem to be a strict aliasing warning in that file, and they use a union to get around t

[openssl.org #2988] Makefiles should (usually) remove target before re-generating

2013-02-13 Thread Salz, Rich via RT
Some targets need to be removed before rebuilding them: In apps/Makefile, add "$(RM) $@" after progs.h line In crypt/bn/Makefile, something like this: bn_prime.h: bn_prime.pl $(RM) $@ $(PERL) bn_prime.pl >$@

[openssl.org #2911] shall publish current state

2013-02-13 Thread Francis Dupont via RT
I'll publish the whole stuff (patch to the last OpenSSL distrib, docs and the test suite as the "application") into the Windows Store in a few days (I expect this weekend). francis.dup...@fdupont.fr PS: only the crypto stuff works: the file and network I/O part of the WIN32 API is not available i

Re: [openssl.org #2981] BUG: 1.0.1e 64-bit C implementation ECDHE* chiphersuites incompatible with https://google.com

2013-02-13 Thread Andy Polyakov via RT
Hi, Please, reply and keep replying to r...@openssl.org, so that proceedings are kept together. > Probably this "strict aliasing" 64-bit optimization bug for > "crypto/bn/bn_nist.c" > > Mac OSX compiler fail test/ectest: cc [Apple LLVM version 4.2 > (clang-425.0.24) (based on LLVM 3.2svn)] gcc-

Re: [openssl.org #2279] Bug Report

2013-02-13 Thread Rainer Jung
This bug about an incompatibility of cms-test.pl with old Perl versions has been fixed in 2011 for trunk by Andy (thanks!), but not been backported to any release branch. I verified it today for 1.0.1 on Solaris 8. It would be nice if the simple change could be applied to at least some of the relea

[openssl.org #2987] "openssl speed" bug with the -multi option on multi-core/processor environments

2013-02-13 Thread Sangjin Han via RT
Hi, The time numbers from "openssl speed -multi " can be easily misunderstood as the elapsed time (latency) for each crypto operation. However, they are simply 1 / . While it makes sense in single-processor cases, they are roughly n times lower than they should be in multi-processor cases. Having