[openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom
Hello!
Since 5.2 AIX supports /dev/random and /dev/urandom. Openssl don't use it
because the select
system call works different on AIX than on linux.
As described in the following URL, the select system call expects the
number
of file describtors as first parameter in AIX. Linux expects the highst
numbered
fd +1.
http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/commtrf1/select.htm
So I made a #ifdef and hardcoded the first parameter to 1 for AIX. I'm not
sure
if this will have any side effects, especially for versions 5.2 but I
don't
think so.
The attached patch will do the change on the file
openssl-0.9.7a/crypto/rand/rand_unix.c.
Anders Liljegren tested it also on AIX 5.2 and found no problems.
Bye
Andreas Walter
diff -u openssl-0.9.7a/crypto/rand/rand_unix.c-orig
openssl-0.9.7a/crypto/rand/rand_unix.c
--- openssl-0.9.7a/crypto/rand/rand_unix.c-orig 2003-03-28
14:23:01.0 +0100
+++ openssl-0.9.7a/crypto/rand/rand_unix.c 2003-03-28
14:45:19.0 +0100
@@ -170,7 +170,14 @@
FD_SET(fd, fset);
r = -1;
+#ifdef AIX /* First paramater on AIX Specifies the number of file
descriptors and message
+* queues to check. See also:
+*
http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/commtrf1/select.htm
+*/
+ if (select(1,fset,NULL,NULL,t)
0)
+#else
if (select(fd+1,fset,NULL,NULL,t) 0)
+#endif
t.tv_usec=0;
else if (FD_ISSET(fd, fset))
{
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #559] X509V3_extensions_print
Hi, I tried to output the extensions without a title: X509V3_extensions_print (out, NULL, ci-extensions, 0, 0); The code fails because of the following: 1. title is empty -- indent will not be incremented 2. if (BIO_printf(bp,%*s,indent, ) = 0) return 0; This printf tries to print an empty string. Printf returns in this case a zero which is correct and not an error. There are two possible patches - accept a zero or don't print. the attached patch use the second option. I used 0.9.7a for diff and the file is crypto/x509v3/v3_prn.c. Best regards Michael -- --- Michael Bell Email: [EMAIL PROTECTED] ZE Computer- und MedienserviceTel.: +49 (0)30-2093 2482 (Computing Centre)Fax: +49 (0)30-2093 2704 Humboldt-University of Berlin Unter den Linden 6 10099 Berlin Email (private): [EMAIL PROTECTED] Germany http://www.openca.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #560] fingerprint in apps/crl.c
Hi, the fingerprint option in apps/crl.c is not documented in 0.9.7a if the online help is used. The simple patch is attached. Best regards Michael -- --- Michael Bell Email: [EMAIL PROTECTED] ZE Computer- und MedienserviceTel.: +49 (0)30-2093 2482 (Computing Centre)Fax: +49 (0)30-2093 2704 Humboldt-University of Berlin Unter den Linden 6 10099 Berlin Email (private): [EMAIL PROTECTED] Germany http://www.openca.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #555] RSA blinding MT patch
Could you please download the latest 0.9.6 snapshot and check that it works for you? As far as I understand, the MT issue has been adressed, but solved in a different manner. [EMAIL PROTECTED] - Fri Mar 28 08:22:16 2003]: This patch fixes the multithreading issues I was having when an RSA struct was being used by multiple threads simultaneously with blinding enabled. It adds _r versions of the convert/invert functions to save the unblinding value, and does the update in the convert step. rsa_eay.c uses the RSA_BLINDING lock to make the convert-and-update step atomic. The patch is for 0.9.6i. Tom -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #560] fingerprint in apps/crl.c
Applied. Thanks. Ticket resolved. [EMAIL PROTECTED] - Mon Mar 31 14:44:47 2003]: Hi, the fingerprint option in apps/crl.c is not documented in 0.9.7a if the online help is used. The simple patch is attached. Best regards Michael -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #559] X509V3_extensions_print
[EMAIL PROTECTED] - Mon Mar 31 13:12:19 2003]: The code fails because of the following: 1. title is empty -- indent will not be incremented 2. if (BIO_printf(bp,%*s,indent, ) = 0) return 0; This printf tries to print an empty string. Printf returns in this case a zero which is correct and not an error. There are two possible patches - accept a zero or don't print. the attached patch use the second option. I used 0.9.7a for diff and the file is crypto/x509v3/v3_prn.c. Nice catch! Actually, from looking at the rest of the file, I'm surprised the return value of that particular BIO_printf() is tested at all, but there are probably hysterical raisins behind that one. Anyway, I've applied your patch and committed. Thank you. Ticket resolved. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #556] x509 -setalias
Fixed. Thanks. Ticket resolved. [EMAIL PROTECTED] - Fri Mar 28 14:06:43 2003]: Hi, I discovered that -setalias in apps/x509.c is tested twice. It's not a real bug but it is unnecessary. I use 0.9.7a. Best regards Michael -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #554] Fw: FreeBSD Problem
You might want to investigate why there isn't a dso_win32.o... [EMAIL PROTECTED] - Fri Mar 28 08:20:27 2003]: Sorry I meant I edited the $HOME/crypto/dso/Makefile.ssl file. - Original Message - From: RCS To: [EMAIL PROTECTED] Sent: Thursday, March 27, 2003 9:35 PM Subject: FreeBSD Problem While compiling 0.9.7.a on FreeBSD 4.6.2-p9 I got the following error while doing 'make': ar r ../../libcrypto.a dso_dl.o dso_dlfcn.o dso_err.o dso_lib.o dso_null.o dso_openssl.o dso_win32.o dso_vms.o /usr/libexec/elf/ar: dso_win32.o: No such file or directory *** Error code 1 Stop in /usr/src/crypto/openssl/crypto/dso. *** Error code 1 Stop in /usr/src/crypto/openssl/crypto. *** Error code 1 Stop in /usr/src/crypto/openssl. I edited $HOME/crypto/Makefile.ssl, removed all dso_win32 entries, and the problem was fixed did make again and worked. Please let me know if this is really a bug or I did something wrong. This happened to me in two separate systems. I don't think it's necessary to include the output of 'make report' Thanks -- Roberto Cardona Jr. IT/IS Manager Corporate Office Centers | http://www.corporateofficecenters.com -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #555] RSA blinding MT patch
On Mon, Mar 31, 2003 at 03:01:10PM +0200, Richard Levitte via RT wrote: Could you please download the latest 0.9.6 snapshot and check that it works for you? As far as I understand, the MT issue has been adressed, but solved in a different manner. The latest snapshots have not been fixed, some more patience is required ... -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #554] Fw: FreeBSD Problem
Shouldn't the configure script take care of this automatically? - Original Message - From: Richard Levitte via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, March 31, 2003 10:07 AM Subject: [openssl.org #554] Fw: FreeBSD Problem You might want to investigate why there isn't a dso_win32.o... [EMAIL PROTECTED] - Fri Mar 28 08:20:27 2003]: Sorry I meant I edited the $HOME/crypto/dso/Makefile.ssl file. - Original Message - From: RCS To: [EMAIL PROTECTED] Sent: Thursday, March 27, 2003 9:35 PM Subject: FreeBSD Problem While compiling 0.9.7.a on FreeBSD 4.6.2-p9 I got the following error while doing 'make': ar r ../../libcrypto.a dso_dl.o dso_dlfcn.o dso_err.o dso_lib.o dso_null.o dso_openssl.o dso_win32.o dso_vms.o /usr/libexec/elf/ar: dso_win32.o: No such file or directory *** Error code 1 Stop in /usr/src/crypto/openssl/crypto/dso. *** Error code 1 Stop in /usr/src/crypto/openssl/crypto. *** Error code 1 Stop in /usr/src/crypto/openssl. I edited $HOME/crypto/Makefile.ssl, removed all dso_win32 entries, and the problem was fixed did make again and worked. Please let me know if this is really a bug or I did something wrong. This happened to me in two separate systems. I don't think it's necessary to include the output of 'make report' Thanks -- Roberto Cardona Jr. IT/IS Manager Corporate Office Centers | http://www.corporateofficecenters.com -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RSA Blinding patch and a recent snapshot.
Title: RSA Blinding patch and a recent snapshot.
Hi,
I downloaded a snapshot recently, openssl-e-0.9.6-stable-SNAP-20030327.tar.gz,
and was comparing the files [.crypto.rsa]rsa_eay.c AND [.crypto.rsa]rsa_lib.c. I noticed
that in rsa_eay.c that the patch used the positive when comparing, RSA_FLAG_BLINDING,
and the snapshot used the negative, RSA_FLAG_NO_BLINDING. Here is the macro
BLINDING_HELPER, and it shows the differences:
From the patch:
#define BLINDING_HELPER(rsa, ctx, err_instr) \
do { \
if(((rsa)-flags RSA_FLAG_BLINDING) \
((rsa)-blinding == NULL) \
!rsa_eay_blinding(rsa, ctx)) \
err_instr \
} while(0)
From the snapshot:
#define BLINDING_HELPER(rsa, ctx, err_instr) \
do { \
if((!((rsa)-flags RSA_FLAG_NO_BLINDING)) \
((rsa)-blinding == NULL) \
!rsa_eay_blinding(rsa, ctx)) \
err_instr \
} while(0)
As for RSA_LIB.C, it looks like only part of the patch has been
applied to the snapshot. We call RSA_new_method and it is return is
placed into r, but then we simply return r. We do not check if
OPENSSL_NO_FORCE_RSA_BLINDING is defined not do we set
r-flags with RSA_FLAG_BLINDING.
Have I missed something in the mailing lists that would
explain these differences?
Thanks,
Kevin.
Kevin Greaney SSL for OpenVMS Team
Hewlett Packard Company OpenVMS Engineering Group
110 Spitbrook Road
Nashua, NH 03062
(603) 884-5099
RE: [openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Lutz Jaenicke via RT On Mon, Mar 31, 2003 at 10:54:31AM +0200, [EMAIL PROTECTED] via RT wrote: Since 5.2 AIX supports /dev/random and /dev/urandom. Openssl don't use it because the select system call works different on AIX than on linux. As described in the following URL, the select system call expects the number of file describtors as first parameter in AIX. Linux expects the highst numbered fd +1. http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/c ommtrf1/select.htm Are you sure? select() is around since UNIX exists, that means the early 70s, maybe longer. I am not that good when it comes to UNIX history :-) I would not believe that IBM would break more or less all programs by chaning the select() API in an incompatible way. This is a non-issue; they are two different ways of saying the same thing. The AIX description is the same one all Unix systems with select() have used since... 4.2BSD. I don't recall if 4.1 had select() or not. Think about it. The fdset is a bit field. The nfds parameter tells select how far into the field it needs to look. Each bit corresponds to one fd. If you have fd#0, that corresponds to bit #1. This is why the number of fds is *always* the highest numbered fd +1. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom
select() expects the first parameter to contain the number of fd's to be checked in all flavours of Unix. Andreas is confusing the number of fd's to be checked (n) with the numbering of fd's (0 -(n-1)). This may explain some bugs :-) Chris Brook -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Lutz Jaenicke via RT Sent: Monday, March 31, 2003 1:56 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom On Mon, Mar 31, 2003 at 10:54:31AM +0200, [EMAIL PROTECTED] via RT wrote: Since 5.2 AIX supports /dev/random and /dev/urandom. Openssl don't use it because the select system call works different on AIX than on linux. As described in the following URL, the select system call expects the number of file describtors as first parameter in AIX. Linux expects the highst numbered fd +1. http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/commtrf1/select ..htm Are you sure? select() is around since UNIX exists, that means the early 70s, maybe longer. I am not that good when it comes to UNIX history :-) I would not believe that IBM would break more or less all programs by chaning the select() API in an incompatible way. 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 Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom
This is a non-issue; they are two different ways of saying the same thing. The AIX description is the same one all Unix systems with select() have used since... 4.2BSD. I don't recall if 4.1 had select() or not. Think about it. The fdset is a bit field. The nfds parameter tells select how far into the field it needs to look. Each bit corresponds to one fd. If you have fd#0, that corresponds to bit #1. This is why the number of fds is *always* the highest numbered fd +1. They are *not* the same thing. I may have only one fd with a value of 100. IBM's select asks that nfdsmsgs (the first parameter) be set to 1. (kind like poll) Linux/BSD requires it be set to 101. Not all implementations of fd_set's and hence select() use bit arrays (win32 does not either but it ignores the first parameter of select). And the behaviour of select() is not consistant across implementations either. Linux has a different behaviour from the standard BSD/UNIX/win32. Just ask anyone who's tried to code select for a non-blocking socket connect -lee __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom
select() expects the first parameter to contain the number of fd's to be checked in all flavours of Unix. No. It is 1+(maxfd). Traditioanlly they are the same, but for long-running servers that open and close things and have holes they won't be. /r$ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dilkie, Lee This is a non-issue; they are two different ways of saying the same thing. The AIX description is the same one all Unix systems with select() have used since... 4.2BSD. I don't recall if 4.1 had select() or not. Think about it. The fdset is a bit field. The nfds parameter tells select how far into the field it needs to look. Each bit corresponds to one fd. If you have fd#0, that corresponds to bit #1. This is why the number of fds is *always* the highest numbered fd +1. They are *not* the same thing. Wrong. I may have only one fd with a value of 100. IBM's select asks that nfdsmsgs (the first parameter) be set to 1. (kind like poll) Wrong. Linux/BSD requires it be set to 101. Not all implementations of fd_set's and hence select() use bit arrays (win32 does not either but it ignores the first parameter of select). The man page on the referenced URL states that the fdset is a bitmask. Please re-read the documentation: http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/basetrf2/select. htm#HDRA15691187 Quoting from the above page: NfdsmsgsSpecifies the number of file descriptors and the number of message queues to check. The low-order 16 bits give the length of a bit mask that specifies which file descriptors to check; the high-order 16 bits give the size of an array that contains message queue identifiers. If either half of the Nfdsmsgs parameter is equal to a value of 0, the corresponding bit mask or array is assumed not to be present. The Nfds parameter is the length of the bitmask. This is exactly the same definition as on BSD. Changing this definition would totally break compatibility with all Unix networking software written to date. They're not that stupid. And the behaviour of select() is not consistant across implementations either. Linux has a different behaviour from the standard BSD/UNIX/win32. Just ask anyone who's tried to code select for a non-blocking socket connect Linux was never originally intended to be Just Like Unix. It has been forced into that direction by later generations of hackers, but some of its early design decisions remain to this day. So it goes. As someone once said, Those who don't understand Unix are doomed to reimplement it, badly. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #552] [Fwd: Bug#186490: libssl0.9.7: EVP_{En,De}cryptFinal() don't free ctx parameter]
An application should call EVP_CIPHER_CTX_cleanup() after a cipher context is finished with to free up any allocated memory. Before 0.9.7 not calling this function on a ctx wouldn't leak memory but it would still leave sensitive information around: so calling it was always a good idea. Unfortunately it isn't possible to free up the context in the EVP_*Final function because this would break existing applications which reuse a cipher context after calling EVP_*Final(). Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom
On Mon, Mar 31, 2003 at 10:54:31AM +0200, [EMAIL PROTECTED] via RT wrote: Since 5.2 AIX supports /dev/random and /dev/urandom. Openssl don't use it because the select system call works different on AIX than on linux. As described in the following URL, the select system call expects the number of file describtors as first parameter in AIX. Linux expects the highst numbered fd +1. http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/commtrf1/select.htm Are you sure? select() is around since UNIX exists, that means the early 70s, maybe longer. I am not that good when it comes to UNIX history :-) I would not believe that IBM would break more or less all programs by chaning the select() API in an incompatible way. 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]
