Re: Crash bug in 0.9.8n
Hi, The crash occurs with 0.9.8 because it wrongly calls the function close instead of closesocket in order to release the client socket. In the 1.0.0 source, this has been corrected but the modification has not been back-ported to the 0.9.8 source tree. Also, the crash occurs only if you compile with a recent VC++ runtime (like VC2008 and VC2005). With VC6 no crash happens. This is because recent VC++ runtimes call a default handler when a CRT function receives an invalid parameter and this handler simply aborts the program execution. This behavior can be changed by setting a custom handler using the function _set_invalid_parameter_handler. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr Thomas J. Hruska schrieb: Running 'openssl s_client' on 0.9.8n without any additional arguments crashes openssl.exe. There is very different behavior between 0.0.8 and 1.0.0 on WinXP Pro SP3: openssl version OpenSSL 0.9.8j 07 Jan 2009 openssl s_client Loading 'screen' into random state - done connect: Bad file descriptor connect:errno=10061 openssl version OpenSSL 1.0.0 29 Mar 2010 openssl s_client Loading 'screen' into random state - done connect: No error connect:errno=0 its no problem for me. Just for information completion. regards, Modem Man __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
building OpenSSL 0.9.8/1.0.0 on Solarisx86
Hello, Has anyone been able to build usable libcrypto/libssl on Solarisx86 ? I built 32-bit OpenSSL 0.9.8 and OpenSSL 1.0.0 on Solaris10x86_64 (64-bit kernel on Intel) with gcc compiler. Makefiles were generated with the following command: Configure solaris-x86-gcc Test executables provided with OpenSSL and other executables and libraries linked to libcrypto.* and libssl.* statically or dynamically dump core in init: core 'core' of 4479:./exec fd28f5c5 _init(feffb28c, feffdd58, feffb818, fc280c90, fdfc01ac, fd28f5b0) + 15 fefd4c11 call_init (fc280c50, 1) + f5 fefd4194 setup(8047b08, 8047b88, 0, 8047fed, 1000, fefc9141) + fd4 fefe005e _setup (8047abc, feffbaec, 3, 8047b00, 4, 8047b08) + 2ba fefcaa1c _rt_boot (0, 8047bfa, 8047c06, 8047c49, 8047c56, 8047c5d) + 56 08047bf0 () And probably is happened when calling init of curl library: 04487: 1: calling .init (done): /export/home/PreTest/genio/libGShricudata.so.34 04487: 1: 04487: 1: calling .init (from sorted order): /usr/lib/libz.so.1 04487: 1: 04487: 1: calling .init (done): /usr/lib/libz.so.1 04487: 1: 04487: 1: calling .init (from sorted order): /export/home/PreTest/genio/libcurl.so.4 04487: 1: Segmentation Fault(coredump) libcurl.so.4 is statically linked to libcrypto and libssl. Core dump does not occur with 64-bit libcrypto.* and libssl.*. We were able to create usable 32- and 64-bit libraries on 64-bit kernel using platform specific compilers on Solaris SPARC, AIX, HP-UX. This is our system info: SunOS viola 5.10 Generic_141445-09 i86pc i386 i86pc /export/home/sambuild/OpenSSL more /etc/release Solaris 10 10/09 s10x_u8wos_08a X86 Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 16 September 2009 /export/home/sambuild/OpenSSL /usr/bin/isainfo -kv 64-bit amd64 kernel modules /export/home/sambuild/OpenSSL gcc -v Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) Please advise. Thank you, Alona Alona Rossen Software developer Connectivity Solutions Group Open Text Phone: +1 (905) 762-6001 ext. 6908 aros...@opentext.com http://www.hummingbird.com/
Re: OpenSSL ca command handles -infiles option more carefully?
No...
I may have been unclear: I was referring to the '-infiles' switch to the
openssl ca command, as referenced in the docs. This switch exists, ostensibly,
to sign multiple CSRs as a batch.
My point was only that, despite the stated constraint:
' if present this should be the last option, all subsequent arguments are
assumed to the the names of files containing certificate requests' ,
we seemed to have somehow been able to use this switch (at some point in the
distant past) embedded in a command string, with other switches following it.
Executing our same commands now, under OpenSSL v1.0.0, the '-infiles' switch
appears to be behaving exactly as documented.
Having said all this, I know there are those who feel that the ca command
should be avoided altogether; my notes here are only for academic/historical(?)
interest.
Lou Picciano
- Original Message -
From: Kyle Hamilton aerow...@gmail.com
To: openssl-users openssl-users@openssl.org
Sent: Sunday, April 25, 2010 10:16:55 PM GMT -05:00 US/Canada Eastern
Subject: Re: OpenSSL ca command handles -infiles option more carefully?
The switch is -infile, not -infiles.
-Kyle H
On Sun, Apr 25, 2010 at 6:26 PM, Lou Picciano loupicci...@comcast.net wrote:
We've run into an interesting - apparently new? - behavior of the openssl ca
command:
I believe we've used the following command in the past (pre 1.0.0). (Don't
know why we were still using the -infiles option with a single input file -
something vestigial, no doubt; Nonetheless, I think it's worked:
../bin/openssl ca \
-days 1095 \
-infiles YOUR.csr \
-out YOUR.crt \
-config ../openssl.cnf
Now, using OpenSSL v1.0.0, this command results in an error, as if the
-infiles option is trying to read the -out option as a filename! (Yes, many
of our commands are formatted with the backslash for readability):
-out: No such file or directory
4274892676:error:02001002:system library:fopen:No such file or
directory:bss_file.c:355:fopen('-out','r')
4274892676:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:357:
Don't know if this is a new 'fastidiousness' of the ca command, or if we
simply never hit it before, but it may merit attention.
For example, we haven't tested all the permutations, such as what would
happen if the -infiles option were the last option in the command string,
and had only one file as an input?
Lou
__
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
