Re: solving those data type problems
At 01:01 23.04.99 +0200, you wrote: >>Any comments / additions ? > >The question is what to do about name conflicts with applications. >For example an application might also definite "bool". Drop it ? Since it is only defined on sun/sparc it seems to be a bad idea to define it at all... By Goetz -- Goetz Babin-Ebell mailto:[EMAIL PROTECTED] TC Trust Center for Security http://www.trustcenter.de in Data Networks GmbH Tel.: +49-40-766 29 3301 Am Werder 1 / 21073 Hamburg / Germany Fax.: +49-40-766 29 577 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
BN_ULLONG undefined: why?
When compiling OpenSSL (current) and defining SIXTY_FOUR_BIT, the preprocessor define BN_ULLONG is undefined (see comment in file include/bn.h line 119). That results in an error when compiling crypto/bn/bn_div.c: bn_div.c 215: [error]: CFE1020 Identifier "BN_ULLONG" not defined etc. Why is BN_ULLONG undefined in the first place? OTOH, un-commenting it doesn't help either: I get all kinds of warnings that the number of bits in a shift operation is too big, and finally bn_asm bails out with: bn_asm.c 741: [error]: CFE1020 Identifier "BN_MASK" not defined Martin __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: make links
Ulf Möller wrote: > > People get confused by the make links output. So I think Configure > should print out something reassuring after make links is done. > > I also wonder if it wouldn't be enough to create the links only if > the include directory is empty. > > I would also prefer to have a "links" dependency in the Makefile > rather than running it from Configure. Does that break it for VC++? You can't do that: it means the other dependencies aren't valid when the Makefile is parsed. Unless I'm misunderstanding what you mean. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Intel: blowfish performance
Hi! I do realize that I'm concentrating on wrong matters (after all, blowfish is never used by SSL applications), but I couldn't abstain from commenting:-) First of I fail to understand why #define BF_PTR2 would perform better than the last "generic" version. The one that performs best on Alpha: ( S[(int)(R>>24L) ] + \ S[0x0100+((int)(R>>16L)&0xff)])^ \ S[0x0200+((int)(R>> 8L)&0xff)])+ \ S[0x0300+((int)(R )&0xff)]) Intel does have instructions that "multiply" array index by 4 at no cost... So that latter *should* generate better code. And.. it does:-) #undef BF_PTR* performs at least 25% faster on Intel! Yeah, I know there is assembler implementation provided. As I said I just couldn't abstain... Andy. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: make links
Ben Laurie wrote: > > Ulf Möller wrote: > > > > People get confused by the make links output. So I think Configure > > should print out something reassuring after make links is done. > > > > I also wonder if it wouldn't be enough to create the links only if > > the include directory is empty. > > > > I would also prefer to have a "links" dependency in the Makefile > > rather than running it from Configure. Does that break it for VC++? > > You can't do that: it means the other dependencies aren't valid when the > Makefile is parsed. Unless I'm misunderstanding what you mean. BTW, speaking of links, the current CVS tree is completely screwed: gcc -DMONOLITH -I../include -DBN_DEBUG -DREF_CHECK -DCRYPTO_MDEBUG -O2 -pedantic -Wall -Wshadow -Werror -pipe -c verify.c In file included from ../include/asn1.h:67, from ../include/x509.h:68, from verify.c:65: ../include/bn.h:62: opensslconf.h: No such file or directory opensslconf.h exists in crypto/ but not includes. I presume it should be linked there? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: #include or #include ?
On Fri, Apr 23, 1999 at 02:21:12AM +0200, Bodo Moeller wrote:
> [...] Now whether /usr/local/include/openssl is a link or a
> directory with copies of all the files doesn't really make a
> difference, what counts is that the name-space makes sense.
Since there seems to be mostly agreement to the change to
(including a "Yes, please!!!" sent via private mail -:),
I'll commit the appropriate changes tonight unless somone vetoes very
quickly. In addition to the actual #includes, many Makefile.ssl's
need a tiny change, Makefile.org needs a couple of tiny changes; so
does mk1mf.pl (I verified building the changed library with
makefile.one), and mklink.sh needs a patch to handle link directories
of the form {../}*directory1/directory2 -- the original script could
handle only {../}*directory.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: make links
> You can't do that: it means the other dependencies aren't valid when the > Makefile is parsed. Unless I'm misunderstanding what you mean. Uh, right. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: #include or #include ?
> I'll commit the appropriate changes tonight unless somone vetoes very > quickly. In addition to the actual #includes, many Makefile.ssl's > need a tiny change, Makefile.org needs a couple of tiny changes; so > does mk1mf.pl (I verified building the changed library with Und OPENSSL_VERSION_NUMBER hochzählen, bitte. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: GUESSOS
> echo "`sysctl -n hw.model | sed >'s,.*\(.\)86-class.*,i\186,'`-whatever-netbsd"; exit 0 Thanks! The FreeBSD:*:*:*486* and NetBSD:*:*:*486* entries are bogus, right? sysctl -n hw.model exists on FreeBSD as well, but it prints the string "Pentium" there. Makes me wonder how it calls i486 and Pentium II. The man page is not particularly helpful. (I'll make it a check for Pentium* for now. If someone knows the right way, let me know.) Does anyone know about BSDI and OpenBSD? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: GUESSOS
Ulf Möller wrote: > sysctl -n hw.model exists on FreeBSD as well, but it prints the string > "Pentium" there. Makes me wonder how it calls i486 and Pentium II. The > man page is not particularly helpful. (I'll make it a check for Pentium* > for now. If someone knows the right way, let me know.) ben@heap:~/work/openssl$ sysctl -n hw.model Pentium II (quarter-micron) Seems FreeBSD has an electron microscope... Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: #include or #include ?
Oops. I didn't mean to send that to the list (and it is wrong, too--in order to check the version header you'd have to find it first.) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: #include or #include ?
-BEGIN PGP SIGNED MESSAGE-
At 16:29 23.04.99 +0200, you wrote:
>Since there seems to be mostly agreement to the change to
> (including a "Yes, please!!!" sent via private mail -
:),
>I'll commit the appropriate changes tonight unless somone vetoes
very
>quickly. In addition to the actual #includes, many Makefile.ssl's
>need a tiny change, Makefile.org needs a couple of tiny changes; so
>does mk1mf.pl
BTW:
I messed a little with the makefile generation for M$
allowing to select between multi and single threading.
(and added code for BounceChecker...)
Perhaps I'll find why dll don't work...
Index: mk1mf.pl
===
RCS file: /usr/pcshare/tc//cvsroot/openssl/util/mk1mf.pl,v
retrieving revision 1.1.2.1
diff -c -r1.1.2.1 mk1mf.pl
*** mk1mf.pl1999/04/07 15:09:32 1.1.2.1
- --- mk1mf.pl 1999/04/23 13:39:19
***
*** 28,33
- --- 28,35
);
$platform="";
+ $multithread=0;
+
foreach (@ARGV)
{
if(/^no-rc2$/) { $no_rc2=1; }
***
*** 60,65
- --- 62,69
elsif (/^rsaref$/) { $rsaref=1; }
elsif (/^gcc$/) { $gcc=1; }
elsif (/^debug$/) { $debug=1; }
+ elsif (/^debugbc$/) { $debug=1; $bcheck=1; }
+ elsif (/^multithread$/) { $multithread=1; }
elsif (/^shlib$/) { $shlib=1; }
elsif (/^dll$/) { $shlib=1; }
elsif (/^([^=]*)=(.*)$/){ $VARS{$1}=$2; }
***
*** 88,93
- --- 92,99
no-err - No error strings
dll/shlib - Build shared libraries (MS)
debug - Debug build
+ debugbc - Debug build with BoundsChecker(TM)
+(MS)
+ multithread - Multithreaded (MS)
gcc - Use Gcc (unix)
rsaref - Build to require RSAref
***
*** 128,178
- --- 134,194
# $bin_dir.=$o causes a core dump on my sparc :-(
$NT=0;
+ $microsoft=0;
+ $outaddms="";
push(@INC,"util/pl","pl");
if ($platform eq "VC-MSDOS")
{
$asmbits=16;
$msdos=1;
+ $microsoft=1;
require 'VC-16.pl';
}
elsif ($platform eq "VC-W31-16")
{
$asmbits=16;
$msdos=1; $win16=1;
+ $microsoft=1;
require 'VC-16.pl';
}
elsif (($platform eq "VC-W31-32") || ($platform eq "VC-WIN16"))
{
$asmbits=32;
$msdos=1; $win16=1;
+ $microsoft=1;
require 'VC-16.pl';
}
elsif (($platform eq "VC-WIN32") || ($platform eq "VC-NT"))
{
$NT = 1 if $platform eq "VC-NT";
+ $microsoft=1;
require 'VC-32.pl';
}
elsif ($platform eq "BC-NT")
{
$bc=1;
+ $microsoft=1;
require 'BC-32.pl';
}
elsif ($platform eq "BC-W31")
{
$bc=1;
$msdos=1; $w16=1;
+ $microsoft=1;
require 'BC-16.pl';
}
elsif ($platform eq "BC-Q16")
{
$msdos=1; $w16=1; $shlib=0; $qw=1;
+ $microsoft=1;
require 'BC-16.pl';
}
elsif ($platform eq "BC-MSDOS")
{
$asmbits=16;
$msdos=1;
+ $microsoft=1;
require 'BC-16.pl';
}
elsif ($platform eq "FreeBSD")
***
*** 200,209
$cflags.=' -DTERMIO';
}
!
$out_dir=(defined($VARS{'OUT'}))?$VARS{'OUT'}:$out_def.($debug?".dbg":
"");
!
$tmp_dir=(defined($VARS{'TMP'}))?$VARS{'TMP'}:$tmp_def.($debug?".dbg":
"");
$inc_dir=(defined($VARS{'INC'}))?$VARS{'INC'}:$inc_def;
- -
$bin_dir=$bin_dir.$o unless ((substr($bin_dir,-1,1) eq $o) ||
($bin_dir eq ''));
$cflags.=" -DNO_IDEA" if $no_idea;
- --- 216,241
$cflags.=' -DTERMIO';
}
! # BoundsChecker for MS
! if ($bcheck > 0)
! {
! $cc = 'nmcl.exe';
! $link= 'nmlink.exe';
! $ex_libs.= ' BCINTERF.LIB';
! }
!
! if ($microsoft > 0)
! {
!
$out_dir=(defined($VARS{'OUT'}))?$VARS{'OUT'}:$out_def.($debug?"dbg":"
").($bcheck?"bc":"").($multithread?"MT":"");
!
$tmp_dir=(defined($VARS{'TMP'}))?$VARS{'TMP'}:$tmp_def.($debug?"dbg":"
").($bcheck?"bc":"").($multithread?"MT":"");
! $cflags.=$outaddms.$out_dir."/OpenSSL" if !$outaddms eq "";
! }
! else
! {
!
$out_dir=(defined($VARS{'OUT'}))?$VARS{'OUT'}:$out_def.($debug?".dbg":
"");
!
$tmp_dir=(defined($VARS{'TMP'}))?$VARS{'TMP'}:$tmp_def.($debug?".dbg":
"");
! }
$inc_dir=(defined($VARS{'INC'}))?$VARS{'INC'}:$inc_def;
$bin_dir=$bin_dir.$o unless ((substr($bin_dir,-1,1) eq $o) ||
($bin_dir eq ''));
$cflags.=" -DNO_IDEA" if $no_idea;
Index: pl/VC-32.pl
===
RCS file: /usr/pcshare/tc//cvsroot/openssl/util/pl/VC-32.pl,v
retrieving revision 1.1
Re: GUESSOS
> My recommendation is to build for the generic case, and document the
> optimizations available for each platform, and why someone would want
> to (or not want to) use them. Slow and working is always preferable to
> a fast crash.
Let me explain why we need the CPU version:
OpenSSL contains optimized assembler implementations for a number of
cryptographic algorithms. They are only used when you configure the
library for Intel processors, not in the generic case ("Configure cc").
The SHA-1 implementation uses the bswap instruction, which is not
available on the i386. (I consider it a bug if an operating system
doesn't catch the exception and emulate bswap, but apparently OS
authors don't buy into the "slow and working" philosophy.) SHA-1 is
considerably slower with the swap done stepwise, so we do that only
when OpenSSL is built on a 386 or the user explicitly requests it.
The INSTALL file contains the following explanation in a prominent
position:
| There are several options to ./config to customize the build:
|
| rsarefBuild with RSADSI's RSAREF toolkit.
| no-asmBuild with no assembler code.
| 386 Use the 80386 instruction set only (the default x86 code is
|more efficient, but requires at least a 486).
Given the current market share of i386 processors, I believe that is a
reasonable solution.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: R: OCSP patching
"Titchener, Tom" wrote: > > >Who wants to write a simple S/MIME tool, able to >decrypt, verify, sign, > >crypt any mail, so I can use it as a PINE filter? ;-) > > You can use the pkcs#7 patch I sent last week to do > the sign/verify bit. Then you just need to fix it up > to encrpyt/decrypt and you'll be all set... :) > I received a bad tar archive... I don't know if that problem was only mine or it was received badly by all the community, in case, can you re-send it to the list (or at least to me ?). Thanks, Massimiliano Pala ([EMAIL PROTECTED]) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
cryptall.h
While scanning the libary for remaining include filenames without the openssl/ prefix, I noticed that crypto/cryptall.h doesn't make any sense at all. Ever since 0.6.6b (possibly earlier) this header file included a file "meth.h", which I could not find anywhere in neither that nor the current library. And it contains stuff like this: #ifdef NO_MD2 #include #else #include "md2.h" #endif and similar for NO_MD5 and NO_DES. I have no idea what that could have meant, but the cryptall.h file isn't needed for anything anyway. I presume we should just delete it, right? Or is there some strange autogeneration procedure involved? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: R: OCSP patching
[EMAIL PROTECTED] wrote: > > > I received a bad tar archive... I don't know if that problem was only mine or > it was received badly by all the community, in case, can you re-send it to > the list (or at least to me ?). > Maybe just you. It wasn't a tar archive anyway even though it had a .tar extension. It was a gzip'ed tar archive: maybe thats the problem? Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
