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 #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 #989] DJGPP patches for 0.9.8 and 0.9.7
On Mon, 3 Jan 2005, Doug Kaufman wrote: On Mon, 3 Jan 2005, Andy Polyakov wrote: I haven't audited the proposed patch yet, but I'd like you to explicitly state what happens if the noise driver is not installed at end-user system and provide a pointer to the driver (I know you've provided one back then, but please send it once again). This would be of value to mention in INSTALL.DJGPP. In fact just write a paragraph *as* if it was meant for INSTALL.DJGPP. A. I'll try to write this in the next few days. The noise program was recently released under a more liberal license (originally it was under the GPL). I need to verify some changes in the package with the author, then I'll plan to make it available from my website. Actually the INSTALL.DJGPP needs revision. It is now about 2 years since I wrote it, and I see that the URL cited for obtaining DJGPP is no longer valid. Here is a revised version of INSTALL.DJGPP, which should be applicable to the 0.9.8 and the 0.9.7 branches. Let me know if you think it needs any additional revision. The file should be an attachment to this message. Doug -- Doug Kaufman Internet: [EMAIL PROTECTED] INSTALLATION ON THE DOS PLATFORM WITH DJGPP --- Openssl has been ported to DOS, but only with long filename support. If you wish to compile on native DOS with 8+3 filenames, you will have to tweak the installation yourself, including renaming files with illegal or duplicate names. You should have a full DJGPP environment installed, including the latest versions of DJGPP, GCC, BINUTILS, BASH, etc. This package requires that PERL and BC also be installed. All of these can be obtained from the usual DJGPP mirror sites, such as ftp://ftp.delorie.com/pub/djgpp; or http://www.delorie.com/pub/djgpp;. For help on which files to download, see the DJGPP ZIP PICKER page at http://www.delorie.com/djgpp/zip-picker.html;. You also need to have the WATT-32 networking package installed before you try to compile openssl. This can be obtained from http://www.bgnett.no/~giva/;. The Makefile assumes that the WATT-32 code is in the directory specified by the environment variable WATT_ROOT. If you have watt-32 in directory watt32 under your main DJGPP directory, specify WATT_ROOT=/dev/env/DJDIR/watt32. To compile openssl, start your BASH shell. Then configure for DOS by running ./Configure with appropriate arguments. The basic syntax for DOS is: ./Configure no-threads --prefix=/dev/env/DJDIR DJGPP You may run out of DPMI selectors when running in a DOS box under Windows. If so, just close the BASH shell, go back to Windows, and restart BASH. Then run make again. OpenSSL requires a source of random data in order to perform secure cryptography. Random data may be limited in the usual DOS setup, causing OpenSSL to sometimes fail with an error message that the PRNG (pseudo-random number generator) has not been seeded. You can avoid this problem by installing a device which collects random data and makes it available to OpenSSL. One such device is noise, which creates character devices RANDOM$ and URANDOM$ (also known as /dev/random$ and /dev/urandom$) from which data can be read. Noise is generally installed from the config.sys file. You can get noise from http://www.rahul.net/dkaufman/index.html;
Re: [openssl.org #989] DJGPP patches for 0.9.8 and 0.9.7
On Tue, 4 Jan 2005, Andy Polyakov wrote: Configure, openssl_fips_fingerprint, dbg_init and O_BINARY patches are in now [both 0.9.7 and HEAD]. Compiler warnings will be addressed later. As for -fno-strict-aliasing. I'd say it should rather be resolved in source code, but [again] at some later point... A. Using the new code in the 20050105 snapshots, I compiled under DJGPP, using the 386 option and excluding idea, rc5, and mdc2. The 0.9.8 code and the 0.9.7 code (fips and non-fips) compile OK, with the fips code stopping in make test at test_sha if noise isn't installed to create /dev/urandom$. With noise installed, all three builds go through make test OK, but the 0.9.8 version only installs one man page in make install (man1/CA.pl.1), since the set -e prevents installation of any additional pages. Here are the warnings about lack of strict aliasing under the DJGPP port of gcc. The warnings are the same for the 0.9.7 and 0.9.8 code (except for pem_lib.c at line 483 in 0.9.8). I don't know how to fix these in the source code myself, so I'll leave that to someone else for a future patch. a_type.c: In function `ASN1_TYPE_set': a_type.c:74: warning: dereferencing type-punned pointer will break strict-aliasing rules x_name.c: In function `x509_name_ex_d2i': x_name.c:171: warning: dereferencing type-punned pointer will break strict-aliasing rules x_name.c:177: warning: dereferencing type-punned pointer will break strict-aliasing rules x_name.c: In function `x509_name_encode': x_name.c:239: warning: dereferencing type-punned pointer will break strict-aliasing rules x_name.c:242: warning: dereferencing type-punned pointer will break strict-aliasing rules pem_lib.c: In function `PEM_get_EVP_CIPHER_INFO': pem_lib.c:481: warning: dereferencing type-punned pointer will break strict-aliasing rules Thanks for working on my proposed patches so quickly. 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 #989] DJGPP patches for 0.9.8 and 0.9.7
-DDEVRANDOM=\/dev/urandom\\x24\ instead? As for PATH=$TOP/apps\;$TOP\;$PATH in openssl_fips_fingerprint. Configure, openssl_fips_fingerprint, dbg_init and O_BINARY patches are in now [both 0.9.7 and HEAD]. Compiler warnings will be addressed later. As for -fno-strict-aliasing. I'd say it should rather be resolved in source code, but [again] at some later point... A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #989] DJGPP patches for 0.9.8 and 0.9.7
I have tested current source code for the 0.9.8 version and the 0.9.7 version (fips and non-fips) with DJGPP. The attached patches allow building under DJGPP. In addition to a few substantive fixes, I put in a number of minor fixes to get rid of gcc warnings when compiled with -W, such as putting static at the beginning of a declaration and putting in missing initializers. Some of the changes (e.g., getting rid of the erroneous set -e) were previously reported (rt #932). The code for watt-32 debugging didn't appear to be implemented correctly. This should only be called when desired; otherwise large files will be created, documenting every byte going through tcp. In addition dbug_init() should be called only once, but was being called multiple times. I moved dbug_init out of s_socket.c. It needs to be hooked to a command-line option for any application that needs tcp debugging. I put in code for s_client, since that is the place where watt-32 debugging was most likely to be needed, but didn't put in code for other applications (such as s_server). When I last submitted patches in August, I was trying to get adequate entropy for DOS. I think the answer is probably to use a separate program to create /dev/random and /dev/urandom equivalents, then use the mechanism in rand_unix.c. The DOS program noise collects entropy by sampling keystroke timings, exec() and exit() timings, and flush() timings. Because of peculiarities of the DOS filesystem, the authors of noise create /dev/random$ and /dev/urandom$ rather than /dev/random and /dev/urandom, avoiding problems reading files with similar names. I added a default define for DEVRANDOM to the DJGPP CFLAGs to enable use of the noise program, and had /dev/urandom$ read in binary mode in rand_unix.c. All 3 versions I tested were built without IDEA, RC5, and MDC2. I haven't tried building this time with the 386 option. They all go through make, make depend, make test, and make install without error. The binaries identify themselves as: OpenSSL 0.9.8-dev XX xxx built on: Sun Jan 2 20:36:37 PST 2005 platform: DJGPP options: bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) blowfish(idx) compiler: gcc -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 -I/dev/env/WATT_ROOT/inc -DTERMIOS -DL_ENDIAN -fno-strict-aliasing -fomit-frame-pointer -O2 -W -Wall -DDEVRANDOM=/dev/urandom$$ -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM OPENSSLDIR: /dev/env/DJDIR/ssl OpenSSL 0.9.7f-dev XX xxx built on: Sun Jan 2 19:26:44 PST 2005 platform: DJGPP options: bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) blowfish(idx) compiler: gcc -DOPENSSL_SYSNAME_MSDOS -DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 -I/dev/env/WATT_ROOT/inc -DTERMIOS -DL_ENDIAN -fno-strict-aliasing -fomit-frame-pointer -O2 -W -Wall -DDEVRANDOM=/dev/urandom$$ OPENSSLDIR: /dev/env/DJDIR/ssl OpenSSL 0.9.7f-fips-dev XX xxx built on: Sun Jan 2 18:34:35 PST 2005 platform: DJGPP options: bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) blowfish(idx) compiler: gcc -DOPENSSL_SYSNAME_MSDOS -DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 -I/dev/env/WATT_ROOT/inc -DTERMIOS -DL_ENDIAN -fno-strict-aliasing -fomit-frame-pointer -O2 -W -Wall -DDEVRANDOM=/dev/urandom$$ OPENSSLDIR: /dev/env/DJDIR/ssl Since I am in the US, copies of the patches are being submitted to the Bureau of Industry and Security. 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 #989] DJGPP patches for 0.9.8 and 0.9.7
Just couple of common words first. I realize that sometimes we can't match the level of enthusiasm of our contributors [which might be experienced as frustrating], but I want to emphasize that it does *not* mean that the feedback is not appreciated. Please, keep up the good work and bear with us. It *is* appreciated. Next thing to understand. Changes to 0.9.7 are *currently* prioritized, because we're trying to schedule 0.9.7f release. For this reason we [or at least I] a bit reluctant to apply cosmetic changes to 0.9.7. Or in other words changes that solve *real* problems in 0.9.7 are prioritized for *this* particular moment. So don't get upset if you find that not everything went in, or you have to argue and show that the problem is *real*, or 0.9.8 changes were left without immediate attention. When I last submitted patches in August, I was trying to get adequate entropy for DOS. I think the answer is probably to use a separate program to create /dev/random and /dev/urandom equivalents, then use the mechanism in rand_unix.c. The DOS program noise collects entropy by sampling keystroke timings, exec() and exit() timings, and flush() timings. Because of peculiarities of the DOS filesystem, the authors of noise create /dev/random$ and /dev/urandom$ rather than /dev/random and /dev/urandom, avoiding problems reading files with similar names. I added a default define for DEVRANDOM to the DJGPP CFLAGs to enable use of the noise program, and had /dev/urandom$ read in binary mode in rand_unix.c. I haven't audited the proposed patch yet, but I'd like you to explicitly state what happens if the noise driver is not installed at end-user system and provide a pointer to the driver (I know you've provided one back then, but please send it once again). This would be of value to mention in INSTALL.DJGPP. In fact just write a paragraph *as* if it was meant for INSTALL.DJGPP. A. __ 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
I added a default define for DEVRANDOM to the DJGPP CFLAGs to enable use of the noise program, and had /dev/urandom$ read in binary mode in rand_unix.c. Eight \$ is not only ugly, but presumably has everything to do with current amount of recursive invocations of make... Can we settle for -DDEVRANDOM=\/dev/urandom\\x24\ instead? As for PATH=$TOP/apps\;$TOP\;$PATH in openssl_fips_fingerprint. The reason why PATH is quoted in original version is to allow spaces in $PATH. Is there possibility for DJ run-time environment to suffer from this as well? In which case PATH=$TOP/apps;$TOP;$PATH might be more appropraite... Care to comment on this? A. __ 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 Mon, 3 Jan 2005, Andy Polyakov wrote: Just couple of common words first. I realize that sometimes we can't match the level of enthusiasm of our contributors [which might be experienced as frustrating], but I want to emphasize that it does *not* mean that the feedback is not appreciated. Please, keep up the good work and bear with us. It *is* appreciated. Thanks. I don't expect many folks to get excited over porting a program to DOS. Next thing to understand. Changes to 0.9.7 are *currently* prioritized, because we're trying to schedule 0.9.7f release. For this reason we [or at least I] a bit reluctant to apply cosmetic changes to 0.9.7. Or in other words changes that solve *real* problems in 0.9.7 are prioritized for *this* particular moment. So don't get upset if you find that not everything went in, or you have to argue and show that the problem is *real*, or 0.9.8 changes were left without immediate attention. I wasn't expecting everything to go in. The set -e lines do prevent the man pages from being installed in 0.9.8. The watt-32 debug problem should probably be fixed in both, since it causes unexpected and (probably) inappropriate action by the executable. I don't expect changes to go into the distribution without appropriate consideration. I think it was well over a year and after many revisions before my first attempts to get OpenSSL to work in DOS got into the code at all. There isn't any hurry. I am not sure that anyone is actually compiling OpenSSL for DOS besides me and Gisle Vanem. The proposed patches are in the mailing list archive and the rt archive if anyone needs to see them. I haven't audited the proposed patch yet, but I'd like you to explicitly state what happens if the noise driver is not installed at end-user system and provide a pointer to the driver (I know you've provided one back then, but please send it once again). This would be of value to mention in INSTALL.DJGPP. In fact just write a paragraph *as* if it was meant for INSTALL.DJGPP. A. I'll try to write this in the next few days. The noise program was recently released under a more liberal license (originally it was under the GPL). I need to verify some changes in the package with the author, then I'll plan to make it available from my website. Actually the INSTALL.DJGPP needs revision. It is now about 2 years since I wrote it, and I see that the URL cited for obtaining DJGPP is no longer valid. When noise isn't installed, the 0.9.8 and 0.9.7 (non-fips) pass make test without any problems, but the 0.9.7 (fips) test suite fails in fips_aesavs, fips_desmovs, fips_dsatest, and in fips_sha1test, all with error of PRNG not seeded:md_rand.c:512. I presume that without noise being installed, applications built with the library may occasionally fail with this error, and at other times be less secure than might be assumed by the user. I tested openssl s_client and it seemed to work OK without noise. Can you think of any specific tests that I should make? 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 #989] DJGPP patches for 0.9.8 and 0.9.7
On Mon, 3 Jan 2005, Andy Polyakov wrote: Eight \$ is not only ugly, but presumably has everything to do with current amount of recursive invocations of make... Can we settle for -DDEVRANDOM=\/dev/urandom\\x24\ instead? As for PATH=$TOP/apps\;$TOP\;$PATH in openssl_fips_fingerprint. The reason why PATH is quoted in original version is to allow spaces in $PATH. Is there possibility for DJ run-time environment to suffer from this as well? In which case PATH=$TOP/apps;$TOP;$PATH might be more appropraite... Care to comment on this? A. I tested both of your changes, and they seem to work fine. I never thought of using the \\x24 instead of $. Thanks; that works nicely. Taking out the quotes for PATH was an oversight on my part. Your PATH statement works just fine and should be robust to spaces in $PATH. Doug -- Doug Kaufman Internet: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
