[openssl.org #772] 32/64-bit detection on HPUX 11.11
To detect if your HPUX 11.11 system is running in 64-bit mode, you simply
have to do the following:
# /usr/bin/file /stand/vmunix
You should get the following response if you are 64-bit.
/stand/vmunix: ELF-64 executable object file - PA-RISC 2.0 (LP64)
And you'll get the following if you are 32-bit:
/stand/vmunix: PA-RISC1.1 executable -not stripped
So the section in the config shell script that needs to be modified (i
believe) is:
HP-UX:*)
HPUXVER=`echo ${RELEASE}|sed -e 's/[^.]*.[0B]*//'`
case $HPUXVER in
1[0-9].*) # HPUX 10 and 11 targets are unified
echo ${MACHINE}-hp-hpux10; exit 0
;;
*)
echo ${MACHINE}-hp-hpux; exit 0
;;
esac
;;
It should be changed to detect 10.X systems separate from 11.X systems.
11.X systems break down to three different categories:
11.00
11.11
11.22
Each which you can check to see if it is running 32 or 64bit mode.
I am not familiar with the config sh script enough to modify it (i tried
but I broke it!), but I can provide whatever data is necessary from an
HPUX 11.11 64-bit system if someone wants to actually modify the config
sh.
Thanks,
v.
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
Richard Levitte - VMS Whacker levitte
@stacken.kth.se
Sent by: owner-openssl-users
11/18/2003 06:17 PM
Please respond to openssl-users
To: [EMAIL PROTECTED], Vinnie Lima/CEG/[EMAIL PROTECTED]
cc:
Subject:Re: Cannot make test openssl-0.9.7c on HPUX
11.11
Now, the really cool thing would be if someone (you?) could provide us
with some sh code that identifies 64bit HP/UX so we could set that up
in the script 'config'. Please take a look at that file and see if
you can figure out a recipe to detect what's needed.
In message [EMAIL PROTECTED]
on Tue, 18 Nov 2003 16:54:11 -0500, Vinnie Lima [EMAIL PROTECTED] said:
vlima It worked. Thanks for your suggestions. You were right, trying to
build
vlima 32bit version on hpux 64bit isnt that great of an idea ;)
vlima
vlima Here are my parameters for the next unfortunate soul:
vlima
vlima Configure parameter:
vlima
vlima /opt/perl/bin/perl ./Configure hpux64-parisc-gcc -D_REENTRANT
[...]
-
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!
--
Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED]
[EMAIL PROTECTED] \ S-168 36 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
User Support 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.org #772] 32/64-bit detection on HPUX 11.11
Now, the really cool thing would be if someone (you?) could provide us with some sh code that identifies 64bit HP/UX so we could set that up in the script 'config'. ??? 'config' tells apart 32- and 64-bit HP/UX kernels since long time ago. Look for 'getconf KERNEL_BITS'. # /usr/bin/file /stand/vmunix Even though probability that some user would have kernel image some other place is diminishingly low, formally it's not appropriate to 'file /stand/vmunix', as user is free to boot /whatever/image. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11
In message [EMAIL PROTECTED] on Wed, 19 Nov 2003 09:38:04 +0100 (MET), Andy Polyakov via RT [EMAIL PROTECTED] said: rt rt Now, the really cool thing would be if someone (you?) could provide us rt with some sh code that identifies 64bit HP/UX so we could set that up rt in the script 'config'. rt rt ??? 'config' tells apart 32- and 64-bit HP/UX kernels since long time rt ago. Look for 'getconf KERNEL_BITS'. Oh? So how come 64-bit people get a build that tries to go for 32-bit? What have we missed? I haven't looked yet, but I might tonight, if I remember... - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. You don't have to be rich, a $10 donation is appreciated! -- Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 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: [openssl.org #772] 32/64-bit detection on HPUX 11.11
On Wed, Nov 19, 2003 at 09:50:41AM +0100, Richard Levitte - VMS Whacker via RT wrote: In message [EMAIL PROTECTED] on Wed, 19 Nov 2003 09:38:04 +0100 (MET), Andy Polyakov via RT [EMAIL PROTECTED] said: rt rt Now, the really cool thing would be if someone (you?) could provide us rt with some sh code that identifies 64bit HP/UX so we could set that up rt in the script 'config'. rt rt ??? 'config' tells apart 32- and 64-bit HP/UX kernels since long time rt ago. Look for 'getconf KERNEL_BITS'. Oh? So how come 64-bit people get a build that tries to go for 32-bit? What have we missed? I haven't looked yet, but I might tonight, if I remember... Actually the problem doesn't seem to be the kernel but the compiler used. The original requestor uses a gcc version 3.3.2. The 32/64 bit decision is made by running the GCC in question and looking for __LP64__ in the output (lines 410-418 in 0.9.7-CVS). Maybe running a 64bit compiler on a 32bit kernel does not correctly determine which target should be used. (Maybe it isn't a good idea anyway.) I suppose the original requestor (living in another timezone) can clarify this a bit later. 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 #772] 32/64-bit detection on HPUX 11.11
rt Now, the really cool thing would be if someone (you?) could provide us rt with some sh code that identifies 64bit HP/UX so we could set that up rt in the script 'config'. rt rt ??? 'config' tells apart 32- and 64-bit HP/UX kernels since long time rt ago. Look for 'getconf KERNEL_BITS'. Oh? So how come 64-bit people get a build that tries to go for 32-bit? Because it defaults to 32-bit build and challenges user to manually invoke ./Configure hpux64-parisc2-cc if 64-bit build is required. The background for such decision is that most other programs using the toolkit, most notably apache and openssh, default to 32-bit build, at least did at that time. Keep in mind that 32-bit PARISC2 code is as fast as 64-bit, if not faster. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11
rt Now, the really cool thing would be if someone (you?) could provide us rt with some sh code that identifies 64bit HP/UX so we could set that up rt in the script 'config'. rt rt ??? 'config' tells apart 32- and 64-bit HP/UX kernels since long time rt ago. Look for 'getconf KERNEL_BITS'. Oh? So how come 64-bit people get a build that tries to go for 32-bit? Because it defaults to 32-bit build and challenges user to manually invoke ./Configure hpux64-parisc2-cc if 64-bit build is required. The background for such decision is that most other programs using the toolkit, most notably apache and openssh, default to 32-bit build, at least did at that time. Keep in mind that 32-bit PARISC2 code is as fast as 64-bit, if not faster. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11
rt Now, the really cool thing would be if someone (you?) could provide us rt with some sh code that identifies 64bit HP/UX so we could set that up rt in the script 'config'. rt rt ??? 'config' tells apart 32- and 64-bit HP/UX kernels since long time rt ago. Look for 'getconf KERNEL_BITS'. Oh? So how come 64-bit people get a build that tries to go for 32-bit? What have we missed? I haven't looked yet, but I might tonight, if I remember... Actually the problem doesn't seem to be the kernel but the compiler used. The original requestor uses a gcc version 3.3.2. The 32/64 bit decision is made by running the GCC in question and looking for __LP64__ in the output (lines 410-418 in 0.9.7-CVS). Background for this __LP64__ decision was that [at least earlier versions of] gcc did not support multiple ABI on HP-UX. Meaning that if 'gcc -v -E -x c /dev/null' without extra arguments exhibits __LP64__ in its output, then you have *no* other option, but to produce 64-bit build. And vice versa. In other words './config' otherwise assumes that gcc is not capable of producing 64-bit code and goes for 32-bit build regarless kernel bit-ness. The relevant question is of requestor can confirm that gcc can *now* generate *both* 32- and 64-bit code? What's the switch? -m64 as on most of other plaforms or something else? Does './Configure hpux64-parisc-gcc -m64' work? Note the commentary section above hpux64-parisc-gcc... A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11
We have this working on HPUX ia64 in both 32 and 64 bit modes. You'll have to manually Configure anyway, there are three supported modes, 32 bit , 64 bit, and pa_risc, all of which are supported by the base OS. Autodetection is going to give the wrong answer 2 times in 3. The IBM patch with the code in it is available, but it's too big to post to this list. Peter Peter Waltenberg Team Lead IBM Crypto for C Team IBM/Tivoli Gold Coast Office Phone: +61-7-55524016 Andy Polyakov [EMAIL PROTECTED]To: [EMAIL PROTECTED] .se cc: [EMAIL PROTECTED] Sent by: Subject: Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11 owner-openssl-dev@ openssl.org 19/11/2003 07:40 PM Please respond to openssl-dev rt Now, the really cool thing would be if someone (you?) could provide us rt with some sh code that identifies 64bit HP/UX so we could set that up rt in the script 'config'. rt rt ??? 'config' tells apart 32- and 64-bit HP/UX kernels since long time rt ago. Look for 'getconf KERNEL_BITS'. Oh? So how come 64-bit people get a build that tries to go for 32-bit? What have we missed? I haven't looked yet, but I might tonight, if I remember... Actually the problem doesn't seem to be the kernel but the compiler used. The original requestor uses a gcc version 3.3.2. The 32/64 bit decision is made by running the GCC in question and looking for __LP64__ in the output (lines 410-418 in 0.9.7-CVS). Background for this __LP64__ decision was that [at least earlier versions of] gcc did not support multiple ABI on HP-UX. Meaning that if 'gcc -v -E -x c /dev/null' without extra arguments exhibits __LP64__ in its output, then you have *no* other option, but to produce 64-bit build. And vice versa. In other words './config' otherwise assumes that gcc is not capable of producing 64-bit code and goes for 32-bit build regarless kernel bit-ness. The relevant question is of requestor can confirm that gcc can *now* generate *both* 32- and 64-bit code? What's the switch? -m64 as on most of other plaforms or something else? Does './Configure hpux64-parisc-gcc -m64' work? Note the commentary section above hpux64-parisc-gcc... A. __ 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]
Reference of known ASN1_TEMPLATE
Hi, Is there a table that references all the known/declared ASN1_TEMPLATE ? The goal is to use OpenSSL for dynamic ASN1_TEMPLATE declaration, but to do this I need to set the ASN1_ITEM_EXP member. Frédéric Giudicelli http://www.newpki.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11
We have this working on HPUX ia64 in both 32 and 64 bit modes. You'll have to manually Configure anyway, there are three supported modes, 32 bit , 64 bit, and pa_risc, all of which are supported by the base OS. ./config tells apart IA-64 and PA-RISCs as well, and then it consciously defaults to 64-bit IA-64 build if executed on IA-64 machine and to 32-bit PA-RISC build - on PA-RISC. Autodetection is going to give the wrong answer 2 times in 3. ./config is expected to auto-detect most appropriate option for the platform it's being executed on. Can you confirm that it actually fails to detect platform as depicted above? I.e. hpux64-ia64-cc on IA-64 machine and hpux-parisc2-cc at PA-RISC2 machine? Blended builds (which would execute on both PA-RISC1.1 and 2.0 in this example), builds for another ABI (32-bit vs. 64-bit) or cross-platform builds (PA-RISC code on IA-64) were never ./config's domain, but something for user to think about. In other words you can't expect ./config to prepare for 3 builds (or why not 5: 64-bit IA-64, 32-bit IA-64, 64-bit PA-RISC2.0, 32-bit PA-RISC2.0, 32-bit blended PA-RISC?) and should invoke './Configure proper-line; make; ...' multiple times if so required. At least for the time being. We have to decide what we want to discuss in this particular context. ./config's intended behaviour or bugs in it. The IBM patch with the code in it is available, but it's too big to post to this list. Post it to openssl-team then:-) A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Reference of known ASN1_TEMPLATE
On Wed, Nov 19, 2003, Frédéric Giudicelli wrote: Hi, Is there a table that references all the known/declared ASN1_TEMPLATE ? The goal is to use OpenSSL for dynamic ASN1_TEMPLATE declaration, but to do this I need to set the ASN1_ITEM_EXP member. Not sure what you mean. Do you want all top level ASN1_ITEM structures? If so something like: nm libcrypto.a | grep _it might do the trick. Alternatively parsing the header files will do that in the same way mkdef.pl does. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11
Oh? So how come 64-bit people get a build that tries to go for 32-bit? What have we missed? I haven't looked yet, but I might tonight, if I remember... Yes, during media installation of the OS (11.00, 11.11, etc), you can choose 64 or 32 bit operating system installation. 11.11 (11i) defaults to 64-bit at least on the platforms we are utilizing (rp24XX and 54XX). v. This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11
??? 'config' tells apart 32- and 64-bit HP/UX kernels since long time ago. Look for 'getconf KERNEL_BITS'. That may be the case, but it didnt detect my 64-bit kernel (thus the root of my emails)... As clarified by Lutz the issue is that kernel 64-bitness is not checked at all, whenever gcc is used and 'getconf KERNEL_BITS' is never invoked. The subject line should have read 32/64-bit detection on HPUX 11.11 for gcc builds. Additionally, for those who have kernel in other locations, I would suggest providing the option of specifying where the kernel is located (either through a Makefile or Configure file). Why? If it should be sufficient to invoke 'getconf KERNEL_BITS' to cover even impossible cases? Or can you really confirm that 'getconf KERNEL_BITS' fails on your system if actually called? A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11
Since the OpenSSL libraries are used by many other applications, it might be appropriate for the Configure to build both 32 and 64 bit version of the libs. This applies to more then just HP and more then just OPenSSL. The configure should use the local systems naming/location conventions for storing these libs. Andy Polyakov via RT wrote: rt Now, the really cool thing would be if someone (you?) could provide us rt with some sh code that identifies 64bit HP/UX so we could set that up rt in the script 'config'. rt rt ??? 'config' tells apart 32- and 64-bit HP/UX kernels since long time rt ago. Look for 'getconf KERNEL_BITS'. Oh? So how come 64-bit people get a build that tries to go for 32-bit? Because it defaults to 32-bit build and challenges user to manually invoke ./Configure hpux64-parisc2-cc if 64-bit build is required. The background for such decision is that most other programs using the toolkit, most notably apache and openssh, default to 32-bit build, at least did at that time. Keep in mind that 32-bit PARISC2 code is as fast as 64-bit, if not faster. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11
The relevant question is of requestor can confirm that gcc can *now* generate *both* 32- and 64-bit code? What's the switch? -m64 as on most of other plaforms or something else? Does './Configure hpux64-parisc-gcc -m64' work? Note the commentary section above hpux64-parisc-gcc... snip nmcmadam:/opt/patches/openssl-0.9.7c ./Configure hpux64-parisc-gcc -m64 ... Configured for hpux64-parisc-gcc. nmcmadam:/opt/patches/openssl-0.9.7c /snip Does that help? Not really:-) What happens if you actually run 'make'? Does 'gcc -m64' actually work? Are resulting object modules ELF64? Does very same command, gcc, *without* -m64 generates 32-bit PA-RISC relocatable object? A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11
Since the OpenSSL libraries are used by many other applications, it might be appropriate for the Configure to build both 32 and 64 bit version of the libs. Yes, it's indeed appropriate and support might be implemented at some point (starting with unification of .h files), but it's not the case *now*. As for today multi-ABI builds is something for user to consider. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11
Andy Polyakov wrote: Since the OpenSSL libraries are used by many other applications, it might be appropriate for the Configure to build both 32 and 64 bit version of the libs. Yes, it's indeed appropriate and support might be implemented at some point (starting with unification of .h files), but it's not the case *now*. As for today multi-ABI builds is something for user to consider. I agree. I am talking long term, and needs to be addressed by all the open source community. Just adding a lib to /usr/local/lib is not good enough anymore. One of the problems is the interdependencies of all these Open Source packages. If they only build one version, 32 or 64, then the rest have to be built the same way. For example at our site I see OpenSSH, OpenSSL, Kerberos, OpenAFS all being used in combination. I would like to see OpenSSL take a lead on this, building both 32 and 64 bit versions where appropriate. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11
'./Configure hpux64-parisc-gcc -m64' work? snip nmcmadam:/opt/patches/openssl-0.9.7c ./Configure hpux64-parisc-gcc -m64 ... Configured for hpux64-parisc-gcc. nmcmadam:/opt/patches/openssl-0.9.7c /snip Does that help? Not really:-) What happens if you actually run 'make'? It fails make (see output below) Does 'gcc -m64'actually work? No. (see output below). Does it mean that your gcc without any options generate ELF64 object modules then? Because if it does, then original ./config should have worked and configured for 64-bit build [without even checking for kernel bit-ness!]. If gcc without extra option doesn't generate ELF64 object modules, then it's no point to check for kernel bit-ness, *unless* we know what command line option makes gcc generate different object modules. So if you *know* that your gcc is capable of generating both ELF64 and 32-bit object modules, then you should figure out what is the command line option and tell us. If there is no such option, then ./config does its best as it is now. Are resulting object modules ELF64? How can I check it? Well, it was least exepcted to get such question from somebody who has suggested to run 'file /stand/vmunix':-) With 'file some.o' of course! nmcmadam:/opt/patches/openssl-0.9.7c ./Configure hpux64-parisc-gcc ... Configured for hpux64-parisc-gcc. make finish successfully. What does `file apps/openssl' print then? A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11
Since the OpenSSL libraries are used by many other applications, it might be appropriate for the Configure to build both 32 and 64 bit version of the libs. Yes, it's indeed appropriate and support might be implemented at some point (starting with unification of .h files), but it's not the case *now*. As for today multi-ABI builds is something for user to consider. I agree. I am talking long term, and needs to be addressed by all the open source community. Just adding a lib to /usr/local/lib is not good enough anymore. No, it's not good enough, but what does it have to do with this request ticket? Nothing. The ticket will be eventually closed, because the core issue will be addressed [or written-off] and we forget all about this very discussion. In other words, you should have posed separate question:-) A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11
It should be changed to detect 10.X systems separate from 11.X systems. Why? 11.X systems break down to three different categories: 11.00 11.11 11.22 Why? What's so different between 11.x? Each which you can check to see if it is running 32 or 64bit mode. If the only difference is that 11.00 can be run in either 32- or 64-bit mode, then 'getconf KERNEL_BITS' perfectly covers for all cases (including Itanium machines!). And it covers even for 10.x. No, 'getconf KERNEL_BITS' is not actually supported by 10.x, but ./config script explicitly defaults to 32 in such cases. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #773] No OAEP support for S/MIME
Hi OpenSSL does not support OAEP for S/MIME mails. I think should be enabled in further version. One easy (may be not elegant) way is to do a simple fallback in EVP_PKEY_decypt(). Thanks, Thorsten __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11
On Wed, Nov 19, 2003 at 12:28:18PM +0100, Andy Polyakov wrote: The IBM patch with the code in it is available, but it's too big to post to this list. Post it to openssl-team then:-) A. Even better: do post it to [EMAIL PROTECTED] RT will forward the message to the list but will strip the attachment and store it for download. 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 #772] 32/64-bit detection on HPUX 11.11
If you can really confirm that './config -t' fails to print configuring for hpux64-parisc-gcc on your system, nmcmadam:/opt/patches/openssl-0.9.7c ./config -t Operating system: 9000/800-hp-hpux10 ^^ Well, HP-UX 11.x user might find this inappropriate, but it doesn't really gives the reason to tell apart 10.0 and every possible 11.x. Changing this particular line to 9000/800-hp-hpux1x instead is probably more appropriate... Configuring for hpux-parisc-gcc /usr/contrib/bin/perl ./Configure hpux-parisc-gcc -D_REENTRANT then submit output from 'gcc -v -E -x c /dev/null' command. nmcmadam:/opt/patches/openssl-0.9.7c gcc -V -E -x c /dev/null The line was with -v, not -V. gcc: couldn't run `hppa64-hp-hpux11.11-gcc--E': No such file or directory ^^^ (*hm seems like my gcc copy may have a problem! would this cause the 'config -t' mistake?*) No would in the last sentense. The question is does this cause the problem? and the answer is yes, it does. Why does it want to run *-gcc--E? Can you preprocess any .c file with just 'gcc -E somefile.c'? A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #773] No OAEP support for S/MIME
[EMAIL PROTECTED] - Wed Nov 19 18:10:06 2003]: Hi OpenSSL does not support OAEP for S/MIME mails. I think should be enabled in further version. One easy (may be not elegant) way is to do a simple fallback in EVP_PKEY_decypt(). That could be done but it would be none standard. The standard way involves quite a bit more work... The standard RFC3560 gives details of OAEP in CMS (as used in S/MIME v3). This specifies changes syntaxes for various parts of the ASN1 structures. OpenSSL currently doesn't support CMS, just PKCS#7. I hope to add CMS support one day if I can get enough interest in it. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11
Configuring for hpux-parisc-gcc /usr/contrib/bin/perl ./Configure hpux-parisc-gcc -D_REENTRANT then submit output from 'gcc -v -E -x c /dev/null' command. nmcmadam:/opt/InCharge6 gcc -v -E -x c /dev/null /usr/local/pa20_64/lib/gcc-lib/hppa64-hp-hpux11.11/3.3.2/cc1 -E -quiet -v -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=2 /dev/null cc1, not cpp0! A-a-a-a-a-h... They must have changed it in some 3.x, so that it doesn't show pre-defined symbols now:-( I mean it surely defines __LP64__ internally (you can't use /usr/include/*.h otherwise), but never shows it to us. G-r-r-r... Well, one can try to use 'echo __LP64__ | gcc -v -E -x c - | grep ^__LP64__' instead... I mean if you find 'grep ^__LP64__' returning true, then gcc generates 32-bit code... Can you verify this? Any other ideas? Oh! Could you send your /usr/local/pa20_64/lib/gcc-lib/hppa64-hp-hpux11.11/3.3.2/specs over... A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #774] problem installing openssl-0.9.4
Hi, when i run ./config i get: Operating system: sun4u-sun-solaris2 ./config: test: unknown operator (GCC) then on running make i get: making all in crypto... ( echo #ifndef MK1MF_BUILD; \ echo /* auto-generated by crypto/Makefile.ssl for crypto/cversion.c */; \ echo #define CFLAGS \cc -DTHREADS -D_REENTRANT -xtarget=ultra - xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DULTRASPARC -DMD5_ASM\; \ echo #define PLATFORM \solaris-sparcv9-cc\; \ echo #define DATE \`date`\; \ echo #endif ) buildinf.h cc -I. -I../include -DTHREADS -D_REENTRANT -xtarget=ultra -xarch=v8plus -xO5 - xs trconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DULTRASPARC -DMD5_ASM -c cryptlib. c sh: cc: not found *** Error code 1 make: Fatal error: Command failed for target `cryptlib.o' Current working directory /stl/blyth/openssl-0.9.4/crypto *** Error code 1 make: Fatal error: Command failed for target `all' Please can you help Regards [EMAIL PROTECTED] -- Swallow Technology Limited [EMAIL PROTECTED] Tel: +44 (0)20 7350 5000 Fax: +44 (0)20 7350 5010 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
about the sequence number field
I have a question anout the use of sequence number as a part of the input to the hash function during the MAC calculation. Does that security concerns? Would the security aspects of theSSL be affected if the sequence number is not used as a part of the input to the hash funtion for MAC calculation? Thanks, swami __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: about the sequence number field
hi, thanks for your quick reply. So if I can include the sequence number as a part of the protocol(may be another field added by the SSL) data, I still solve the problem of replay attacks and I can get rid of sequence number from the MAC calculation. So my MAC wouldnt depend on the sequence number now. To avoid replay attacks there are 2 options: 1. As it exists now. MAC would fail with duplicate packets. 2. Or if sequence number is made a part of the protocol and stripped of the MAC calulation, I can verify and avoid duplicate packets from the sequence number which could be made a part of the protocol data (even though the MAC would succeed). This is just as the way TCP works. If I'm wrong in any of these points please do correct me. Thanks again Lev for your quick reply. -swami On Wed, 19 Nov 2003, Lev Walkin wrote: Swaminathan P wrote: I have a question anout the use of sequence number as a part of the input to the hash function during the MAC calculation. Does that security concerns? Would the security aspects of theSSL be affected if the sequence number is not used as a part of the input to the hash funtion for MAC calculation? Sequence number prevents replay attacks. Both sides of SSL communication channel are keeping track of number of messages received. If somebody has ability to inject a record into the SSL stream which is the same as some other record observed on that stream, the sequence number melted in a MAC will prevent the SSL machinery to treat this record as a valid one. -- Lev Walkin [EMAIL PROTECTED] __ 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: about the sequence number field
Swaminathan P wrote: hi, thanks for your quick reply. So if I can include the sequence number as a part of the protocol(may be another field added by the SSL) data, I still solve the problem of replay attacks and I can get rid of sequence number from the MAC calculation. So my MAC wouldnt depend on the sequence number now. Basically, you're a) adding a piece (8 bytes in TLS) of predictable data into the byte stream sequence (making it a tiny bit easier for the symmetric key attack) and b) adding additional several bytes to the overall length of the data record (as opposed to have it melt into the fixed-size MAC). To avoid replay attacks there are 2 options: 1. As it exists now. MAC would fail with duplicate packets. 2. Or if sequence number is made a part of the protocol and stripped of the MAC calulation, I can verify and avoid duplicate packets from the sequence number which could be made a part of the protocol data (even though the MAC would succeed). This is just as the way TCP works. If I'm wrong in any of these points please do correct me. More or less true. But what are you really achieving by this besides loosing several bytes by having to extend a record? The protocol specifies that the MAC should be applied over unencrypted message, than an encryption should proceed over the message and the MAC. By having the sequence inside the data you're trying to make it closer to the attacker while making a thing to take longer to encrypt (because the message is longer). Thanks again Lev for your quick reply. -swami On Wed, 19 Nov 2003, Lev Walkin wrote: Swaminathan P wrote: I have a question anout the use of sequence number as a part of the input to the hash function during the MAC calculation. Does that security concerns? Would the security aspects of theSSL be affected if the sequence number is not used as a part of the input to the hash funtion for MAC calculation? Sequence number prevents replay attacks. Both sides of SSL communication channel are keeping track of number of messages received. If somebody has ability to inject a record into the SSL stream which is the same as some other record observed on that stream, the sequence number melted in a MAC will prevent the SSL machinery to treat this record as a valid one. -- Lev Walkin [EMAIL PROTECTED] __ 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] -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: about the sequence number field
On November 19, 2003 07:16 pm, Swaminathan P wrote: I have a question anout the use of sequence number as a part of the input to the hash function during the MAC calculation. Does that security concerns? Would the security aspects of theSSL be affected if the sequence number is not used as a part of the input to the hash funtion for MAC calculation? As Les pointed out, this helps detect replay (or removal) attacks. It also forces the underlying transport to be reliable and ordered, so that the SSL/TLS encapsulation in turn presents what appears to be a reliable and ordered channel to the user of the protocol. For example, it doesn't stop you trying to run SSL/TLS over something like UDP that does not these sorts of guarantees, but this aspect of the SSL/TLS protocol will allow you to detect (in theory) if the packets arrive out of order or don't turn up at all. It will not *recover* from such problems though, so this sequence number trick is simply to verify reliability of the transport, without providing any recovery mechanism if the ordering and reliability assumptions aren't met. But there's two far more fundamental problems with trying to bypass this ordering issue anyway. (1) the ciphering used to en/decrypt the payloads of SSL/TLS records (after the initial handshake has agreed parameters) is typically stateful, so if you get records duplicated, removed, or out-of-order, then en/decryption will start misreading all subsequent records as senseless noise. (2) during a handshake or a renegotiation, the finished messages use MAC calculations over *all* the previous handshake messages *in order*. Note that all and in order mean that if you lose reliability during the handshake or renegotiation phase, you get the SSL/TLS equivalent of a carrier disconnect - no amount of sequencing logic in the application protocol will matter as this corruption in the handshake protocol will prevent application protocol data from being exchanged anyway. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: about the sequence number field
Those were great replies. Thanks Lev and Geoff. Guess I'll have to put more thought into this. Thanks again, swami On Wed, 19 Nov 2003, Geoff Thorpe wrote: On November 19, 2003 07:16 pm, Swaminathan P wrote: I have a question anout the use of sequence number as a part of the input to the hash function during the MAC calculation. Does that security concerns? Would the security aspects of theSSL be affected if the sequence number is not used as a part of the input to the hash funtion for MAC calculation? As Les pointed out, this helps detect replay (or removal) attacks. It also forces the underlying transport to be reliable and ordered, so that the SSL/TLS encapsulation in turn presents what appears to be a reliable and ordered channel to the user of the protocol. For example, it doesn't stop you trying to run SSL/TLS over something like UDP that does not these sorts of guarantees, but this aspect of the SSL/TLS protocol will allow you to detect (in theory) if the packets arrive out of order or don't turn up at all. It will not *recover* from such problems though, so this sequence number trick is simply to verify reliability of the transport, without providing any recovery mechanism if the ordering and reliability assumptions aren't met. But there's two far more fundamental problems with trying to bypass this ordering issue anyway. (1) the ciphering used to en/decrypt the payloads of SSL/TLS records (after the initial handshake has agreed parameters) is typically stateful, so if you get records duplicated, removed, or out-of-order, then en/decryption will start misreading all subsequent records as senseless noise. (2) during a handshake or a renegotiation, the finished messages use MAC calculations over *all* the previous handshake messages *in order*. Note that all and in order mean that if you lose reliability during the handshake or renegotiation phase, you get the SSL/TLS equivalent of a carrier disconnect - no amount of sequencing logic in the application protocol will matter as this corruption in the handshake protocol will prevent application protocol data from being exchanged anyway. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ __ 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]
