[openssl.org #486] ocsp.c make_ocsp_response() fix
The handling of the thisupd and nextupd pointers in make_ocsp_response() is incorrect. The pointers should be the first parameter of x509_gmtime_adj(), rather than the return value. I've attached a patch that fixes this. -John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #435] ssl_connect core dump problem, with gdb traces
Hi Our's is a Proxy Server SSL enabled multithreaded application. We are running on solaris operating system. we are using OpenSSL library [ openssl-0.9.6 ] we have serverCA and root CA certificate at the Proxy server application. our application dumps in ssl_connect during certificate chain verification. Here the Certificate chain is Root CA--- ServerCA - server What all certficates do we need at the proxy server application to validate the above certificate chain. The gdb traces are as follows. #0 0x0039d424 in X509_NAME_cmp (a=0x14291d0, b=0x1404c18) at x509_cmp.c:173 173 j=na-value-length-nb-value-length; (gdb) bt #0 0x0039d424 in X509_NAME_cmp (a=0x14291d0, b=0x1404c18) at x509_cmp.c:173 #1 0x003b14fc in X509_check_issued (issuer=0x7a5fb8, subject=0x6bbea8) at v3_purp.c:528 #2 0x0039eca0 in check_issued (ctx=0xfe8075d8, x=0x6bbea8, issuer=0x7a5fb8) at x509_vfy.c:339 #3 0x003a2728 in X509_STORE_CTX_get1_issuer (issuer=0xfe807560, ctx=0xfe8075d8, x=0x6bbea8) at x509_lu.c:500 #4 0x0039e87c in X509_verify_cert (ctx=0xfe8075d8) at x509_vfy.c:243 #5 0x00355e64 in ssl_verify_cert_chain (s=0x8a2498, sk=0x5ae238) at ssl_cert.c:472 #6 0x00364218 in ssl3_get_server_certificate (s=0x8a2498) at s3_clnt.c:832 #7 0x0036298c in ssl3_connect (s=0x8a2498) at s3_clnt.c:268 #8 0x00350fe0 in SSL_connect (s=0x8a2498) at ssl_lib.c:718 #9 0x000cc4a0 in Sdf_cl_NetworkManager::sslConnect (this=0x5f5c50, pConnMapElem=0x1a46c20, pErr=0xfe807b30) at source/networkmanager/src/sdftlsnetwork.cpp:1565 #10 0x000cb4b8 in Sdf_cl_NetworkManager::tlsSelectThread (this=0x5f5c50) at source/networkmanager/src/sdftlsnetwork.cpp:1015 #11 0x000c9ed0 in Sdf_fn_startTlsSelectThread (pParam=0x5f5c50) at source/networkmanager/src/sdftlsnetwork.cpp:199 Current language: auto; currently c Can anyone help us in figuring out the problem. (reason for core dump). Thanks in Advance Ajay Kumar This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #486] ocsp.c make_ocsp_response() fix
[[EMAIL PROTECTED] - Thu Jan 30 09:08:11 2003]: The handling of the thisupd and nextupd pointers in make_ocsp_response() is incorrect. The pointers should be the first parameter of x509_gmtime_adj(), rather than the return value. Why do you think it's incorrect? Have you checked what happens when the first parameter is NULL? -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #477] memory leak in SSL_dup
Thanks for the report and the patch. I applied it almost verbatim. This ticket is now resolved. [[EMAIL PROTECTED] - Sat Jan 25 18:18:47 2003]: Hi, I found a memory leak in openssl (version 0.9.6h). I've reproduced it with demos/bio/saccept.c. openssl-0.9.6h/demos/bio$ valgrind --num-callers=20 --leak-check=yes ./saccept ==1981== valgrind-1.0.4, a memory error detector for x86 GNU/Linux. [...] ==1981== ==1981== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==1981== malloc/free: in use at exit: 28987 bytes in 1602 blocks. ==1981== malloc/free: 1771 allocs, 169 frees, 127309 bytes allocated. ==1981== For counts of detected errors, rerun with: -v ==1981== searching for pointers to 1602 not-freed blocks. ==1981== checked 4299544 bytes. ==1981== ==1981== definitely lost: 920 bytes in 1 blocks. ==1981== possibly lost: 0 bytes in 0 blocks. ==1981== still reachable: 28067 bytes in 1601 blocks. ==1981== ==1981== 920 bytes in 1 blocks are definitely lost in loss record 1 of 3 ==1981==at 0x4004519B: malloc (in /usr/lib/valgrind/valgrind.so) ==1981==by 0x80679C0: CRYPTO_malloc (mem.c:223) ==1981==by 0x80610CE: ssl3_new (s3_lib.c:706) ==1981==by 0x804C63B: tls1_new (t1_lib.c:123) ==1981==by 0x804E40E: SSL_new (ssl_lib.c:224) ==1981==by 0x8051659: SSL_dup (ssl_lib.c:1695) ==1981==by 0x8058CC9: ssl_ctrl (bio_ssl.c:434) ==1981==by 0x806EC1A: BIO_ctrl (bio_lib.c:311) ==1981==by 0x806F11A: BIO_dup_chain (bio_lib.c:478) ==1981==by 0x8074E18: acpt_state (bss_acpt.c:260) ==1981==by 0x8074F30: acpt_read (bss_acpt.c:301) ==1981==by 0x806E699: BIO_read (bio_lib.c:165) ==1981==by 0x804AFFF: main (saccept.c:80) ==1981==by 0x4026A08C: __libc_start_main (in /lib/libc-2.2.5.so) ==1981==by 0x228EC: ??? ==1981== ==1981== LEAK SUMMARY: ==1981==definitely lost: 920 bytes in 1 blocks. ==1981==possibly lost: 0 bytes in 0 blocks. ==1981==still reachable: 28067 bytes in 1601 blocks. ==1981== Reachable blocks (those to which a pointer was found) are not shown. The problem seems to be in SSL_dup in ssl/ssl_lib.c: First, the ssl object ret is created: ret=SSL_new(SSL_get_SSL_CTX(s)), this calls s-method-ssl_new(s) in SSL_new later in SSL_dup, some previously allocated bytes with ssl_new are overwritten: ret-method-ssl_new(ret) This little patch seems to fix the problem, but I don't know, if it is the right way... diff -u -r1.3 -r1.4 --- ssl_lib.c 6 Jan 2003 09:04:14 - 1.3 +++ ssl_lib.c 24 Jan 2003 16:25:16 - 1.4 @@ -1708,6 +1708,7 @@ * and thus we can't use SSL_copy_session_id. */ ret-method = s-method; + ret-method-ssl_free(ret); ret-method-ssl_new(ret); if (s-cert != NULL) regards, christian OpenSSL self-test report: OpenSSL version: 0.9.6h Last change: New function OPENSSL_cleanse(), which is used to cleans... Options: --prefix=/usr --openssldir=/etc/openssl shared OS (uname): Linux 2.4.20 #4 Thu Jan 2 00:10:53 CET 2003 i686 unknown OS (config): i686-whatever-linux2 Target (default): linux-elf Target: linux-elf Compiler: gcc version 2.95.3 20010315 (release) P.S.: The link in openssl-0.9.6h/README is wrong: .. via the Request Tracker (http://www.openssl.org/rt2.html) - Not found -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #476] [Fwd: Bug#178112: libssl-dev: Typo in /usr/include/openssl/md5.h]
Thanks for the report, I just committed a fix, which will be present in 0.9.7a. This ticket is now resolved. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #486] ocsp.c make_ocsp_response() fix
[levitte - Thu Jan 30 11:21:30 2003]: [[EMAIL PROTECTED] - Thu Jan 30 09:08:11 2003]: The handling of the thisupd and nextupd pointers in make_ocsp_response() is incorrect. The pointers should be the first parameter of x509_gmtime_adj(), rather than the return value. Why do you think it's incorrect? Have you checked what happens when the first parameter is NULL? It should be correct. Although the corresponding thisUpdate and nextUpdate fields are of type ASN1_GENERALIZEDTIME they go through ASN1_TIME_to_generalizedtime en route which converts them. However a bug was introduced into 0.9.7 ASN1_TIME_to_generalizedtime() which causes problems in this conversion. This change would work around the problem without addressing the underlying cause. Since the ASN1_TIME_to_generalizedtime() bug has now been fixed in 0.9.7-stable I suggest the OP checks the latest stable snapshot. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #435] ssl proxy, core dump in certificate validation when acting as a client
[[EMAIL PROTECTED] - Thu Jan 30 09:28:31 2003]: Hi Our's is a Proxy Server SSL enabled multithreaded application. We are running on solaris operating system. we are using OpenSSL library [ openssl-0.9.6 ] we have serverCA and root CA certificate at the Proxy server application. our application dumps in ssl_connect during certificate chain verification. Here the Certificate chain is Root CA--- ServerCA - server What all certficates do we need at the proxy server application to validate the above certificate chain. The gdb traces are as follows. #0 0x0039d424 in X509_NAME_cmp (a=0x14291d0, b=0x1404c18) at x509_cmp.c:173 173 j=na-value-length-nb-value-length; (gdb) bt #0 0x0039d424 in X509_NAME_cmp (a=0x14291d0, b=0x1404c18) at x509_cmp.c:173 #1 0x003b14fc in X509_check_issued (issuer=0x7a5fb8, subject=0x6bbea8) at v3_purp.c:528 #2 0x0039eca0 in check_issued (ctx=0xfe8075d8, x=0x6bbea8, issuer=0x7a5fb8) at x509_vfy.c:339 #3 0x003a2728 in X509_STORE_CTX_get1_issuer (issuer=0xfe807560, ctx=0xfe8075d8, x=0x6bbea8) at x509_lu.c:500 #4 0x0039e87c in X509_verify_cert (ctx=0xfe8075d8) at x509_vfy.c:243 #5 0x00355e64 in ssl_verify_cert_chain (s=0x8a2498, sk=0x5ae238) at ssl_cert.c:472 #6 0x00364218 in ssl3_get_server_certificate (s=0x8a2498) at s3_clnt.c:832 #7 0x0036298c in ssl3_connect (s=0x8a2498) at s3_clnt.c:268 #8 0x00350fe0 in SSL_connect (s=0x8a2498) at ssl_lib.c:718 #9 0x000cc4a0 in Sdf_cl_NetworkManager::sslConnect (this=0x5f5c50, pConnMapElem=0x1a46c20, pErr=0xfe807b30) at source/networkmanager/src/sdftlsnetwork.cpp:1565 #10 0x000cb4b8 in Sdf_cl_NetworkManager::tlsSelectThread (this=0x5f5c50) at source/networkmanager/src/sdftlsnetwork.cpp:1015 #11 0x000c9ed0 in Sdf_fn_startTlsSelectThread (pParam=0x5f5c50) at source/networkmanager/src/sdftlsnetwork.cpp:199 Current language: auto; currently c Can anyone help us in figuring out the problem. (reason for core dump). The fields in X509_NAME_cmp should be valid so this looks a bit odd. Does the OpenSSL s_client also crash when you connect to this server? What happens when you try: openssl verify -CAfile rootca.pem -untrusted serverca.pem server.pem does that crash? What if you concatenate the two CAs and try: openssl verify -CAfile cas.pem -untrusted server.pem If neither s_client nor verify crash then it could be an application error of some sort. If both crash then you may have a weird certificate that confuses OpenSSL. If that is the case could you send me the chain? Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #287] [PATCH] no-engine (openssl-0.9.7-stable-SNAP-20020915)
OK, I looked at the no-engine patch again, and really saw no harm in it, so it's committed, and will be part of all release from 0.9.7a and on (as well as the current 0.9.7 and main snapshots). This ticket is now resolved. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #328] DH_compute_key incompatable with PKCS #3
No further reaction, so I'm making this ticket stalled. [levitte - Fri Dec 13 16:47:19 2002]: No further reactions, so I'm moving this to 0.9.7a. [[EMAIL PROTECTED] - Wed Dec 4 16:14:25 2002]: I asked Eric Rescorla, and he agreed the section of the TLS RFC was definitely unclear, but he wasn't totally sure which way it should go as far as stripping any leading 0s before using the shared secret to generate keys. It basically depends on what various implementations have decided to do. -J On Wed, 4 Dec 2002, Richard Levitte via RT wrote: I haven't heard any news about this. I also mailed ietf-tls asking about this, but had no response there either. That means there will most probably be no fix in 0.9.6h. 0.9.7 still has a week... I think I'll change the miestone for this fix. [[EMAIL PROTECTED] - Thu Nov 14 19:05:29 2002]: In message [EMAIL PROTECTED] on Thu, 14 Nov 2002 18:54:21 +0100 (MET), Jack Lloyd via RT [EMAIL PROTECTED] said: rt Looks like the 1.1 TLS draft spec uses the same wording. Perhaps someone rt should contact the TLS WG and ask for a clarification on this issue? [I'll rt do it if nobody else is interested] Please do. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #437] bad instructions in CHANGES for platform-dependent builds
Why does this matter? [[EMAIL PROTECTED] - Mon Jan 27 19:20:17 2003]: I've checked over the snapshot that was current on or about 14-Jan- 2003. It builds OK. In the original 0.9.7.tar.gz there were symbolic links already present in include/openssl, and they are not removed by make clean. In the snapshot the links are not present. Script started on Mon Jan 27 10:15:14 2003 kea gzcat openssl-0.9.7-stable-SNAP-20030114.tar.gz | tar tf - | grep include openssl-0.9.7-stable-SNAP-20030114/VMS/test-includes.com openssl-0.9.7-stable-SNAP-20030114/include/ kea gzcat openssl-0.9.7.tar.gz| tar tf - | grep include openssl-0.9.7/include/ openssl-0.9.7/include/openssl/ openssl-0.9.7/include/openssl/aes.h symbolic link to ../../crypto/aes/aes.h openssl-0.9.7/include/openssl/asn1.h symbolic link to ../../crypto/asn1/asn1.h openssl-0.9.7/include/openssl/asn1_mac.h symbolic link to ../../crypto/asn1/asn1_mac.h openssl-0.9.7/include/openssl/asn1t.h symbolic link to ../../crypto/asn1/asn1t.h openssl-0.9.7/include/openssl/bio.h symbolic link to ../../crypto/bio/bio.h openssl-0.9.7/include/openssl/blowfish.h symbolic link to ../../crypto/bf/blowfish.h openssl-0.9.7/include/openssl/bn.h symbolic link to ../../crypto/bn/bn.h openssl-0.9.7/include/openssl/buffer.h symbolic link to ../../crypto/buffer/buffer.h openssl-0.9.7/include/openssl/cast.h symbolic link to ../../crypto/cast/cast.h openssl-0.9.7/include/openssl/comp.h symbolic link to ../../crypto/comp/comp.h openssl-0.9.7/include/openssl/conf_api.h symbolic link to ../../crypto/conf/conf_api.h openssl-0.9.7/include/openssl/conf.h symbolic link to ../../crypto/conf/conf.h openssl-0.9.7/include/openssl/crypto.h symbolic link to ../../crypto/crypto.h openssl-0.9.7/include/openssl/des.h symbolic link to ../../crypto/des/des.h openssl-0.9.7/include/openssl/des_old.h symbolic link to ../../crypto/des/des_old.h openssl-0.9.7/include/openssl/dh.h symbolic link to ../../crypto/dh/dh.h openssl-0.9.7/include/openssl/dsa.h symbolic link to ../../crypto/dsa/dsa.h openssl-0.9.7/include/openssl/dso.h symbolic link to ../../crypto/dso/dso.h openssl-0.9.7/include/openssl/ebcdic.h symbolic link to ../../crypto/ebcdic.h openssl-0.9.7/include/openssl/ec.h symbolic link to ../../crypto/ec/ec.h openssl-0.9.7/include/openssl/engine.h symbolic link to ../../crypto/engine/engine.h openssl-0.9.7/include/openssl/e_os2.h symbolic link to ../../e_os2.h openssl-0.9.7/include/openssl/err.h symbolic link to ../../crypto/err/err.h openssl-0.9.7/include/openssl/evp.h symbolic link to ../../crypto/evp/evp.h openssl-0.9.7/include/openssl/hmac.h symbolic link to ../../crypto/hmac/hmac.h openssl-0.9.7/include/openssl/idea.h symbolic link to ../../crypto/idea/idea.h openssl-0.9.7/include/openssl/krb5_asn.h symbolic link to ../../crypto/krb5/krb5_asn.h openssl-0.9.7/include/openssl/kssl.h symbolic link to ../../ssl/kssl.h openssl-0.9.7/include/openssl/lhash.h symbolic link to ../../crypto/lhash/lhash.h openssl-0.9.7/include/openssl/md2.h symbolic link to ../../crypto/md2/md2.h openssl-0.9.7/include/openssl/md4.h symbolic link to ../../crypto/md4/md4.h openssl-0.9.7/include/openssl/md5.h symbolic link to ../../crypto/md5/md5.h openssl-0.9.7/include/openssl/mdc2.h symbolic link to ../../crypto/mdc2/mdc2.h openssl-0.9.7/include/openssl/objects.h symbolic link to ../../crypto/objects/objects.h openssl-0.9.7/include/openssl/obj_mac.h symbolic link to ../../crypto/objects/obj_mac.h openssl-0.9.7/include/openssl/ocsp.h symbolic link to ../../crypto/ocsp/ocsp.h openssl-0.9.7/include/openssl/opensslconf.h symbolic link to ../../crypto/opensslconf.h openssl-0.9.7/include/openssl/opensslv.h symbolic link to ../../crypto/opensslv.h openssl-0.9.7/include/openssl/ossl_typ.h symbolic link to ../../crypto/ossl_typ.h openssl-0.9.7/include/openssl/pem2.h symbolic link to ../../crypto/pem/pem2.h openssl-0.9.7/include/openssl/pem.h symbolic link to ../../crypto/pem/pem.h openssl-0.9.7/include/openssl/pkcs12.h symbolic link to ../../crypto/pkcs12/pkcs12.h openssl-0.9.7/include/openssl/pkcs7.h symbolic link to ../../crypto/pkcs7/pkcs7.h openssl-0.9.7/include/openssl/rand.h symbolic link to ../../crypto/rand/rand.h openssl-0.9.7/include/openssl/rc2.h symbolic link to ../../crypto/rc2/rc2.h openssl-0.9.7/include/openssl/rc4.h symbolic link to ../../crypto/rc4/rc4.h openssl-0.9.7/include/openssl/rc5.h symbolic link to ../../crypto/rc5/rc5.h openssl-0.9.7/include/openssl/ripemd.h symbolic link to ../../crypto/ripemd/ripemd.h openssl-0.9.7/include/openssl/rsa.h symbolic link to ../../crypto/rsa/rsa.h openssl-0.9.7/include/openssl/safestack.h symbolic link to ../../crypto/stack/safestack.h openssl-0.9.7/include/openssl/sha.h symbolic link to ../../crypto/sha/sha.h openssl-0.9.7/include/openssl/ssl23.h symbolic link to ../../ssl/ssl23.h openssl-0.9.7/include/openssl/ssl2.h symbolic link to ../../ssl/ssl2.h
[openssl.org #437] bad instructions in CHANGES for platform-dependent builds
It's not supposed to. It's only under unusual circumstances that this needs updating, and it should be done in the original source directory anyway. [[EMAIL PROTECTED] - Mon Jan 27 19:48:27 2003]: In the original 0.9.7 release there also seems to be some configuration remnants left in the crypto/objects directory -- obj_dat.h; this isn't removed by a make clean. \nick -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #454] [PATCH] FreeBSD openssl-0.9.7
Hmm, mind if I skip the freebsd-shared: part? It doesn't seem to be used anywhere
anyway...
[[EMAIL PROTECTED] - Sun Jan 12 23:00:37 2003]:
Hi,
In order to support compilation on FreeBSD I have to suggest some
patches.
Please revise and send me comment.
regesssion test looks fine for:
http://people.freebsd.org/~dinoex/ports/openssl097.i386.stable
http://people.freebsd.org/~dinoex/ports/openssl097.i386.current
http://people.freebsd.org/~dinoex/ports/openssl097.alpha.current
http://people.freebsd.org/~dinoex/ports/openssl097.sparc64.current
http://people.freebsd.org/~dinoex/ports/openssl097.ia64.current
Gruß Dirk
- Dirk Meyer, Im Grund 4, 34317 Habichtswald, Tel 05606/6512 Q (voice)
- Origin: DINOEX Habichtswald -FRG- [[EMAIL PROTECTED]]
-
[[EMAIL PROTECTED]],[[EMAIL PROTECTED]],[[EMAIL PROTECTED]]
--- Makefile.org.orig Thu Apr 5 13:08:02 2001
+++ Makefile.org Sat Oct 12 22:10:18 2002
@@ -250,6 +250,21 @@
done
build-shared: clean-shared do_$(SHLIB_TARGET) link-shared
+
+freebsd-shared:
+ for i in ${SHLIBDIRS}; do \
+ rm -f lib$$i.a lib$$i.so \
+ lib$$i.so.${SHLIBVER}; \
+ ${MAKE} CC='${CC}' PLATFORM='${PLATFORM}' CFLAG='-fPIC ${CFLAG}'
SDIRS='${SDIRS}' INSTALLTOP='${INSTALLTOP}' PEX_LIBS='${PEX_LIBS}'
EX_LIBS='${EX_LIBS}' BN_ASM='${BN_ASM}' DES_ENC='${DES_ENC}'
BF_ENC='${BF_ENC}' CAST_ENC='${CAST_ENC}' RC4_ENC='${RC4_ENC}'
RC5_ENC='${RC5_ENC}' SHA1_ASM_OBJ='${SHA1_ASM_OBJ}'
MD5_ASM_OBJ='${MD5_ASM_OBJ}' RMD160_ASM_OBJ='${RMD160_ASM_OBJ}'
AR='${AR}' DIRS=$$i clean all || exit 1; \
+ ( set -x; ${CC} -nodefaultlibs -shared -o lib$$i.so.${SHLIBVER} \
+ -Wl,-S,-soname=lib$$i.so.${SHLIBVER} \
+ -Wl,${WHOLE_ARCHIVE_FLAG} lib$$i.a ) || exit 1; \
+ rm -f lib$$i.a; (cd $$i ; ${MAKE} clean) || exit 1 ;\
+ done;
+ @set -x; \
+ for i in ${SHLIBDIRS}; do \
+ ln -s lib$$i.so.${SHLIBVER} lib$$i.so; \
+ done;
do_bsd-gcc-shared: do_gnu-shared
do_linux-shared: do_gnu-shared
--- Configure.origFri Dec 27 17:35:11 2002
+++ Configure Sat Jan 11 01:44:38 2003
@@ -350,7 +350,9 @@
#
# This probably belongs in a different section.
#
-FreeBSD-alpha,gcc:-DTERMIOS -O
-fomit-frame-pointer::(unknown):::SIXTY_FOUR_BIT_LONG RC4_CHUNK
DES_INT DES_PTR DES_RISC2::dlfcn:bsd-gcc-shared:-
fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
+FreeBSD-alpha,$ENV{CC}:-DTERMIOS
$ENV{CFLAGS}::(unknown):::SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT
DES_PTR DES_RISC2::dlfcn:bsd-gcc-shared:-
fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
+FreeBSD-sparc64,$ENV{CC}:-DTERMIOS -DB_ENDIAN -DULTRASPARC
-DBN_DIV2W $ENV{CFLAGS}::(unknown):::SIXTY_FOUR_BIT_LONG RC4_CHAR
RC4_CHUNK DES_INT DES_PTR DES_RISC1 DES_UNROLL
BF_PTR::dlfcn:bsd-gcc-shared:-
fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
+FreeBSD-ia64,$ENV{CC}:-DL_ENDIAN -DTERMIOS
$ENV{CFLAGS}::(unknown):::SIXTY_FOUR_BIT_LONG RC4_CHUNK
RC4_CHAR:asm/ia64-cpp.o:dlfcn:bsd-gcc-shared:-
fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
Alpha Linux with GNU C and Compaq C setups
# Special notes:
@@ -395,8 +397,8 @@
NetBSD-sparc, gcc:-DTERMIOS -O3 -fomit-frame-pointer -mv8 -Wall
-DB_ENDIAN::(unknown):::BN_LLONG MD2_CHAR RC4_INDEX
DES_UNROLL::dlfcn:bsd-gcc-shared:-
fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
NetBSD-m68,gcc:-DTERMIOS -O3 -fomit-frame-pointer -Wall
-DB_ENDIAN::(unknown):::BN_LLONG MD2_CHAR RC4_INDEX
DES_UNROLL::dlfcn:bsd-gcc-shared:-
fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
NetBSD-x86,gcc:-DTERMIOS -O3 -fomit-frame-pointer -m486
-Wall::(unknown):::BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}::dlfcn:bsd-gcc-shared:-
fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
-FreeBSD-elf, gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3
-m486 -Wall::-pthread -D_REENTRANT -D_THREAD_SAFE
-D_THREADSAFE:::BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:bsd-gcc-shared:-
fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
-FreeBSD, gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3
-m486 -Wall::(unknown):::BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_out_asm},
+FreeBSD-elf, $ENV{CC}:-DTERMIOS -DL_ENDIAN $ENV{CFLAGS}
-Wall::-pthread -D_REENTRANT -D_THREAD_SAFE
-D_THREADSAFE:::BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:bsd-gcc-shared:-
fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
+FreeBSD, $ENV{CC}:-DTERMIOS -DL_ENDIAN $ENV{CFLAGS}
-Wall::(unknown):::BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_out_asm},
bsdi-gcc, gcc:-O3 -ffast-math -DL_ENDIAN -DPERL5
-m486::(unknown):::RSA_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_bsdi_asm},
bsdi-elf-gcc, gcc:-DPERL5 -DL_ENDIAN -fomit-frame-pointer -O3
-m486 -Wall::(unknown)::-ldl:BN_LLONG ${x86_gcc_des}
[openssl.org #481] (0.9.7 on Win32) openssl ca crashes when exiting...
[[EMAIL PROTECTED] - Tue Jan 28 11:07:34 2003]: And (while i'm at it) another thing to mention: While we're mentioning stuff, I'd like to mention that we can handle bug reports much better if there's only *one* bug per report. Please keep that in mind in the future. I'm using openssl with stunnel. When i'm running stunnel as a service, RAND_poll in rand_win.c can't work, as it needs features not available under the SYSTEM account without a user logged in (i.e. the UI features) so it dropped all the stuff except for the CryptAcquireContext when building the service version. Although i'm totally dependent on MS- randomness now, everything works fine when runing as service now. OK, does anyone know a good way to detect (in run-time!) when the program is running as a service? If there's a way, the rest should be easy. And yet another thing: Usage of RAND_file_name() isn't working for a service-app with no logged-on user, too, when no filename is specified. After trying to get a filename from the environment (where none is defined), filename is filled with rubbish (could be that the environment is rubbish, or the OS...). So i don't use that under Win32 either. Interesting. Do you have an example of the rubbish? From what I can see, if the environment variables RANDFILE and HOME aren't defined, the result should be C:/.rnd. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #287] [PATCH] no-engine(openssl-0.9.7-stable-SNAP-20020915)
* Richard Levitte via RT ([EMAIL PROTECTED]) wrote: OK, I looked at the no-engine patch again, and really saw no harm in it, so it's committed, and will be part of all release from 0.9.7a and on (as well as the current 0.9.7 and main snapshots). This ticket is now resolved. Erm, I think there's a fundemantal problem with this. I understand the desire to build a version of openssl such that it doesn't include the engine footprint, nor its execution overheads. I could possibly accept that binary incompatibilities could be accepted between applications and/or libraries on the basis that you'd only bother doing this stuff if you were *determined* to have ENGINE surgically removed. Ie. we already state that for binary compatibility, 0.9.x !~ 0.9.(x+1), however we could perhaps also tolerate the situation where for a fixed 'x', 0.9.x-engine !~ 0.9.x-noengine. What I can't accept is that the precompiler symbol used to *build* a non-engine version of openssl is used in the exported header files in a way that alters the definitions of API structures. Ie. if you build a non-engine version of openssl, your application code will silently compile and link whether you defined OPENSSL_NO_ENGINE or not (and/or whether you define OPENSSL_NO_ENGINE before or after including the relevant headers) - *but* the resulting object code will use conflicting descriptions of data structures unless the app's author got everything correct. As for how this could impact distributions using system-wide versions of openssl as shared-libraries is obvious and so in this state, the nonengine approach would be considered untouchable even by those who want it. I know, the practise of system-wide shared libraries is not considered wise for openssl - but if distributors are vigilant about only using version-specific linking then IMHO that's OK, this type of configuration option threatens to break that. IMHO the better way to have handled this would have been to opaquely define the ENGINE type in crypto.h (this could also reduce some header dependencies on engine.h BTW) so that all the existing structures can remain as-is. Ie. if RSA has an ENGINE* member, leave it there - but disable all use of the ENGINE API in the RSA implementation (and the trick of #error in engine.h is fine). This way, whether you get ENGINE functionality, footprint, and overheads at run-time depends *only* on whether openssl was built with it or without it. It won't be essential for applications to bother defining OPENSSL_NO_ENGINE - though if they do it will correctly stop them accidently including engine.h (and thus prevent linker failures if they accidently try to use ENGINE functionality). The point is, compatibility between application object code and openssl (be it static or dynamic) won't be volatile. FYI: the easiest example to see the problem is EVP_MD_CTX in crypto/evp/evp.h:280 - the structure definition is incompatible if OPENSSL_NO_ENGINE is defined (or undefined, as the case may be). IMHO OPENSSL_NO_ENGINE shouldn't change structure definitions, it should change only the building of openssl implementation code. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.openssl.org/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #437] bad instructions in CHANGES for platform-dependent builds
I suspect it doesn't really matter if the links are made only for files that are not already links. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #287] [PATCH] no-engine(openssl-0.9.7-stable-SNAP-20020915)
In message [EMAIL PROTECTED] on Thu, 30 Jan 2003 13:33:59 -0500, Geoff Thorpe [EMAIL PROTECTED] said: geoff Erm, I think there's a fundemantal problem with this. I understand the geoff desire to build a version of openssl such that it doesn't include the geoff engine footprint, nor its execution overheads. I could possibly accept geoff that binary incompatibilities could be accepted between applications geoff and/or libraries on the basis that you'd only bother doing this stuff if geoff you were *determined* to have ENGINE surgically removed. Ie. we already geoff state that for binary compatibility, 0.9.x !~ 0.9.(x+1), however we geoff could perhaps also tolerate the situation where for a fixed 'x', geoff 0.9.x-engine !~ 0.9.x-noengine. From a functional point of view, this is not different from, for example, specifying no-rsa. geoff What I can't accept is that the precompiler symbol used to *build* a geoff non-engine version of openssl is used in the exported header files in a geoff way that alters the definitions of API structures. Ie. if you build a [...] Very good point. However: geoff IMHO the better way to have handled this would have been to opaquely geoff define the ENGINE type in crypto.h (this could also reduce some header geoff dependencies on engine.h BTW) so that all the existing structures can No need, there's a very practical line in ossl_typ.h :-). Working on the problem. Thanks for noticing it. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #484] openssl question
The best you can do at present is to either use the DER option in 0.9.7 if you know the encoding or the new mini-ASN1 compiler of 0.9.8. Neither of which is particularly easy to do. What do you mean the DER option in 0.9.7? Do I modify the IP address to DER and put it in the config file? subjectAltName=IP:DER:DER encoding of IPv6 address Is there some examples of doing this? __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #481] (0.9.7 on Win32) openssl ca crashes when exiting...
I'm using openssl with stunnel. When i'm running stunnel as a service, RAND_poll in rand_win.c can't work, as it needs features not available under the SYSTEM account without a user logged in (i.e. the UI features) so it dropped all the stuff except for the CryptAcquireContext when building the service version. Although i'm totally dependent on MS- randomness now, everything works fine when runing as service now. OK, does anyone know a good way to detect (in run-time!) when the program is running as a service? If there's a way, the rest should be easy. That's a bit coarse. It might be sufficient to allow the service to interact with the desktop [interactive user] (as admin user, right click on My Computer, select Manage..., navigate to the services section, right click on the indicated service, choose the Log On tab, and under the radio button for Local System account there's a checkbox (off by default): Allow service to interact with desktop. This can also be enabled when the service registers itself at installation. See MS Knowledge Base article number 115825 (formerly Q115825), as well as the documentation on ::CreateService() and search for SERVICE_INTERACTIVE_PROCESS. Of course some customer locations might be reticent about letting services interact with the desktop, this being a potential security hole. But is there a bug here? If it runs okay (with limited functionality) if the service doesn't have permissions to access the desktop, isn't that correct? What would you have it do differently if it did detect that it was running as a service? Is there some alternative source of randomness? (Perhaps the number of patches applied to the system? :-). If so, it might be best to detect the problem at the specific API call that fails rather than decide based on running as a service -- partly because it might work running as a service, partly because it might fail for other reasons when not running as a service. Larry West mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #481] (0.9.7 on Win32) openssl ca crashes when exiting...
I'm using openssl with stunnel. When i'm running stunnel as a service, RAND_poll in rand_win.c can't work, as it needs features not available under the SYSTEM account without a user logged in (i.e. the UI features) so it dropped all the stuff except for the CryptAcquireContext when building the service version. Although i'm totally dependent on MS- randomness now, everything works fine when runing as service now. OK, does anyone know a good way to detect (in run-time!) when the program is running as a service? If there's a way, the rest should be easy. That's a bit coarse. It might be sufficient to allow the service to interact with the desktop [interactive user] (as admin user, right click on My Computer, select Manage..., navigate to the services section, right click on the indicated service, choose the Log On tab, and under the radio button for Local System account there's a checkbox (off by default): Allow service to interact with desktop. This can also be enabled when the service registers itself at installation. See MS Knowledge Base article number 115825 (formerly Q115825), as well as the documentation on ::CreateService() and search for SERVICE_INTERACTIVE_PROCESS. Of course some customer locations might be reticent about letting services interact with the desktop, this being a potential security hole. But is there a bug here? If it runs okay (with limited functionality) if the service doesn't have permissions to access the desktop, isn't that correct? What would you have it do differently if it did detect that it was running as a service? Is there some alternative source of randomness? (Perhaps the number of patches applied to the system? :-). If so, it might be best to detect the problem at the specific API call that fails rather than decide based on running as a service -- partly because it might work running as a service, partly because it might fail for other reasons when not running as a service. Larry West mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #484] openssl question
[[EMAIL PROTECTED] - Thu Jan 30 20:06:27 2003]: The best you can do at present is to either use the DER option in 0.9.7 if you know the encoding or the new mini-ASN1 compiler of 0.9.8. Neither of which is particularly easy to do. What do you mean the DER option in 0.9.7? Do I modify the IP address to DER and put it in the config file? subjectAltName=IP:DER:DER encoding of IPv6 address Is there some examples of doing this? I did say it wasn't particularly easy didn't I? You have to manually work out the encoding or use the 0.9.8 asn1parse to do it for you. If you *only* want one entry in subjectAltName then you can do: subjectAltName=DER:87:10:00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F where you change those last 16 hex values 00-0F to whatever the IPv6 address is. The 87:10 bit are the implicit tag 7 and length 0x10 bytes. However no version of OpenSSL will currently display that correctly. This isn't very friendly and proper IPv6 support will be added at some stage. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #327] compilation errors for openssl 0.9.8
[[EMAIL PROTECTED] - Fri Nov 1 16:57:20 2002]: Notes on documentation files: - The FAQ (Why does the OpenSSL compilation fail on Win32 with VC++?)refers to using VCVARS32.BAT. That is the correct name for VC++6. For VS.NET (think of it as 'VC++7'), the name is VSVARS32.BAT instead. - Install.w32 refers to MASM and how it was included in old versions of MSVC. It should be remarked that the latest version of MSVC (VS.NET), includes MASM again. Fixed, will appear in 0.9.7a and on. Errors during build (based on snapshot dated 20021031). - a bunch of signed/unsigned mismatches. The code compiles after adding some (int) casts. I have no clue whether those are valid though. The affected lines are: warning C4018: '=' : signed/unsigned mismatch in: crypto\ec\ec2_smpl.c lines 173 174 198 203 crypto\bn\bn_gf2m.c lines 877 897 warning C4018: '' : signed/unsigned mismatch crypto\ec\ec2_mult.c line 349 To be fixed... - There is something wrong with the macros that disable hardware support. Some parts of the build procedure think it is not necessary to build the hardware support engines, other parts still want to use them. During the first link trial, I got a bunch of 'unresolved external symbol' messages for these exported functions: ENGINE_load_4758cca ENGINE_load_aep ENGINE_load_atalla ENGINE_load_chil ENGINE_load_cswift ENGINE_load_nuron ENGINE_load_sureware ENGINE_load_ubsec Manually editing LIBEAY32.def to exclude those exports fixes this, but I guess the scripts that generate it should be adapted. To be fixed... - By the way, I also got the following message: ms/LIBEAY32.def(7) : warning LNK4017: DESCRIPTION statement not supported for the target platform; ignored IIRC the 'DESCRIPTION' line in a .def file is a remainder of the 16 bit era. It should not be there in the 32 bit .def files. To be fixed... - During the next link run 'unresolved external symbol' messages related to the previous ones show up. This time not from the exports (.def), but all of them from 'eng_all.obj'. The missing symbols are exactly the same as above. To be fixed... Adding adding '-DOPENSSL_NO_HW' to CFLAG in the makefile and recompiling fixes this, but once again, I guess the scripts should be updated. (no change in eng_all.c is needed). Fixed, I'll commit them in a moment. However, that will not fix all the problems. After these changes, the libraries compile. During compilation of the apps the following error shows up: apps\ca.c(97) : fatal error C1083: Cannot open include file: 'sys/file.h': No such file or directory A snapshot I used last week (20021022) did not have this error. OK, then I won't bother looking at it... -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #359] Calling SSL_read and SSL_write with non-empty error stack may cause an error
Any more thoughts on this issue? -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #359] Calling SSL_read and SSL_write with non-empty error stack may cause an error
On Thu, Jan 30, 2003 at 10:09:22PM +0100, Richard Levitte via RT wrote: Any more thoughts on this issue? The problem is not yet solved. Using the global error stack as error indicator instead of correctly passing state back via return values is a design flaw. It happend to make problems in the past. I am currently busy as hell, so I will probably not be able to fix it over the next days. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #359] Calling SSL_read and SSL_write with non-empty error stack may cause an error
OK... [jaenicke - Thu Jan 30 22:21:50 2003]: On Thu, Jan 30, 2003 at 10:09:22PM +0100, Richard Levitte via RT wrote: Any more thoughts on this issue? The problem is not yet solved. Using the global error stack as error indicator instead of correctly passing state back via return values is a design flaw. It happend to make problems in the past. I am currently busy as hell, so I will probably not be able to fix it over the next days. Best regards, Lutz -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #11] Fw: trustway pkcs11 engine for openssl
Hello Richard, Richard Levitte via RT wrote: It's unfortunate that cryptoki.h is GPLd, or I would put it in our contribution area. GPL is not compatible with the OpenSSL license. Is it possible to get a different cryptoki.h? I got the original cryptoki.h which is not GPLd from RSA and is a sample for Windows environment. I have added necessary changes for Unix-like platforms. Also, is conf.h really necssary? You're absolutely right, conf.h is not necessary. I take it off. I'm willing to do the transformation needed for this bundle to work properly within OpenSSL. So, you can find attached to this mail updates taking in account your advice. Cheers, Afchine Madjlessi __ [EMAIL PROTECTED] Bull TrustWay RD, France http://www.servers.bull.com/trustway __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #11] Fw: trustway pkcs11 engine for openssl
__ [EMAIL PROTECTED] Bull TrustWay RD, France http://www.servers.bull.com/trustway __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #364] Fw: BUG ?: ssl_bio.c increase reference count (BIO_push), but doesn't remove it (BIO_pop)
I applied your changes, to be committed as soon as my tests get through. Please try
the next snapshot and send in a new bug report if it still doesn't work properly.
This ticket is now resolved.
[[EMAIL PROTECTED] - Tue Nov 26 09:37:12 2002]:
Below msg is a re-send to the correct address [EMAIL PROTECTED] -- Sorry
for
mailing it to the wrong place!! /Jonas
- Original Message -
From: Jonas Sundgren [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 26, 2002 2:43 AM
Subject: BUG ?: ssl_bio.c increase reference count (BIO_push), but
doesn't
remove it (BIO_pop)
Env: openssl-0.9.6g (9-aug-2002), VC6/masm, WinXP
Hi,
When you do BIO_push on a SSL BIO object, reference count
(CRYPTO_LOCK_BIO)
is increased on next BIO object. The problem is when you later pop
the SSL
BIO, then the reference count isn't decreased. This isn't a problem
as
long
as you're supposed to do BIO_free twice on next BIO (a socket BIO in
my
case). I want to do one, single BIO_free on my socket BIO and it
should
shutdown/close the socket--but that doesn't work! (Example code
below,
after
the diff)
Is this correct behavior? Have I missed something? If not, below fix
works
for me:
Index: crypto/bio/bio_lib.c
===
RCS file: c:\cvsroot/openssl-0.9.6g/crypto/bio/bio_lib.c,v
retrieving revision 1.1
diff -u -r1.1 bio_lib.c
--- crypto/bio/bio_lib.c 2 Nov 2002 13:02:10 - 1.1
+++ crypto/bio/bio_lib.c 26 Nov 2002 00:48:15 -
@@ -381,6 +381,9 @@
if (b == NULL) return(NULL);
ret=b-next_bio;
+
+/* called to do internal process before bio is unlinked */
+BIO_ctrl(b,BIO_CTRL_POP,0,NULL);
if (b-prev_bio != NULL)
b-prev_bio-next_bio=b-next_bio;
@@ -389,7 +392,6 @@
b-next_bio=NULL;
b-prev_bio=NULL;
- BIO_ctrl(b,BIO_CTRL_POP,0,NULL);
return(ret);
}
Index: ssl/bio_ssl.c
===
RCS file: c:\cvsroot/openssl-0.9.6g/ssl/bio_ssl.c,v
retrieving revision 1.1
diff -u -r1.1 bio_ssl.c
--- ssl/bio_ssl.c 2 Nov 2002 13:03:47 - 1.1
+++ ssl/bio_ssl.c 26 Nov 2002 01:28:44 -
@@ -399,6 +399,8 @@
{
BIO_free_all(ssl-wbio);
}
+ if (b-next_bio != NULL)
+ CRYPTO_add(b-next_bio-references,-1,CRYPTO_LOCK_BIO);
ssl-wbio=NULL;
ssl-rbio=NULL;
break;
Example code:
...
sockbio = BIO_new_socket(s, BIO_CLOSE);
sslbio = BIO_new_ssl(g_Ssl.ctx, TRUE);
if (!sslbio)
goto cleanup;
BIO_push(sslbio, sockbio);
if (BIO_do_connect(sslbio) = 0)
goto cleanup;
SendHttpRequest(sslbio);
ReadHttpResponse(sslbio);
BIO_ssl_shutdown(sslbio);
BIO_pop(sslbio);
success = TRUE;
cleanup:
/* BUG ?: Have to do BIO_free twice on sockbio, otherwise it
won't
free
it nor close the socket */
BIO_free(sockbio);
BIO_free(sslbio);
...
Thanks,
Jonas Sundgren
PS. The same problem exists in openssl-0.9.7-beta4 as well.
--
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #449] [Fwd: Bug#176059: openssl: ca shows CSR contents, not preview of certificate]
Since the 0.9.6 branch is now dead, I suggest this ticket gets killed. [steve - Sat Jan 11 02:13:30 2003]: [[EMAIL PROTECTED] - Fri Jan 10 15:10:09 2003]: Ugh, can't quote the original message... This refers to OpenSSL 0.9.6X which does indeed only show the DN of the CSR (or pseudo CSR in the case of SPKACs) including the old mishandling of multibyte string types. That's one reason why I didn't add extension copying to 0.9.6X: you can't see what extensions you are adding which is a big security issue. OpenSSL 0.9.7 does not have this problem and the contents of the preview are highly configurable, including such things as extensions in the certificate. See 0.9.7 docs. Steve. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #451] SX6 port
Will anything happen with this? [[EMAIL PROTECTED] - Sat Jan 18 11:02:31 2003]: I already answered this once, but it didn't come through for some reason... + sx6, cc:-g -DTERMIOS::(unknown):::SIXTY_FOUR_BIT DES_INT:::, No optimization? Not even lousy -O? -g overrides any optimization you give, Yes, that's what normally happens... and i think there's a problem with the optimizer anyway because with default optimization, aes-128-cbc test fails. it's fine with -g. I wonder if AES is the only one affected. Could you run 'make -k test' and submit output? A. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #457] bug report: BIO_socket_nbio() can't set socket to non-blocking
Hmm, BIO_socket_ioctl() should really take a void* instead of an unsigned long *. Then, BIO_socket_nbio() should send a pointer to an int instead of a pointe to a long. The latter can be done anyway and pushed through useing a cast (ugly), or we could change that last argument type to BIO_socket_ioctl(), but that breaks the API (at least at source level). *sigh* [[EMAIL PROTECTED] - Tue Jan 14 09:48:11 2003]: bug report: openssl operating system: HP-UX11 openssl version 0.9.6b, 0.96g and probably 0.7 too. configuration options:./Configure hpux64-parisc-cc shared no-idea Description: BIO_socket_nbio() fails to set sockets to non-blocking mode. The call succeeds but the socket is still blocking I have noticed that BIO_socket_nbio() calls BIO_socket_ioctl() unsing FIONBIO. This ioctl, according to it's man page, takes one argument: a pointer to int, but the BIO_socket_ioctl() uses a pointer to long as the argument. This will result in that the os will only read the 32 most significant bits of the 64 bit long value that is set to 0 or 1 by BIO_socket_nbio(). These bits are always 0 and the call will always set the socket to blocking mode. (If I patch BIO_socket_ioctl() to send a pointer to int instead the calls to BIO_socket_nbio() work as expected.) Regards /Magnus Lind -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #486] ocsp.c make_ocsp_response() fix
Stephen Henson via RT wrote: However a bug was introduced into 0.9.7 ASN1_TIME_to_generalizedtime() which causes problems in this conversion. This change would work around the problem without addressing the underlying cause. Since the ASN1_TIME_to_generalizedtime() bug has now been fixed in 0.9.7-stable I suggest the OP checks the latest stable snapshot. Steve. Thanks for pointing this out. Indeed, patching in the asn1 changes from the latest snapshot fixes the problems I was seeing. And sorry, I should have pointed out from the beginning that it was 0.9.7 release that I was using. Thanks! -John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #486] ocsp.c make_ocsp_response() fix
Stephen Henson via RT wrote: However a bug was introduced into 0.9.7 ASN1_TIME_to_generalizedtime() which causes problems in this conversion. This change would work around the problem without addressing the underlying cause. Since the ASN1_TIME_to_generalizedtime() bug has now been fixed in 0.9.7-stable I suggest the OP checks the latest stable snapshot. Steve. Thanks for pointing this out. Indeed, patching in the asn1 changes from the latest snapshot fixes the problems I was seeing. And sorry, I should have pointed out from the beginning that it was 0.9.7 release that I was using. Thanks! -John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #484] openssl question
[steve - Thu Jan 30 20:44:34 2003]: [[EMAIL PROTECTED] - Thu Jan 30 20:06:27 2003]: What do you mean the DER option in 0.9.7? Do I modify the IP address to DER and put it in the config file? subjectAltName=IP:DER:DER encoding of IPv6 address Is there some examples of doing this? I did say it wasn't particularly easy didn't I? You have to manually work out the encoding or use the 0.9.8 asn1parse to do it for you. If you *only* want one entry in subjectAltName then you can do: subjectAltName=DER:87:10:00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F where you change those last 16 hex values 00-0F to whatever the IPv6 address is. The 87:10 bit are the implicit tag 7 and length 0x10 bytes. Oops, sorry that isn't correct. You need an outer SEQUENCE OF wrapper as well. The correct form is: subjectAltName=DER:30:12:87:10:00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F this will show up in current versions of OpenSSL as invalid. I'll shortly add support which will make 0.9.8-dev correctly display this and permit the more standard IPv6 formats to be used. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #484] openssl question
[steve - Thu Jan 30 20:44:34 2003]: However no version of OpenSSL will currently display that correctly. This isn't very friendly and proper IPv6 support will be added at some stage. Do you have any ideia when? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #484] openssl question
In message [EMAIL PROTECTED] on Fri, 31 Jan 2003 04:59:36 +0100 (MET), via RT [EMAIL PROTECTED] said: rt rt [steve - Thu Jan 30 20:44:34 2003]: rt rt However no version of OpenSSL will currently display that correctly. rt rt This isn't very friendly and proper IPv6 support will be added at some rt stage. rt rt Do you have any ideia when? 0.9.8 at the earliest. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #484] openssl question
In message [EMAIL PROTECTED] on Fri, 31 Jan 2003 04:59:36 +0100 (MET), via RT [EMAIL PROTECTED] said: rt rt [steve - Thu Jan 30 20:44:34 2003]: rt rt However no version of OpenSSL will currently display that correctly. rt rt This isn't very friendly and proper IPv6 support will be added at some rt stage. rt rt Do you have any ideia when? 0.9.8 at the earliest. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #487] bug in BN_generate_prime for small n.
for num 15 .. always get the same result.. and it's larger than
expected...
We are using small primes to verify the correctness of our system.
thanks,
Cameron
#include openssl/bn.h
#include stdio.h
/*
* @author Cameron Gregory, http://www.bloke.com/
*/
char *me=NULL;
int debug=0;
int main(int argc, char **argv) {
BIGNUM *a1;
int i;
a1=BN_new();
for (i=2;i100;i++) {
if (NULL == BN_generate_prime (a1, i, 1, NULL,NULL,NULL,NULL)) {
printf(Unable to generate prime %d\n,i);
}
printf(%d: %s\n,i,BN_bn2hex(a1));
}
}
results:
2: 8C27
3: 8C27
4: 8C27
5: 8C27
6: 8C27
7: 8C27
8: 8C27
9: 8C27
10: 8C27
11: 8C27
12: 8C27
13: 8C27
14: 8C27
15: 8C27
16: ECE7
17: 01A25B
18: 038D77
19: 0655D3
20: 0C368F
21: 1A2F5B
22: 3D850F
23: 7533EF
24: F4185B
25: 01B4BF83
26: 038730BF
27: 07A6A347
28: 0EF9162F
29: 1F0C620B
30: 32B63F67
31: 7B17C807
32: D716DA9F
33: 01B321AE0B
34: 03D925F39F
35: 0764FA9DA3
36: 0DC6B9353F
37: 1BB6933783
38: 36A28D04D3
39: 6BB4BA8C97
40: D779689747
41: 018359F5241F
42: 0343F06D6EA3
43: 074E222178C3
44: 0EBF611AE0E3
45: 1ED25F8860E3
46: 3823AF4FE90F
47: 602FF5CC8A7F
48: D169DC5514D7
49: 01D48FB5A55597
50: 03C9AF37049ECF
51: 0667D931FDACF3
52: 0FC6A0D3A9A53B
53: 1CD6DA5D6A65BB
54: 37EB10ABDA7467
55: 66CA77CE1C2E13
56: F075A0793F499B
57: 01C95701E092192B
58: 03FBB79E0E62A3CB
59: 0613EC8029C4529B
60: 0E921F8D99BD0CAB
61: 1FE6F748C594191B
62: 3D4892183B4ECCF3
63: 63DF49231F761ECB
64: CC3E615B976F3D9B
65: 01E0F4F1B958ECB743
66: 03C5F567C2BCBE6697
67: 07A46BA12AFD174993
68: 0C90FFA863203A8CAB
69: 1A668050E56F7F4F6B
70: 396D85F0136F83C0AB
71: 6F8D2D733A69942693
72: EC63DE740DF6A87E6F
73: 01DE7DFD5662607999CB
74: 03B763A9E39C7202FDA7
75: 078C0D69F06DB72DC21F
76: 0F162DFB8BBBA24AFC07
77: 1A11991D665E8CF8D083
78: 3EBD39B39D1AA9D07253
79: 661E0370D398889A6B0F
80: C86BCEFE5D99F40E123F
81: 01A9F109944BB86CC0178B
82: 03D3395F310814CC97DF07
83: 0711C74C462FEF78138E6B
84: 0E6E1108356D70A59DA5DF
85: 1E789D2D50B4FAEB12CE1F
86: 3C69A1C665E3FE963ADB0B
87: 6E4DE3C7FBD5407347BE1B
88: D8C1EC0C4B562E07EF9D97
89: 0194756C9350E0ACDB4F138F
90: 03853388D6F5B2058E4A370B
91: 0681E38E4A0CF39D1D689C2B
92: 0C435421130F2A3D66E5CB2F
93: 1B4A72F60CAE19DDE9024307
94: 32FFBD19BFA94866F0D1E38B
95: 7893A1FEC63B8DC63717B4BF
96: F4C76B5A5244656E2B87794F
97: 01FB1B57E63DFD289042EFA003
98: 03024A0E2D38DE63B6FF679F9F
99: 0782B0E8C13EFD7A169E2849AF
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
