I notice that the current version doesn't even compile under gcc 4.2.2
with our preferred flags.
gcc 4.6 is quite happy, though, interestingly.
On Fri, Dec 2, 2011 at 3:45 PM, Yann Droneaud via RT r...@openssl.org wrote:
The problem of the upper capability bytes is also affecting
Hi,
I have just produced a patch against the upstream HEAD version,
to seek a way to fight against DoS attack in openssl itself,
the logic is simple, get client's ip address in BIO layer,
and send this info to upper SSL layer; In SSL layer,
according to the client ip and control policy to do
Attached patch will allow passing the LDFLAGS variable to the build,
making it possible to pass individual linker flags if wanted. Patch is
taken from Gentoo Linux.
It'd be great if this could be incorporated before 1.0.1
http://bugs.gentoo.org/327421
--- Makefile.org
+++ Makefile.org
@@ -189,6
OpenSSL 1.0.1 snaphot 20111211, compiled on Cygwin, no special config options.
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
CPU Code2 Duo E8600
make tests shows:
../util/shlib_wrap.sh ./shatest
test 1 ok
test 2 ok
test 3 ok
../util/shlib_wrap.sh ./sha1test
test 1 ok
test 2 ok
OpenSSL 1.0.1 snaphot 20111211, compiled on Cygwin, no special config options.
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
CPU Code2 Duo E8600
Both
./apps/openssl speed sha1
and
./apps/openssl speed -evp sha1
MAY results in hangup on any stage.
Sometimes speed
OS: SunOS 5.10
Compiler: SunStudio
As requested on the mailing lists today I downloaded
openssl-1.0.1-stable-SNAP-20111209
and tried to compile it on various OS.
It failed on SunOS 5.10 when using Sun's compiler:
cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include
I've been testing out the LLVM static analysis tool
http://clang-analyzer.llvm.org/ on various code bases, and it's lighting up a
particular construct used in OpenSSL.
Let me state my position right up front:
I have no idea if this causes any problems in OpenSSL, but I don't
think
I'm still having this build problem on Windows, with code just pulled
from CVS 1.0.1 stable branch. It happens when building the 32-bit build
on a 64-bit OS.
I think it depends on what do you mean by code just pulled from CVS
1.0.1 branch *exactly*? If you have a checked out tree, and had it
On Mon, Dec 12, 2011, Andy Polyakov via RT wrote:
OS: SunOS 5.10
Assembler:
modexp512-x86_64.s, line 433 : Syntax error
Please verify http://cvs.openssl.org/chngview?cn=21836.
Thanks, that fixes the error.
__
Thanks Andy. It looks like that was indeed the problem -- my copy of the
CVS tree had gotten out of sync somehow.
On Mon, Dec 12, 2011 at 7:29 AM, Andy Polyakov ap...@openssl.org wrote:
I'm still having this build problem on Windows, with code just pulled
from CVS 1.0.1 stable branch. It
Hello,
OpenSSL introduced support for RFC 3779, but the functionality is disabled
by default. Are there any specific reasons for not enabling it or will
enable-rfc3779 eventually become the default compile flag?
Thanks and Best regards,
Martin Krüger
The same behaviour is for other hashes: md4 md5 mdc2 and sha.
But not for sha256, sha512 and whirlpool - everything is ok with these hashes:
$ ./apps/openssl speed sha512 sha256 whirlpool
OpenSSL 1.0.1-dev xx XXX
built on: Tue Dec 13 08:14:31 RST 2011
options:bn(64,32) rc4(8x,mmx)
Can you reproduce it under cygwin gdb? I.e. 'gdb apps/openssl' and then
at gdb prompt 'run speed sha1'. If yes, ctrl-C and 'info threads'. Then
'cont', ctrl-C and 'info threads' few more times. Look at thread #1 at
all occasions. Where is it caught? Does program counter varies? If it's
Where is it caught?
Addentum: programm caught in different functions: I saw
OPENSSL_Cleanse(), EVP_DigestUpdate(), sha1_something and others.
I provided 'thread apply 1 info reg' only if it get caugth in
sha1_block_data_order_ssse3 ().
openssl was compiled with ./config -g
(gdb) info
14 matches
Mail list logo
