Re: [openssl.org #989] DJGPP patches for 0.9.8 and 0.9.7
./Configure no-threads --prefix=/dev/env/DJDIR DJGPP Just occured to me. What if end-user system doesn't have /dev catalog on the current drive? Would an application succeed to open /dev/urandom$ even then? In other words wouldn't it more appropriate to check upon urandom$ without *any* prefix in pathname? OpenSSL requires a source of random data in order to perform secure cryptography. It's not OpenSSL specific thing and cryptography has to be secure to be called one. FAQ really has more appropriate wording: Cryptographic software needs a source of unpredictable data to work correctly. Verify what happens if you don't have /dev to see if ./Configure needs to be updated at the same time... A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1000] OpenSSL 0.9.7e fails RIPEMD160 on Sparc64
Hi,
On Thu, Jan 13, 2005 at 12:09:42AM +0100, Andy Polyakov via RT wrote:
Anything I should try?
INSTALL is specfic about this. Try removing any compiler optimization
flags... This very issue was discussed couple of times already (google
for error message) in Solaris context. The error is believed to be a GCC
64-bit specific bug and nobody managed to prove otherwise so far. A.
OK, thanks.
If I compile the two .c/.o files in crypto/ripemd/ without optimization,
the ./rmdtest passes without a hitch.
OSSL_LIBPATH=`cd ..; pwd`; LD_LIBRARY_PATH=$OSSL_LIBPATH:$LD_LIBRARY_PATH;
DYLD_LIBRARY_PATH=$OSSL_LIBPATH:$DYLD_LIBRARY_PATH;
SHLIB_PATH=$OSSL_LIBPATH:$SHLIB_PATH; LIBPATH=$OSSL_LIBPATH:$LIBPATH; if
[ NetBSD-sparc = Cygwin ]; then PATH=${LIBPATH}:$PATH; fi; export
LD_LIBRARY_PATH DYLD_LIBRARY_PATH SHLIB_PATH LIBPATH PATH; ./rmdtest
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
test 7 ok
test 8 ok
So indeed, this seems to be a gcc (3.3.3) optimization error.Is there
a way to make OpenSSL auto-disable -O3 for specific crypto/... modules
if its known that they fail on specific platforms? If yes, the NetBSD
pkgsrc module could just enable this...
PS: sorry that I forgot make report last time, here it is:
OpenSSL self-test report:
OpenSSL version: 0.9.7e
Last change: Avoid a race condition when CRLs are checked in a multi...
Options: no-asm no-krb5
OS (uname): NetBSD kirk 2.0 NetBSD 2.0 (KIRK) #2: Tue Jan 11 20:49:13 CET
2005 [EMAIL
PROTECTED]:/home/sparc64/obj/home/src-2.0/sys/arch/sparc64/compile/KIRK sparc64
OS (config): sparc64-whatever-netbsd
Target (default): NetBSD-sparc
Target: NetBSD-sparc
Compiler: Using built-in specs.
Configured with:
/home/nick/work/netbsd/src/tools/gcc/../../gnu/dist/gcc/configure
--enable-long-long --disable-multilib --enable-threads --disable-symvers
--build=i386-unknown-netbsdelf --host=sparc64--netbsd --target=sparc64--netbsd
Thread model: posix
gcc version 3.3.3 (NetBSD nb3 20040520)
Failure!
[...]
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [EMAIL PROTECTED]
fax: +49-89-35655025[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
[openssl.org #1001] potential problem with no-asm option
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1002] Problem with mingw build of 0.9.8
I have now built the snapshot from 20050105 for mingw. The 0.9.7 stable
code builds and tests fine, with or without FIPS. The 0.9.8 code,
however, fails the test suite at the end of test_ssl. The same error
occurs when built with or without the assembler code. I am not sure
where to go with this. If anyone has suggestions as to what to check
next, I would appreciate it. The error reported is:
4294254169:error:1407E086:SSL routines:SSL2_SET_CERTIFICATE:certificate verify
failed:s2_clnt.c:1063:
I am attaching the log of test_ssl in case it gives some clues. All the
other tests from make test seem to pass OK. The check of the
certificates did, however, give different results than I got with the
DJGPP port. All the certificates were OK in the DJGPP port, but several
in the mingw port had the error:
error 18 at 0 depth lookup:self signed certificate
Here is an excerpt from the log:
The following command should have some OK's and some failures
There are definitly a few expired certificates
if [ -n ]; then OSSL_LIBPATH=`cd ..; pwd`;
LD_LIBRARY_PATH=$OSSL_LIBPATH:$LD_LIBRARY_PATH;
DYLD_LIBRARY_PATH=$OSSL_LIBPATH:$DYLD_LIBRARY_PATH;
SHLIB_PATH=$OSSL_LIBPATH:$SHLIB_PATH; LIBPATH=$OSSL_LIBPATH:$LIBPATH; if
[ mingw = Cygwin ]; then PATH=${LIBPATH}:$PATH; fi;
LD_PRELOAD=$OSSL_LIBPATH/libssl.so $OSSL_LIBPATH/libcrypto.so; export
LD_LIBRARY_PATH DYLD_LIBRARY_PATH SHLIB_PATH LIBPATH PATH; export LD_PRELOAD;
fi; ../apps/openssl verify -CApath ../certs ../certs/*.pem
../certs/RegTP-5R.pem: /C=DE/O=Regulierungsbeh\xC8orde f\xC8ur
Telekommunikation und Post/0.2.262.1.10.7.20=1/CN=5R-CA 1:PN
error 18 at 0 depth lookup:self signed certificate
One of the mingw binaries I tested identifies itself as:
OpenSSL 0.9.8-dev XX xxx
built on: Sun Jan 9 23:24:56 PST 2005
platform: mingw
options: bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) blowfish(idx)
compiler: gcc -DDSO_WIN32 -mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3
-march=i486 -Wall
OPENSSLDIR: d:/cygwin/mingw/ssl
Doug
--
Doug Kaufman
Internet: [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
ENGINE issues
Dear list,
I have a problem when integrating my application with
LunaSA/LunaCA3 by using the ENGINE extension with our
OpenCA-OCSP daemon.
I successfully can execute PRE and POST commands by using
`ENGINE_ctrl_cmd_string()' (e.g. CONF_PATH and login
commands).
The problem is that, by using default OpenSSL ENGINE
commands (with OpenSSL 0.9.7) to load the private key
generated on the LunaSA I get the following error:
---
30436:error:2609607D:engine
routines:ENGINE_load_private_key:no load
function:eng_pkey.c:110:
---
The code that generates the problem is the following:
---
ocspd_conf-ocspd_pkey =
ENGINE_load_private_key(ocspd_conf-engine,
keyfile, UI_OpenSSL(), cb_data);
if ( bio_out = BIO_new_fp( stderr, BIO_NOCLOSE)) {
ERR_print_errors( bio_out );
BIO_free(bio_out);
}
---
On the LunaSA device we have the following objects:
---
[EMAIL PROTECTED] root]# cmu list -display=id,label,handle
Please enter password for token in slot 1 :
id=0001 label=ocspPubKey handle=10
id=0001 label=ocspPrivKey handle=11
---
and in keyfile variable in the example I set the id of the
private key (0001).
Does anyone have experiences on how to load a private
key from the LunaSA (LunaCA3) with OpenSSL 0.9.7 ?
Thanks for any help,
--- Massimiliano Pala
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
RE: ENGINE issues
IIRC the Luna CA3 is FIPS140-2 LEVEL 3 which means it won't allow you under nay circumstances to extract the private key from the device (non-extractable, sensitive in PKCS#11 parlance). What this means is that you need to send the data to the device to be signed (don't know how to do this using openssl), rather than extracting the key and using openssl to do the crypto in software. Dave __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ENGINE issues
On Thu, 13 Jan 2005 12:27:57 - David C. Partridge [EMAIL PROTECTED] wrote: IIRC the Luna CA3 is FIPS140-2 LEVEL 3 which means it won't allow you under nay circumstances to extract the private key from the device (non-extractable, sensitive in PKCS#11 parlance). What this means is that you need to send the data to the device to be signed (don't know how to do this using openssl), rather than extracting the key and using openssl to do the crypto in software. My intention was not to extract the key but to tell OpenSSL to use a particular key, thus I need a way to generate a reference to the key. I just taken as an example the code from openssl, but there is something I am doing wrong somewhere... All I want to do is to enable ENGINE so all crypto operations are performed on the LunaSA (and probably I am missing something important here :-( ) and to use the Key sored on the device, not a software one. Does anybody have experiences (also with other hardware) that may be of some help ??? Thank you, byz. --- Massimiliano Pala ([EMAIL PROTECTED]) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #989] DJGPP patches for 0.9.8 and 0.9.7
On Thu, 13 Jan 2005, Andy Polyakov wrote: ./Configure no-threads --prefix=/dev/env/DJDIR DJGPP Just occured to me. What if end-user system doesn't have /dev catalog on the current drive? Would an application succeed to open /dev/urandom$ even then? In other words wouldn't it more appropriate to check upon urandom$ without *any* prefix in pathname? The /dev directory is a special directory for DJGPP. This is a virtual directory, reserved for use by the DJGPP system. The user shouldn't have anything in a /dev directory. The DJGPP system converts /dev/d/ to d:/ and converts /dev/env/whatever to the environment variable whatever. So it doesn't matter what a user has there, unless they specifically created a /dev directory and put another file there with the same name. The virtual /dev directory was created specifically to make it easier to port unix-based source code to DJGPP. There is an alternative. Noise creates other names for the random/urandom devices, known as RANDOM$ and URANDOM$. We could use those names instead of /dev/random$ and /dev/urandom$ if you prefer. I don't think it makes a difference. OpenSSL requires a source of random data in order to perform secure cryptography. It's not OpenSSL specific thing and cryptography has to be secure to be called one. FAQ really has more appropriate wording: Cryptographic software needs a source of unpredictable data to work correctly. Good. I like the wording from the FAQ. It is better. Doug -- Doug Kaufman Internet: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #998] /dev/random and Solaris 10
/dev/random is a symlink on Solaris and Solaris 10 has added O_NOFOLLOW to /usr/include/sys/fcntl.h. This causes a problem in crypto/rand/rand_unix.c where /dev/random doesn't get used, when it actually should... This is with openssl-0.9.7e and Solaris x86 10_b72. Or is it used to avoid using same device? Well, on FreeBSD 5 /dev/urandom is a symbolic link to random and O_NOFOLLOW is indeed due, but it's far from universally appropriate... As rightly noted /dev/* under Solaris are indeed and always were symbolic links to /devices/... So collecting fstats and compare st_rdevs Check for device numbers would be more appropriate... Alternatively one can simply complement #ifdef O_NOFOLLOW with #ifdef __FreeBSD__... A. I've commited suggestion to HEAD, see two top-most entries at http://cvs.openssl.org/rlog?f=openssl/crypto/rand/rand_unix.c. If nobody shouts, I'll apply it to 0.9.7-stable. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OS/2 support
tmp_dll\o_str.obj(o_str.obj) : error L2029: 'strncasecmp' : unresolved external tmp_dll\o_str.obj(o_str.obj) : error L2029: 'strcasecmp' : unresolved external My reasoning was following. Snapshot version of o_str.c was recently modified to include e_os.h, which in turn conditionally defines str[n]casecmp as str[n]icmp on OS/2 already. Ooops! I missed #undef str[n]casecmp in beginning of o_str.c... I have to ponder over it, there should be more elegant solution to this problem... I've committed suggestion to HEAD, see http://cvs.openssl.org/chngview?cn=12821. If nobody shouts, I'll apply it to 0.9.7-stable. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1000] OpenSSL 0.9.7e fails RIPEMD160 on Sparc64
Anything I should try?
INSTALL is specfic about this. Try removing any compiler optimization
flags... This very issue was discussed couple of times already (google
for error message) in Solaris context. The error is believed to be a GCC
64-bit specific bug and nobody managed to prove otherwise so far. A.
OK, thanks.
If I compile the two .c/.o files in crypto/ripemd/ without optimization,
the ./rmdtest passes without a hitch.
OSSL_LIBPATH=`cd ..; pwd`;
LD_LIBRARY_PATH=$OSSL_LIBPATH:$LD_LIBRARY_PATH;
DYLD_LIBRARY_PATH=$OSSL_LIBPATH:$DYLD_LIBRARY_PATH;
SHLIB_PATH=$OSSL_LIBPATH:$SHLIB_PATH; LIBPATH=$OSSL_LIBPATH:$LIBPATH;
if [ NetBSD-sparc = Cygwin ]; then PATH=${LIBPATH}:$PATH; fi; export
LD_LIBRARY_PATH DYLD_LIBRARY_PATH SHLIB_PATH LIBPATH PATH; ./rmdtest
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
test 7 ok
test 8 ok
So indeed, this seems to be a gcc (3.3.3) optimization error.Is there
a way to make OpenSSL auto-disable -O3 for specific crypto/... modules
if its known that they fail on specific platforms?
No. BTW, if it enough to drop to -O2 or do you have to -O0? Can you test
if './config -DMD32_REG_T=int' does the trick?
If yes, the NetBSD
pkgsrc module could just enable this...
PS: sorry that I forgot make report last time, here it is:
OpenSSL self-test report:
OpenSSL version: 0.9.7e
Last change: Avoid a race condition when CRLs are checked in a multi...
Options: no-asm no-krb5
OS (uname): NetBSD kirk 2.0 NetBSD 2.0 (KIRK) #2: Tue Jan 11 20:49:13
CET 2005 [EMAIL
PROTECTED]:/home/sparc64/obj/home/src-2.0/sys/arch/sparc64/compile/KIRK
sparc64
OS (config): sparc64-whatever-netbsd
Target (default): NetBSD-sparc
Target: NetBSD-sparc
Just NetBSD-sparc? When gcc spits out 64-bit objects? You're more than
likely to suffer from http://www.openssl.org/support/faq.html#BUILD11.
NetBSD should have contributed NetBSD-sparc64 target with appropriate
flags... A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Fwd: RE : ENGINE issues
--- the forwarded message follows --- ---BeginMessage--- On Thu, 13 Jan 2005 16:26:33 +0100 Frédéric Donnat [EMAIL PROTECTED] wrote: Hi Massimo, Hi, As far as I know it you must LOAD (pre command I think) the ENGINE to correctly set all ENGINE function pointers... And thus initialize openssl with your ENGINE. Did you do it? Yes, init of the ENGINE works fine. You should be able to get a priovate key handle but not the private key paramters according to PKCS#11. I have done such thing with a Bull PKCS 11 module and their PKCS#11 patch and it works fine. You could try to trace Luna ENGINE in ENGINE_load_private_key() function in order to find the faulty part of code. This is what I have done... and I found that they simply did not implemented the ENGINE_load_private_key()... I am trying to implement it... but it is quite hard to do it in less than one day. I hope they will respond to my requests sending me the missing functions (also the ENGINE_load_public_key() is missing, but this is not an issue... at the moment!). It sounds really strange, anyway, that this function is missing... as this implies that no ENGINE support is there to use private keys directly on the LunaCA/SA!?!? Anyway if you have some code you can send me about your implementation, I would be glad to take a look at it in order to check my implementation. Thx, for your help. -- Massimiliano Pala ---End Message---
Re: ENGINE issues
On Thu, Jan 13, 2005, Massimiliano Pala wrote: On Thu, 13 Jan 2005 12:27:57 - David C. Partridge [EMAIL PROTECTED] wrote: I just taken as an example the code from openssl, but there is something I am doing wrong somewhere... All I want to do is to enable ENGINE so all crypto operations are performed on the LunaSA (and probably I am missing something important here :-( ) and to use the Key sored on the device, not a software one. Does anybody have experiences (also with other hardware) that may be of some help ??? The nCipher (nFast/Chil) ENGINE can use hardware keys. There's also a test operation in the openssl test engine which just loads froma PEM file. I suggest you put debugging printfs in your code to check it's load private key function is actually being called. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1000] OpenSSL 0.9.7e fails RIPEMD160 on Sparc64
Hi, On Thu, Jan 13, 2005 at 04:56:58PM +0100, Andy Polyakov via RT wrote: So indeed, this seems to be a gcc (3.3.3) optimization error.Is there a way to make OpenSSL auto-disable -O3 for specific crypto/... modules if its known that they fail on specific platforms? No. BTW, if it enough to drop to -O2 or do you have to -O0? -O2 is not sufficient (- rmdtest fails). Can you test if './config -DMD32_REG_T=int' does the trick? Yes! This makes rmdtest work with -O3. If yes, the NetBSD pkgsrc module could just enable this... PS: sorry that I forgot make report last time, here it is: [..] OS (config): sparc64-whatever-netbsd Target (default): NetBSD-sparc Target: NetBSD-sparc Just NetBSD-sparc? When gcc spits out 64-bit objects? You're more than likely to suffer from http://www.openssl.org/support/faq.html#BUILD11. Uh, well, what shall I say? There are linux-sparc64 and solaris-sparc64 targets, but no NetBSD-sparc64... (and I consider myself mostly user on Sparc64 yet). NetBSD should have contributed NetBSD-sparc64 target with appropriate flags... A. The NetBSD pkgsrc tree has patch for the netbsd-sparc64 target, but using that failed with interesting MD5-assembly error codes. This is what got me started here - I opened a bug vs. NetBSD, they fixed the MD5 thing, and then we discovered that the upstream sources also have the ripemd problems. The NetBSD pkg maintainer (Jonny Lam) has just commited a new set of patches that fix building on Sparc64 for good :-) - maybe you could just incoprorate them (dunno what the NetBSD patch copyright policy is, though)? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1000] OpenSSL 0.9.7e fails RIPEMD160 on Sparc64
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gert Doering via RT Sent: Thursday, January 13, 2005 12:50 AM Cc: openssl-dev@openssl.org Subject: Re: [openssl.org #1000] OpenSSL 0.9.7e fails RIPEMD160 on Sparc64 Hi, On Thu, Jan 13, 2005 at 12:09:42AM +0100, Andy Polyakov via RT wrote: Anything I should try? INSTALL is specfic about this. Try removing any compiler optimization flags... This very issue was discussed couple of times already (google for error message) in Solaris context. The error is believed to be a GCC 64-bit specific bug and nobody managed to prove otherwise so far. A. OK, thanks. If I compile the two .c/.o files in crypto/ripemd/ without optimization, the ./rmdtest passes without a hitch. Gert, Are you using GNU as or the Solaris as? Have you tried this with the other assembler? Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
