Patches
Here are some patches for some files. Some files are unused (not in makefiles,
but in snapshot). All diffs are on diff -tBHu3 format against 19-Aug snapshot.
+++ ./crypto/des/cbc3_enc.c Tue Jul 31 10:13:42 2001
--- ./crypto/des/cbc3_enc.oldFri Aug 13 18:00:24 1999
@@ -70,13 +70,13 @@
if (enc == DES_ENCRYPT)
{
des_cbc_encrypt((unsigned char*)input,
+(unsigned char*)output,length,ks1,iv1,enc);
-(unsigned char*)output,length,ks1,iv1,enc);
if (length = sizeof(des_cblock))
memcpy(niv1,output[off],sizeof(des_cblock));
des_cbc_encrypt((unsigned char*)output,
+(unsigned char*)output,l8,ks2,iv1,!enc);
-(unsigned char*)output,l8,ks2,iv1,!enc);
des_cbc_encrypt((unsigned char*)output,
+(unsigned char*)output,l8,ks1,iv2,enc);
-(unsigned char*)output,l8,ks1,iv2,enc);
if (length = sizeof(des_cblock))
memcpy(niv2,output[off],sizeof(des_cblock));
}
@@ -85,13 +85,13 @@
if (length = sizeof(des_cblock))
memcpy(niv2,input[off],sizeof(des_cblock));
des_cbc_encrypt((unsigned char*)input,
+(unsigned char*)output,l8,ks1,iv2,enc);
-(unsigned char*)output,l8,ks1,iv2,enc);
des_cbc_encrypt((unsigned char*)output,
+(unsigned char*)output,l8,ks2,iv1,!enc);
-(unsigned char*)output,l8,ks2,iv1,!enc);
if (length = sizeof(des_cblock))
memcpy(niv1,output[off],sizeof(des_cblock));
des_cbc_encrypt((unsigned char*)output,
+(unsigned char*)output,length,ks1,iv1,enc);
-(unsigned char*)output,length,ks1,iv1,enc);
}
memcpy(*iv1,niv1,sizeof(des_cblock));
memcpy(*iv2,niv2,sizeof(des_cblock));
+++ ./crypto/des/des.c Tue Jul 31 10:50:54 2001
--- ./crypto/des/des.old Mon May 14 11:00:20 2001
@@ -423,7 +423,7 @@
else
k2[i-8]=k;
}
+des_set_key_unchecked(k2,ks2);
-des_set_key_unchecked(k2,ks2);
memset(k2,0,sizeof(k2));
}
else if (longk || flag3)
@@ -431,7 +431,7 @@
if (flag3)
{
des_string_to_2keys(key,kk,k2);
+des_set_key_unchecked(k2,ks2);
-des_set_key_unchecked(k2,ks2);
memset(k2,0,sizeof(k2));
}
else
@@ -453,7 +453,7 @@
kk[i]=key[i]|0x80;
}
+des_set_key_unchecked(kk,ks);
-des_set_key_unchecked(kk,ks);
memset(key,0,sizeof(key));
memset(kk,0,sizeof(kk));
/* woops - A bug that does not showup under unix :-( */
@@ -493,7 +493,7 @@
if (cflag)
{
des_cbc_cksum(buf,cksum,
+(long)len,ks,cksum);
-(long)len,ks,cksum);
if (!eflag)
{
if (feof(DES_IN)) break;
@@ -506,13 +506,13 @@
des_ecb_encrypt(
(des_cblock *)(buf[i]),
(des_cblock *)(obuf[i]),
+ks,do_encrypt);
-ks,do_encrypt);
else if (flag3 bflag)
for (i=0; il; i+=8)
des_ecb2_encrypt(
(des_cblock *)(buf[i]),
(des_cblock *)(obuf[i]),
+ks,ks2,do_encrypt);
-ks,ks2,do_encrypt);
else if (flag3 !bflag)
{
char tmpbuf[8];
@@ -530,7 +530,7 @@
{
des_cbc_encrypt(
buf,obuf,
+(long)l,ks,iv,do_encrypt);
-(long)l,ks,iv,do_encrypt);
if (l = 8)
toner cartridges
VORTEX SUPPLIES YOUR LASER PRINTER TONER CARTRIDGE, COPIER AND FAX CARTRIDGE CONNECTION SAVE UP TO 30% FROM RETAIL ORDER BY PHONE:1-888-288-9043 ORDER BY FAX: 1-888-977-1577 E-MAIL REMOVAL LINE: 1-888-248-4930 UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED) ALL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL. PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS). IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. NUMBER NOTE: WE DO NOT CARRY 1) XEROX, BROTHER, PANASONIC, FUJITSU PRODUCTS 2) HP DESKJETJET/INK JET OR BUBBLE JET CARTRIDGES 3) CANON BUBBLE JET CARTRIDGES 4) ANY OFFBRANDS BESIDES THE ONES LISTED BELOW. OUR NEW , LASER PRINTER TONER CARTRIDGE, PRICES ARE AS FOLLOWS: (PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER) HEWLETT PACKARD: (ON PAGE 2) ITEM #1 LASERJET SERIES 4L,4P (74A)$44 ITEM #2 LASERJET SERIES 1100 (92A)-$44 ITEM #3 LASERJET SERIES 2 (95A)$39 ITEM #4 LASERJET SERIES 2P (75A)---$54 ITEM #5 LASERJET SERIES 5P,6P,5MP, 6MP (3903A)-- -$44 ITEM #6 LASERJET SERIES 5SI, 8000 (09A)$95 ITEM #7 LASERJET SERIES 2100 (96A)-$74 ITEM #8 LASERJET SERIES 8100 (82X)$145 ITEM #9 LASERJET SERIES 5L/6L (3906A)--$35 ITEM #10 LASERJET SERIES 4V-$95 ITEM #11 LASERJET SERIES 4000 (27X)--$72 ITEM #12 LASERJET SERIES 3SI/4SI (91A)---$54 ITEM #13 LASERJET SERIES 4, 4M, 5,5M-$49 ITEM #13A LASERJET SERIES 5000 (29X)-$125 ITEM #14 LASERJET SERIES 1200$59 HEWLETT PACKARD FAX (ON PAGE 2) ITEM #14 LASERFAX 500, 700 (FX1)--$49 ITEM #15 LASERFAX 5000,7000 (FX2)$54 ITEM #16 LASERFAX (FX3)--$59 ITEM #17 LASERFAX (FX4)--$54 LEXMARK/IBM (ON PAGE 3) OPTRA 4019, 4029 HIGH YIELD---$89 OPTRA R, 4039, 4049 HIGH YIELD---$105 OPTRA E310.312 HIGH YIELD$79 OPTRA E---$59 OPTRA N--$115 OPTRA S--$165 OPTRA T--$195 EPSON (ON PAGE 4) ACTION LASER 7000,7500,8000,9000--$105 ACTION LASER 1000,1500$105 CANON PRINTERS (ON PAGE 5) PLEASE CALL FOR MODELS AND UPDATED PRICES FOR CANON PRINTER CARTRIDGES PANASONIC (0N PAGE 7) NEC SERIES 2 MODELS 90 AND 95--$105 APPLE (0N PAGE 8) LASER WRITER PRO 600 or 16/600--$49 LASER WRITER SELECT 300,320,360-$74 LASER WRITER 300 AND 320$54 LASER WRITER NT, 2NT$54 LASER WRITER 12/640-$79 CANON FAX (ON PAGE 9) LASERCLASS 4000 (FX3)---$59 LASERCLASS 5000,6000,7000 (FX2)-$54 LASERFAX 5000,7000 (FX2)$54 LASERFAX 8500,9000 (FX4)$54 CANON COPIERS (PAGE 10) PC 3, 6RE, 7 AND 11 (A30)-$69 PC 300,320,700,720,760,900,910,920(E-40)--$89 90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS. ALL TRADEMARKS AND BRAND NAMES LISTED ABOVE ARE PROPERTY OF THE RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ENGINE and DSO under FreeBSD
At 12:18 PM 8/18/01 +0200, Richard wrote: From: Tom Biggs [EMAIL PROTECTED] tbiggs It blew up with a NULL pointer fault. I was surprised to discover tbiggs the reason - apparently, Configure assumes that FreeBSD and tbiggs FreeBSD-elf don't have any support for dynamic shared libraries! tbiggs The FreeBSD entries in Configure's $table don't appear to have tbiggs any mention of DSO support. I couldn't see any reason why FreeBSD tbiggs apps couldn't use DLFCN-style DSO, so I did a few temporary tbiggs hacks to build in DLFCN support, such as -DDSO_DLFCN in CFLAGS. tbiggs And it worked. Good to know. The reason for this is that noone has tested it on FreeBSD, so we were cautious. A few questions that come to mind is how far back in FreeBSD history did it have dlfcn support? And it there was a point where support was officially started, is there a clean way to detect it, so config or Configure do the right thing even on older FreeBSD installations? I researched this. DLFCN support is in FreeBSD back to version 2. The current release version of FreeBSD is version 4.3. I don't know how many people out there are still using version 1.x - it doesn't seem very likely. The only configuration issue I can see is that FreeBSD switched over to ELF format for 3.x, earlier versions used the a.out format for executables - by default. ELF support was in version 2 (i.e., ELF executables could be built and run) but the default was to compile to a.out format. This impacts the DSO stuff because in a.out dynamic libraries, C language symbol strings passed into dlsym() (used by DSO_bind_func()) must have a leading underscore. The ELF format dynamic libraries do not require that. I'm not sure what happens now. Will someone who knows Configure take this information and add DLFCN support to the script? Or is it my responsibility? I'm afraid of mucking up the script. Tom Biggs __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SSL_COMP_* API
Hi! While writing the manual page for SSL_COMP_add_compression_methods(): SSL_COMP_add_compression_methods() is defined in ssl.h (and is therefore a public part of the API). The counterpart SSL_COMP_get_compression_methods() is however only part of ssl_locl.h (and is therefore private). Does anybody have an idea on why this distinction is being made? It doesn't make sense to me. (If nobody has an idea on why it should not be public, I will make it public.) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] openssl shared libraries under Fujitsu-Siemens Reliant UNIX
Richard, On Sat, 18 Aug 2001 12:35:36 +0200 (MET DST), Richard Levitte - VMS Whacker wrote: Hmm... In 0.9.7-dev, there's an AIX variant that does what you do, but in a slightly different way: [...] ld -r -o $$i.o $(ALLSYMSFLAG) lib$$i.a \ [...] Please note the 'ld -r'. That's apparently the way to build one giant .o file from a library or a number of smaller .o files. Here are my $0.02 on that: I don't understand (yet) why one should bother which each and every systems idea (better: each combination of OS and compiler) of how to get back the code from some libXXX.a and stuff in into libXXX.so and trying to do this in one complicated non-portable step. It seems far less complicated to me to just unpack all those .o files we have from libXXX.a ($AR x should always do the job) and then bind them together into a shared object with what the system offers. Using this pretty generic way you only need the information how to produce a shared object and that's it. Ok, perhaps I should admit I'm not the always-ported-every-code-to- every-system guy, so there is a big chance for me to miss something. :-) Regards, Robert -- [EMAIL PROTECTED] Siemens Business Services - FS CBS KORDOBA-Outsourcing Tel: +49-69-797-6530 Fax: +49-69-797-6599 -- Sent using PMMail (http://www.pmmail2000.com) - fast, decent, email software; far better than Outlook. Try it sometime. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
drop-in memory management
There is already support for drop-in cryptography, but doing drop-in memory management seems like a more highly applicable feature. After already having done this I realize that it is not a daunting task. It would've been even better had there been documentation pointing to which files to change. Does anyone else see this as a good future feature? Note to openssl-dev listees: I'm not on this list, so could you please CC [EMAIL PROTECTED] when you reply? -- Nathan Bell Companion Corporation Evelyn Manufacturing 801-943-7277 Etc... )); __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
0819 snapshot problem
openssl 0819 snapshot doesn't compile -- ssl/ssl_stat.c had several places that case statements didn't have a : on the clauses. See references to character string 'TLS1'. (It's a snapshot. Is this on-topic? Should I email a diff/patch when I find this sort of thing?) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
intel x86 make error
I'm fairly new to solaris8-intel, could be my inexperience with compiling binaries/scripts. ./config --prefix=/usr/local --openssldir=/usr/local/openssl run from /usr/local/openssl-0.9.6b appears to have no errors. No directories are created in /usr/local, yet no errors. When running make, the folowing error occurs. I had to copy make into /usr/bin to get it into the path. # make + rm -f libcrypto.so.0 + rm -f libcrypto.so + rm -f libcrypto.so.0.9.6 + rm -f libssl.so.0 + rm -f libssl.so + rm -f libssl.so.0.9.6 making all in crypto... ( echo #ifndef MK1MF_BUILD; \ echo /* auto-generated by crypto/Makefile.ssl for crypto/cversion.c */; \ echo #define CFLAGS \cc -KPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fast -O -Xa\; \ echo #define PLATFORM \solaris-x86-cc\; \ echo #define DATE \`date`\; \ echo #endif ) buildinf.h cc -I. -I../include -KPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fast -O -Xa -c cryptlib.c /usr/ucb/cc: language optional software package not installed *** Error code 1 make: Fatal error: Command failed for target `cryptlib.o' Current working directory /usr/local/openssl-0.9.6b/crypto *** Error code 1 make: Fatal error: Command failed for target `sub_all' # Below is a ls of the /usr/local/openssl-0.9.6b directory # ls appsdemos INSTALL.MacOS makevms.com rsaref bugsdoc INSTALL.VMS ms shlib certs e_os.h INSTALL.W32 NEWSssl CHANGES e_os2.h LICENSE openssl.doxytest CHANGES.SSLeay FAQ MacOS openssl.spectimes config include Makefileperltools Configure INSTALL Makefile.orgREADME util crypto install.com Makefile.sslREADME.ENGINE VMS # If this is a bug, great for open source, if not please direct me in detail. Stephen Davis 614-848-3995 X179 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: drop-in memory management
sorry for my poor english... memory management is widely provided by various platforms, but seem some embedded enviornment RTOS don't provide the ordernary memory library we usually used. recently, i try to porting openssl onto an NO_STDIO platform which doesn't provided malloc, realloc, ...etc. as i trace the code of openssl, i find that by the hard work of openssl develpment teams there are only few place that really calling these function. so we can easy redirect it to the library that os provided or self-implemented. i migrate gmalloc (GNU malloc) as the memory management for openssl, although i haven't fully test about it, but recently it works fine on /crypto/bn, bio, rand, dh. (still under testing) cause i am new in security, and embeded field, hope it useful to you. if there's a better solution, please let us know best rgds. Mars Lin Broadband Networks DELTA NETWORKS, INC. -Original Message- From: Nathan Bell [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 21, 2001 6:01 AM To: OpenSSL Users; [EMAIL PROTECTED] Subject: drop-in memory management There is already support for drop-in cryptography, but doing drop-in memory management seems like a more highly applicable feature. After already having done this I realize that it is not a daunting task. It would've been even better had there been documentation pointing to which files to change. Does anyone else see this as a good future feature? Note to openssl-dev listees: I'm not on this list, so could you please CC [EMAIL PROTECTED] when you reply? -- Nathan Bell Companion Corporation Evelyn Manufacturing 801-943-7277 Etc... )); __ 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: ENGINE and DSO under FreeBSD
From: Tom Biggs [EMAIL PROTECTED] tbiggs The only configuration issue I can see is that FreeBSD switched tbiggs over to ELF format for 3.x, earlier versions used the a.out tbiggs format for executables - by default. ELF support was in tbiggs version 2 (i.e., ELF executables could be built and run) tbiggs but the default was to compile to a.out format. tbiggs tbiggs This impacts the DSO stuff because in a.out dynamic libraries, tbiggs C language symbol strings passed into dlsym() (used by tbiggs DSO_bind_func()) must have a leading underscore. The ELF tbiggs format dynamic libraries do not require that. Hmm, I just took a longer lookat config, and it does choose the target FreeBSD-elf for FreeBSD 3 and higher, and if one looks up FreeBSD-elf in Configure, one can see that FreeBSD-elf indeed declares the availability of dlfcn. So, I think the best thing you can do is to find out why you didn't get that configuration target. I'd start with checking config. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ 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: [PATCH] openssl shared libraries under Fujitsu-Siemens ReliantUNIX
From: Robert Dahlem [EMAIL PROTECTED] Robert.Dahlem [...] Robert.Dahlem ld -r -o $$i.o $(ALLSYMSFLAG) lib$$i.a \ Robert.Dahlem [...] Robert.Dahlem Robert.Dahlem Please note the 'ld -r'. That's apparently the way to build one giant Robert.Dahlem .o file from a library or a number of smaller .o files. Robert.Dahlem Robert.Dahlem Here are my $0.02 on that: Robert.Dahlem Robert.Dahlem I don't understand (yet) why one should bother which Robert.Dahlem each and every systems idea (better: each combination Robert.Dahlem of OS and compiler) of how to get back the code from Robert.Dahlem some libXXX.a and stuff in into libXXX.so and trying to Robert.Dahlem do this in one complicated non-portable step. As a matter of fact,it looks like 'ld -r' *is* rather portable among the unixen I've looked at. Robert.Dahlem It seems far less complicated to me to just unpack all Robert.Dahlem those .o files we have from libXXX.a ($AR x should Robert.Dahlem always do the job) and then bind them together into a Robert.Dahlem shared object with what the system offers. Using this Robert.Dahlem pretty generic way you only need the information how to Robert.Dahlem produce a shared object and that's it. I guess it's my sense of esthetics (sp?) that has been in the way so far. I actually dislike the above method as well and much prefer the versions of ld that can produced a .so file with a .a file as input and that's it. Unfortuntely, that isn't supported everywhere,so for me, the above is the next best variant. Anyway, your comment is not really an answer to my question :-). -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ 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: drop-in memory management
From: Nathan Bell [EMAIL PROTECTED] nbell There is already support for drop-in cryptography, but doing drop-in nbell memory management seems like a more highly applicable feature. After nbell already having done this I realize that it is not a daunting task. It nbell would've been even better had there been documentation pointing to which nbell files to change. nbell Does anyone else see this as a good future feature? Actually, there is such a thing, but admitedly not documented. You can create your own allocator and deallocator functions and hook them in using the function CRYPTO_set_mem_functions(). See crypto.h -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ 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: intel x86 make error
From: Steve Davis [EMAIL PROTECTED] sdavis I'm fairly new to solaris8-intel, could be my inexperience with compiling binaries/scripts. Well,I think the error message you failed to read pretty much says it all: [...] sdavis cc -I. -I../include -KPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN sdavis -DHAVE_DLFCN_H -fast -O -Xa -c cryptlib.c sdavis /usr/ucb/cc: language optional software package not installed [...] -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ 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]
