[ftm@uk2.net: Updating OpenSSL on RedHat 7.3]
- Forwarded message from root [EMAIL PROTECTED] - Date: Sun, 09 Jun 2002 16:43:05 -0300 From: root [EMAIL PROTECTED] X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en To: [EMAIL PROTECTED] Subject: Updating OpenSSL on RedHat 7.3 X-Virus-Scanned: by AMaViS snapshot-20011031 Hello, I have RedHat 7.3 installed here and the version of the openSSL is 0.9.6a. I donwnloaded the newest version of openSSL (0.9.6d) but its a tar file, not a RPM file, do I have to uninstall my current version of openSSL in order to intall the newest version? Because if in the openSSL homesite had the RPM file, I would just usr the rpm -Uvh openSSL.rpm command, to upgrade but I don't know if the tar file will upgrade in the correct way Could you tell me if I need to unistall the openSSL already installed in order to intall the new one or I should just install the new one over the current one? Ome more thing... Will the openSSL.tar.gz file install its components in the same place that RedHat 7.3 installed by default? Thanks for your time... Best, FTM - End forwarded message - -- 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]
Re: make depend from Configure?
On Sun, Jun 09, 2002 at 09:23:05AM -0700, Tim Rice wrote: Currently 'make depend' uses makedepend which is part of X11. While it may be likely that development machines have X, there may be people building OpenSSL on machines with no X. Also I think makedepend doesn't produce the exact same output on all platforms __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: make depend from Configure?
In message [EMAIL PROTECTED] on Sun, 9 Jun 2002 20:35:31 -0400 (EDT), Rich Salz [EMAIL PROTECTED] said: rsalz If makedepend is not found, perhaps a pointer to sources to build one. rsalz rsalz Or, since perl is already required, include a quick perl script that does rsalz 70% of the job. Hmm, that could possibly be done... Do you have something ready? -- 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]
extdat.h
It seems that in the latest snapshots in crypto/x509v3/ext_dat.h, the table standard_exts ist not sorted correctly. crl_hold should be after sinfo. v3_crl_hold : #define NID_hold_instruction_code430 v3_sinfo : #define NID_sinfo_access 398 I haven't checked other values. As a consequence SubjectInfoAccess no longer works as a standard extension. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #91] extdat.h
It seems that in the latest snapshots in crypto/x509v3/ext_dat.h, the table standard_exts ist not sorted correctly. crl_hold should be after sinfo. v3_crl_hold : #define NID_hold_instruction_code430 v3_sinfo : #define NID_sinfo_access 398 I haven't checked other values. As a consequence SubjectInfoAccess no longer works as a standard extension. __ 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]
openssl.exe 0.9.6a
Hi, Where/How can I find the openssl.exe (application file) in the 0.9.6a version? Thanks Daniela -- Daniela Prestipino [EMAIL PROTECTED] I.D.S., Informatica Distribuita e Software srl Via Consolare Pompea 19 98168 Messina ITALIA Tel.: +39 90 353638 Fax : +39 90 3500063 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Various patches for 0.9.6d and 0.9.7-beta1
Hello, I have two patches for hpux64-parisc-gcc support in Configure and one to correct an error in evp_test.c, which calls strsep instead of sstrsep (09.7-beta1 only). (See attached file: openssl-0.9.7-beta1.patch)(See attached file: openssl-0.9.6d.patch)(See attached file: openssl-0.9.7-beta1.evp_test.patch) I have tests the hpux64 with gcc-3.1.0 and make test runs through correctly. These are not the most optimal values (eg it sets the -g flag and no optimization) but gcc for hppa64-hp-hpux11.00 is still a little flaky. This currently doesn't create shared libraries. The GNU linker is very flaky but I wouldn't take too much to create shared libaries with the HP linker. Cheers Ross - Ross Alexander He knows no more about his MIS - NEC Europe Limiteddestiny than a tea leaf knows Work ph: +44 20 8752 3394 the history of East India Company openssl-0.9.7-beta1.patch Description: Binary data openssl-0.9.6d.patch Description: Binary data openssl-0.9.7-beta1.evp_test.patch Description: Binary data
Re: Various patches for 0.9.6d and 0.9.7-beta1
On Mon, Jun 10, 2002 at 01:52:12PM +0100, [EMAIL PROTECTED] wrote: I have two patches for hpux64-parisc-gcc support in Configure and one to correct an error in evp_test.c, which calls strsep instead of sstrsep (09.7-beta1 only). Thanks. The strsep issue is already fixed in the current tree. (See attached file: openssl-0.9.7-beta1.patch)(See attached file: openssl-0.9.6d.patch)(See attached file: openssl-0.9.7-beta1.evp_test.patch) I have tests the hpux64 with gcc-3.1.0 and make test runs through correctly. These are not the most optimal values (eg it sets the -g flag and no optimization) but gcc for hppa64-hp-hpux11.00 is still a little flaky. This currently doesn't create shared libraries. The GNU linker is very flaky but I wouldn't take too much to create shared libaries with the HP linker. I don't yet fully understand your patches (I only have gcc-3.0.x on HP-UX 10.20, so I am not familiar with the latest 64bit issues). It however seems, that nowhere any 64bit command line option is used. Doesn't this mean, that 32bit code is generated? For hpux64-parisc-cc the +DD64 flag is required. 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]
Re: [openssl.org #11] Fw: trustway pkcs11 engine for openssl
Richard Levitte via RT [EMAIL PROTECTED] wrote: 2. Those extra functions in the RSA method, are they really needed? I understand that they provide a lot of automagic things, but then it should be added in the ENGINE framework as something that would be potentially available for any hardware (that supports that extra functionality). Also, when it comes to loading keys, the current modus operandi is to explicitely use the ENGINE key loading functions rather than having some implicit functionality going on. The reason is that we'd prefer not to surprise the users too much. Afchine Madjlessi [EMAIL PROTECTED] wrote The Bull Trustway CC2000 isn't only a cryptographic accelerator card, it is a high level security hardware providing key generation and storage in secure memory. That's why we can't use ENGINE key loading functions. Yes those extra functions are really needed when using this kind of hardware. You can find below a sample to generate and store key pair when using openssl-engine over trustway PKCS#11 card. # # create certificate request, sign it - server certificate # (an RSA key pair is generated) # # 1. making a CA certificate # CA-trustway.sh -newca # openssl req -engine trustway -config ../openssl.cnf \ -new -x509 -keyout ./demoCA/private/cakey.pem \ -out =./demoCA/cacert.pem -days 365 # # 2. create a certificate request # CA-trustway.sh -newreq # openssl req -engine trustway -config ../openssl.cnf -new \ -keyout newkey.pem -out newreq.pem -nodes -days 365 # # 3.create a certificate request # CA-trustway.sh -signreq # openssl ca -engine trustway -config ../openssl.cnf \ -policy policy_anything -out newcert.pem -infiles newreq.pem afchine __ [EMAIL PROTECTED] Bull Technologies - Trustway RD - Networking Security http://www.servers.bull.com/trustway __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Various patches for 0.9.6d and 0.9.7-beta1
Lutz, I think the problem is because 32bit HP uses the SOM object format and 64bit HP uses ELF. These are quite different and hence gcc cannot be configured for both targets. So when you build gcc it is a different target (hppa64-hp-hpux11.00) for 64bit than 32bit (hppa2.0n-hp-hpux11.00). NB On PA-linux this is different, its uses ELF32 and ELF64 respectively, so I think a single instance of gcc does have 32/64 bit flag. Thats why there are no flags to tell gcc to produce 64bit code, it will always operate in LP64 mode. Because there is no real autoconfigure you have to assume the user knows what they are doing. I was mainly using openssl to test gcc, as it has a very solid test regime. I hope this explaination makes sense. Cheers, Ross - Ross Alexander He knows no more about his MIS - NEC Europe Limiteddestiny than a tea leaf knows Work ph: +44 20 8752 3394 the history of East India Company |-+- | | Lutz Jaenicke | | | [EMAIL PROTECTED]| | | Cottbus.DE | | | Sent by: | | | owner-openssl-dev@open| | | ssl.org | | | | | | | | | 10/06/2002 14:27 | | | Please respond to | | | openssl-dev | | | | |-+- -| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Various patches for 0.9.6d and 0.9.7-beta1 | -| On Mon, Jun 10, 2002 at 01:52:12PM +0100, [EMAIL PROTECTED] wrote: I have two patches for hpux64-parisc-gcc support in Configure and one to correct an error in evp_test.c, which calls strsep instead of sstrsep (09.7-beta1 only). Thanks. The strsep issue is already fixed in the current tree. (See attached file: openssl-0.9.7-beta1.patch)(See attached file: openssl-0.9.6d.patch)(See attached file: openssl-0.9.7-beta1.evp_test.patch) I have tests the hpux64 with gcc-3.1.0 and make test runs through correctly. These are not the most optimal values (eg it sets the -g flag and no optimization) but gcc for hppa64-hp-hpux11.00 is still a little flaky. This currently doesn't create shared libraries. The GNU linker is very flaky but I wouldn't take too much to create shared libaries with the HP linker. I don't yet fully understand your patches (I only have gcc-3.0.x on HP-UX 10.20, so I am not familiar with the latest 64bit issues). It however seems, that nowhere any 64bit command line option is used. Doesn't this mean, that 32bit code is generated? For hpux64-parisc-cc the +DD64 flag is required. 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: Various patches for 0.9.6d and 0.9.7-beta1
On Mon, Jun 10, 2002 at 03:06:22PM +0100, [EMAIL PROTECTED] wrote: I think the problem is because 32bit HP uses the SOM object format and 64bit HP uses ELF. These are quite different and hence gcc cannot be configured for both targets. So when you build gcc it is a different target (hppa64-hp-hpux11.00) for 64bit than 32bit (hppa2.0n-hp-hpux11.00). NB On PA-linux this is different, its uses ELF32 and ELF64 respectively, so I think a single instance of gcc does have 32/64 bit flag. So the entries you supplied are for gcc (hppa64-hp-hpux11.00)? Is there a way for config to find out itself? Please have a look into config and search for GCC_ARCH to see what I mean. 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]
Re: Various patches for 0.9.6d and 0.9.7-beta1
So the entries you supplied are for gcc (hppa64-hp-hpux11.00)?
Is there a way for config to find out itself? Please have a look
into config and search for GCC_ARCH to see what I mean.
Sure. It will take me a couple of days. In GCC 3.1 gcc --version
doesn't work the same way so I will looking at gcc -v | egrep ^gcc
version
to do the same job.
It may be best to compile a program like the following ...
#include stdio.h
int main()
{
printf(%d.%d.%d\n, __GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__);
return 0;
}
This way you have complete control over the format.
Cheers,
Ross
-
Ross Alexander He knows no more about his
MIS - NEC Europe Limiteddestiny than a tea leaf knows
Work ph: +44 20 8752 3394 the history of East India Company
|-+-
| | Lutz Jaenicke |
| | [EMAIL PROTECTED]|
| | Cottbus.DE |
| | Sent by: |
| | owner-openssl-dev@open|
| | ssl.org |
| | |
| | |
| | 10/06/2002 15:14 |
| | Please respond to |
| | openssl-dev |
| | |
|-+-
-|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Various patches for 0.9.6d and 0.9.7-beta1
|
-|
On Mon, Jun 10, 2002 at 03:06:22PM +0100, [EMAIL PROTECTED]
wrote:
I think the problem is because 32bit HP uses the SOM object format
and 64bit HP uses ELF. These are quite different and hence gcc
cannot be configured for both targets. So when you build gcc it is
a different target (hppa64-hp-hpux11.00) for 64bit than 32bit
(hppa2.0n-hp-hpux11.00). NB On PA-linux this is different, its
uses ELF32 and ELF64 respectively, so I think a single instance
of gcc does have 32/64 bit flag.
So the entries you supplied are for gcc (hppa64-hp-hpux11.00)?
Is there a way for config to find out itself? Please have a look
into config and search for GCC_ARCH to see what I mean.
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: Various patches for 0.9.6d and 0.9.7-beta1
On Mon, Jun 10, 2002 at 03:44:07PM +0100, [EMAIL PROTECTED] wrote: So the entries you supplied are for gcc (hppa64-hp-hpux11.00)? Is there a way for config to find out itself? Please have a look into config and search for GCC_ARCH to see what I mean. Sure. It will take me a couple of days. In GCC 3.1 gcc --version doesn't work the same way so I will looking at gcc -v | egrep ^gcc version to do the same job. Please load down a current snapshot. GCC-3.1 support for --version should be added. 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]
Re: [openssl.org #80] [Lutz.Jaenicke@aet.TU-Cottbus.DE: Re: Naina announce (was: [ANNOUNCE] OpenSSL 0.9.1 beta 1 released)]
On Wed, Jun 05, 2002 at 09:33:25AM +0200, Vadim Fedukovich via RT wrote: patch to add SET-specific objects is attached. It's rather large, still it would let to build Naina without modifying openssl code. I have made some further modifications: I did not like the direct use of 2 23 42 for SET (even though correct of course) but wanted to build the tree from the root. While doing this I noted, that the CCITT has long since been renamed to ITU-T. I therefore made some additional changes to use the new name and prepare aliases for CCITT. * It should be no problem to apply this to 0.9.8. * I am afraid to break things beyond NID_uniqueIdentifier in 0.9.7. (Due to the alias for CCITT nothing should happen, though). Opinions? 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]
Re: make depend from Configure?
Richard Levitte - VMS Whacker wrote:
rsalz Or, since perl is already required, include a quick perl script that does
rsalz 70% of the job.
Hmm, that could possibly be done... Do you have something ready?
Attached. Hope it's useful.
/r$
#! /usr/bin/env perl --
## Rough tool to write Makefile dependencies by scanning source.
## Not an error if a file isn't found.
## Rich $alz, [EMAIL PROTECTED] Public domain.
%found = {};
@searchdirs = ('.', '/usr/include');
$verbose = 0;
sub
doline()
{
local ( $file, $header, $angles ) = ( shift, shift, shift );
local ( $full ) = $found{$header};
local ( $dir );
if ( defined $full ) {
print $file: $full\n;
return;
}
checkdir: foreach $dir ( @searchdirs ) {
if ( $angles == 1 ) {
$angles = 0;
next checkdir;
}
if ( -f $dir/$header ) {
$found{$header} = $dir/$header;
print $file: $dir/$header\n;
return;
}
}
# Not found, print a comment
print # $file: $header\n;
}
$dashdash = 0;
$nosysincs = 0;
argloop: foreach $arg ( @ARGV ) {
if ( ! $dashdash ) {
if ( $arg eq '-nosysincludes' ) {
$nosysincs = 1;
next argloop;
}
if ( $arg =~ /^-I(.*)/ ) {
push(@searchdirs, $1);
next argloop;
}
if ( $arg =~ /^-[DU]/ ) {
# XXX could parse those options.
next argloop;
}
if ( $arg eq '--' ) {
$dashdash++;
next argloop;
}
if ( $arg =~ /^-/ ) {
die Unknown flag $_;
}
}
if ( !open(FH, $arg) ) {
warn Can' open $arg ($!), skipping.;
next argloop;
}
# Look for #include lines in the file.
fline: while ( $line = FH ) {
chop($line);
if ( $line =~ /#\s*include\s+([^]+)/ ) {
doline($arg, $1, 0);
}
elsif ( ! $nosysincs $line =~ /#\s*include\s+([^]+)/ ) {
doline($arg, $1, 1);
}
}
close(FH);
}
Re: Various patches for 0.9.6d and 0.9.7-beta1
Lutz,
I've picked up the snapshot. There is a problem with the new code.
GCCVER=`(gcc --version) 2/dev/null | head -1`
if [ $GCCVER != ]; then
CC=gcc
# then strip off whatever prefix Cygnus as well as GCC 3.1 prepends
# the number with... Hopefully, this will work for any future prefixes
# as well.
GCCVER=`echo $GCCVER | sed 's/^[a-zA-Z ()]*\-//'`
# peak single digit before and after first dot, e.g. 2.95.1 gives 29
GCCVER=`echo $GCCVER | sed 's/\([0-9]\)\.\([0-9]\).*/\1\2/'`
else
CC=cc
fi
GCCVER=${GCCVER:-0}
The problem is with
GCCVER=`echo $GCCVER | sed 's/^[a-zA-Z ()]*\-//'`
The \- doesn't work with gcc 3.1 which outputs
gcc (GCC) 3.1.
I can fix the regex but I like know the reasoning behind it. I tried
^[a-zA-Z ()]*\-?
but this doesn't work with sed because it an extended regex and not
supported by
HP or GNU sed.
As for detecting 64bit GCC, that looks fairly easy. GCC passes a define
-D__LP64__
to cpp. Otherwise it would something like
int main()
{
if ((sizeof(long) == 8) (sizeof(void*) == 8)) return 1; /* LP64 */
or ((sizeof(long == 8) || (sizeof(void*) == 8)) return -1; /* error, this
should never happen on hpux */
or return 0;
}
would work.
Any suggestions?
Ross
-
Ross Alexander He knows no more about his
MIS - NEC Europe Limiteddestiny than a tea leaf knows
Work ph: +44 20 8752 3394 the history of East India Company
|-+-
| | Lutz Jaenicke |
| | [EMAIL PROTECTED]|
| | Cottbus.DE |
| | Sent by: |
| | owner-openssl-dev@open|
| | ssl.org |
| | |
| | |
| | 10/06/2002 15:46 |
| | Please respond to |
| | openssl-dev |
| | |
|-+-
-|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Various patches for 0.9.6d and 0.9.7-beta1
|
-|
On Mon, Jun 10, 2002 at 03:44:07PM +0100, [EMAIL PROTECTED]
wrote:
So the entries you supplied are for gcc (hppa64-hp-hpux11.00)?
Is there a way for config to find out itself? Please have a look
into config and search for GCC_ARCH to see what I mean.
Sure. It will take me a couple of days. In GCC 3.1 gcc --version
doesn't work the same way so I will looking at gcc -v | egrep ^gcc
version
to do the same job.
Please load down a current snapshot. GCC-3.1 support for --version should
be added.
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: Various patches for 0.9.6d and 0.9.7-beta1
On Mon, Jun 10, 2002 at 04:53:36PM +0100, [EMAIL PROTECTED] wrote:
I've picked up the snapshot. There is a problem with the new code.
GCCVER=`(gcc --version) 2/dev/null | head -1`
if [ $GCCVER != ]; then
CC=gcc
# then strip off whatever prefix Cygnus as well as GCC 3.1 prepends
# the number with... Hopefully, this will work for any future prefixes
# as well.
GCCVER=`echo $GCCVER | sed 's/^[a-zA-Z ()]*\-//'`
# peak single digit before and after first dot, e.g. 2.95.1 gives 29
GCCVER=`echo $GCCVER | sed 's/\([0-9]\)\.\([0-9]\).*/\1\2/'`
else
CC=cc
fi
GCCVER=${GCCVER:-0}
The problem is with
GCCVER=`echo $GCCVER | sed 's/^[a-zA-Z ()]*\-//'`
The \- doesn't work with gcc 3.1 which outputs
gcc (GCC) 3.1.
Hmm. From cvs log config:
revision 1.101
date: 2002/06/05 05:00:51; author: levitte; state: Exp; lines: +5 -3
Update the recognision of GCC version numbers to handle the prefix text
that GCC 3.1 adds to the --version output
Maybe the change for 1.101 (or similar fo the BRANCHes) was not sufficient.
I have CC'ed Richard Levitte.
I can fix the regex but I like know the reasoning behind it. I tried
^[a-zA-Z ()]*\-?
but this doesn't work with sed because it an extended regex and not
supported by
HP or GNU sed.
As for detecting 64bit GCC, that looks fairly easy. GCC passes a define
-D__LP64__
to cpp. Otherwise it would something like
int main()
{
if ((sizeof(long) == 8) (sizeof(void*) == 8)) return 1; /* LP64 */
or ((sizeof(long == 8) || (sizeof(void*) == 8)) return -1; /* error, this
should never happen on hpux */
or return 0;
}
would work.
__LP__64 should work for the scheme used for other platforms, so we
probably don't need to test-compile a file.
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]
Re: [openssl.org #80] [Lutz.Jaenicke@aet.TU-Cottbus.DE: Re: Naina announce (was: [ANNOUNCE] OpenSSL 0.9.1 beta 1 released)]
On Mon, Jun 10, 2002 at 05:42:42PM +0200, Lutz Jaenicke via RT wrote: On Wed, Jun 05, 2002 at 09:33:25AM +0200, Vadim Fedukovich via RT wrote: patch to add SET-specific objects is attached. It's rather large, still it would let to build Naina without modifying openssl code. I have made some further modifications: I did not like the direct use of 2 23 42 for SET (even though correct of course) but wanted to build the tree from the root. While doing this I noted, that the CCITT has long since been renamed to ITU-T. I therefore made some additional changes to use the new name and prepare aliases for CCITT. * It should be no problem to apply this to 0.9.8. * I am afraid to break things beyond NID_uniqueIdentifier in 0.9.7. (Due to the alias for CCITT nothing should happen, though). Opinions? Lutz Naina is in development/testing for the moment and nobody actually use it in production. If someone do see problems for other applications this patch could stay as part of Naina package for some time. regards, Vadim __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Prototypes SSL_write() SSL_read() problem in openssl/ssl.h for 64-bit applications
The prototype for SSL_write() and SSL_read() both have their last parameters to be int. I believe that this last parameter needs to be of type size_t. Two reasons for doing this: 1) This will allow applications to be compiled in either 32-bit or 64-bit mode without any warnings from the compiler about implicit conversions. On 64-bit applications, size_t to int is really a typecast from a long to an int, where long = 8-bytes and int = 4-bytes. Possible loss of data. 2) This will make these functions look more like thewrite() read() system calls of Unix. There might be more instances of this, but these are the only 2 functions that I have run into thus far. Darin Broady [EMAIL PROTECTED] Lexmark International, Inc. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Prototypes SSL_write() SSL_read() problem in openssl/ssl.h for 64-bit applications
The same also goes for CRYPTO_malloc(int, char *, int). It probably should be CRYPTO_malloc(size_t, char *, int). The same would go for CRYPTO_realloc() and CRYPTO_remalloc(). Darin Broady [EMAIL PROTECTED] Lexmark International, Inc. Darin_Broady/Lex/Lexmark.LEXMARK@sweeper.lex.lexmark.com on 06/10/2002 03:57:18 PM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Darin Broady/Lex/Lexmark) Subject: Prototypes SSL_write() SSL_read() problem in openssl/ssl.h for 64-bit applications The prototype for SSL_write() and SSL_read() both have their last parameters to be int. I believe that this last parameter needs to be of type size_t. Two reasons for doing this: 1) This will allow applications to be compiled in either 32-bit or 64-bit mode without any warnings from the compiler about implicit conversions. On 64-bit applications, size_t to int is really a typecast from a long to an int, where long = 8-bytes and int = 4-bytes. Possible loss of data. 2) This will make these functions look more like thewrite() read() system calls of Unix. There might be more instances of this, but these are the only 2 functions that I have run into thus far. Darin Broady [EMAIL PROTECTED] Lexmark International, Inc. __ 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: make depend from Configure?
In message [EMAIL PROTECTED] on Mon, 10 Jun 2002 11:46:49 -0400, Rich Salz [EMAIL PROTECTED] said: rsalz Attached. Hope it's useful. Unfortunately no. We need one that works a little more lika a preprocessor, so macros are actually taken into account. Think excluded algorithms. -- 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: Various patches for 0.9.6d and 0.9.7-beta1
In message [EMAIL PROTECTED] on Mon, 10 Jun 2002
18:03:43 +0200, Lutz Jaenicke [EMAIL PROTECTED] said:
Lutz.Jaenicke On Mon, Jun 10, 2002 at 04:53:36PM +0100, [EMAIL PROTECTED]
wrote:
Lutz.Jaenicke I've picked up the snapshot. There is a problem with the new code.
Lutz.Jaenicke
Lutz.Jaenicke GCCVER=`(gcc --version) 2/dev/null | head -1`
Lutz.Jaenicke if [ $GCCVER != ]; then
Lutz.JaenickeCC=gcc
Lutz.Jaenicke# then strip off whatever prefix Cygnus as well as GCC 3.1 prepends
Lutz.Jaenicke# the number with... Hopefully, this will work for any future
prefixes
Lutz.Jaenicke# as well.
Lutz.JaenickeGCCVER=`echo $GCCVER | sed 's/^[a-zA-Z ()]*\-//'`
Lutz.Jaenicke# peak single digit before and after first dot, e.g. 2.95.1 gives 29
Lutz.JaenickeGCCVER=`echo $GCCVER | sed 's/\([0-9]\)\.\([0-9]\).*/\1\2/'`
Lutz.Jaenicke else
Lutz.JaenickeCC=cc
Lutz.Jaenicke fi
Lutz.Jaenicke GCCVER=${GCCVER:-0}
Lutz.Jaenicke
Lutz.Jaenicke The problem is with
Lutz.Jaenicke
Lutz.JaenickeGCCVER=`echo $GCCVER | sed 's/^[a-zA-Z ()]*\-//'`
Lutz.Jaenicke
Lutz.Jaenicke The \- doesn't work with gcc 3.1 which outputs
Lutz.Jaenicke
Lutz.Jaenicke gcc (GCC) 3.1.
Lutz.Jaenicke
Lutz.Jaenicke Hmm. From cvs log config:
Lutz.Jaenicke
Lutz.Jaenicke revision 1.101
Lutz.Jaenicke date: 2002/06/05 05:00:51; author: levitte; state: Exp; lines: +5 -3
Lutz.Jaenicke Update the recognision of GCC version numbers to handle the prefix text
Lutz.Jaenicke that GCC 3.1 adds to the --version output
Lutz.Jaenicke
Lutz.Jaenicke Maybe the change for 1.101 (or similar fo the BRANCHes) was not
sufficient.
Lutz.Jaenicke I have CC'ed Richard Levitte.
Correct, the sed should probably be done in two steps instead of one.
I'll see what I can do tomorrow (if I remember).
--
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]
