Re: [openssl.org #1894] [patch] typos / linguistic bugs in docs/comments
Steven M. Schweda wrote: From: Ger Hobbelt g...@hobbelt.com On Thu, Apr 9, 2009 at 6:42 PM, Ted Mittelstaedt t...@toybox.placo.com wrote: Here is a patch to your patch: [...] plural, not possessive. Thanks for the correction. It's appreciated! Hey. Don't give up so easily. While it's possible to find backing for almost any opinion involving an apostrophe, a rule like plural, not possessive is much too simple to be reliable. It wasn't a rule, it was a guideline. However, the sentence: The no's resounded loudlycan be read either as possessive or plural, although if your indicating possessive I think the proper thing would be to capitalize, as such: The No's resounded loudly Frankly it's a terrible example sentence whatever you mean because if spoken out loud, it sounds like nose as in snot, so the image is of a chamber full of people blowing their noses. The original lines in the patch are a bit different as neither can really be read as possessive. As for word used as a word I'll leave you to ponder the meaninglessness of that phrase. It's definitely not in common usage. However, whatever you end up deciding, it needs to be consistent among the entire text - if your going to do this word used as a word thing, you better check the rest of the text. Everything's complicated. Trust no one. Especially not a native English speaker. As Count Aristid Karpathy once said, The English do not know how to speak their own language. Only foreigners who have been taught to speak it speak it well. Well, nobody has really explained why the shift from Olde English ever happened with any degree of believability, which is why that joke is apropos. Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1894] [patch] typos / linguistic bugs in docs/comments
Ger Hobbelt via RT wrote: Simple stuff, but best to get this out of the way finally. Patch file included, of course. Here is a patch to your patch: +* any floating point printf's. +will automatically add new session-id's to the cache upon successful are supposed to be: +* any floating point printfs. +will automatically add new session-ids to the cache upon successful plural, not possessive. Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0 beta 1 released - build fail on Solaris 2.5.1
Andy Polyakov wrote: There are trivial differences between Solaris 2.5.1 and the later Solaris versions. Not enough to cause a build problem. So if it's busted on 2.5.1 it will be busted on 2.6, 2.7 etc. Newer Solaris version *are* equipped with newer assembler, which *does* support more x86 instructions, such as those used in wp-mmx module. Plus, that illegal mnemonic error has happened before and been corrected before in openssl. You must be referring to illegal mnemonic mentioned in Configure in Solaris x86 with GNU C setups section. For completeness sake it should be noted that newer GNU C versions (or one(s) provided by Sun?) do not exhibit this behavior and it's perfectly possible to compile without NO_INLINE_ASM. In other words, failure to compile on Solaris 2.5.1 and gcc 2.95.3 does not necessarily mean that it shall fail to compile on later versions. I mean the opening statement does not hold true:-) Finally, compilation with no-asm means NO ASSEMBLY, NONE, NADA!!! While you might be able to argue obsolescense on the first compile, the second compile with no-asm defined shouldn't have errored. Correct, it shouldn't have failed. In other words this is bug. http://cvs.openssl.org/chngview?cn=17985 is the cure. Obviously, whoever coded wp-mmx wasn't paying attention to -DOPENSSL_NO_INLINE_ASM. Not to mention the larger question of why wp-mmx was even selected - not all Intel chips HAVE mmx instructions. What does pure assembler wp-mmx have to do with NO_INLINE_ASM? In either case, MMX capability is detected at run-time and whirlpool_block_mmx is *not* invoked on CPU not capable to execute it. This naturally implies that there *is* equivalent non-mmx code. This applies to all MMX/SSE/SSE2 modules. This is totally intentional, i.e. this is not a bug. One can argue that there should be a way to selectively disable strange modules [for impaired assemblers' sake], but where would one draw the line? This is more of rhetorical question, because as long as no-asm does the trick, the line is drawn right there. If you're not satisfied with this all-or-nothing option, feel free to remove wp_block.o wp-mmx.o from $x86_asm in Configure. Or install GNU binutils (so that you get more up-to-date assembler) and reconfigure compiler to use GNU assembler and not Solaris one... A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org Hi All! It's building now, but I'm getting a few messages from netdb.h like the following: gcc -I.. -I../.. -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -c b_sock.c In file included from ../../e_os.h:570, from ../cryptlib.h:65, from b_sock.c:63: /usr/include/netdb.h:195: warning: `struct sockaddr_in' declared inside parameter list /usr/include/netdb.h:195: warning: its scope is only this definition or declaration, which is probably not what you want. gcc -I.. -I../.. -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -c bss_acpt.c In file included from ../../e_os.h:570, from ../cryptlib.h:65, from bss_acpt.c:62: /usr/include/netdb.h:195: warning: `struct sockaddr_in' declared inside parameter list /usr/include/netdb.h:195: warning: its scope is only this definition or declaration, which is probably not what you want. gcc -I.. -I../.. -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -c bss_dgram.c In file included from ../../e_os.h:570, from ../cryptlib.h:65, from bss_dgram.c:65: /usr/include/netdb.h:195: warning: `struct sockaddr_in' declared inside parameter list /usr/include/netdb.h:195: warning: its scope is only this definition or declaration, which is probably not what you want. Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0 beta 1 released - build fail on Solaris 2.5.1
Thor Lancelot Simon wrote: On Sun, Apr 05, 2009 at 09:40:36PM -0700, Ted Mittelstaedt wrote: This is from /openssl-SNAP-20090405 on Solaris x86 ver 2.5.1 using gcc 2.95.3: Ow! Solaris 2.5.1, and gcc2? Didn't Sun even finally end all support for Solaris 2.5? There are trivial differences between Solaris 2.5.1 and the later Solaris versions. Not enough to cause a build problem. So if it's busted on 2.5.1 it will be busted on 2.6, 2.7 etc. Plus, that illegal mnemonic error has happened before and been corrected before in openssl. Finally, compilation with no-asm means NO ASSEMBLY, NONE, NADA!!! While you might be able to argue obsolescense on the first compile, the second compile with no-asm defined shouldn't have errored. Obviously, whoever coded wp-mmx wasn't paying attention to -DOPENSSL_NO_INLINE_ASM. Not to mention the larger question of why wp-mmx was even selected - not all Intel chips HAVE mmx instructions. It's obviously a bug. Whether it's easy to fix or not I don't know. But clearly, if OpenSSL is going to decide to stop supporting things then it should be documented. OpenSSL 0.9.8j runs fine on this platform. Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0 beta 1 released - build fail on Solaris 2.5.1
Andy Polyakov wrote: There are trivial differences between Solaris 2.5.1 and the later Solaris versions. Not enough to cause a build problem. So if it's busted on 2.5.1 it will be busted on 2.6, 2.7 etc. Newer Solaris version *are* equipped with newer assembler, which *does* support more x86 instructions, such as those used in wp-mmx module. OK. Plus, that illegal mnemonic error has happened before and been corrected before in openssl. You must be referring to illegal mnemonic mentioned in Configure in Solaris x86 with GNU C setups section. For completeness sake it should be noted that newer GNU C versions (or one(s) provided by Sun?) do not exhibit this behavior and it's perfectly possible to compile without NO_INLINE_ASM. However, the newer gcc took out the hack to make assembler work with Sun's linker so there's another hack you have to do to get it to compile with gcc 3.x (it's documented in the FAQ for openssl I recall) In other words, failure to compile on Solaris 2.5.1 and gcc 2.95.3 does not necessarily mean that it shall fail to compile on later versions. I mean the opening statement does not hold true:-) OK, point taken. Obsolescense, then. Finally, compilation with no-asm means NO ASSEMBLY, NONE, NADA!!! While you might be able to argue obsolescense on the first compile, the second compile with no-asm defined shouldn't have errored. Correct, it shouldn't have failed. In other words this is bug. http://cvs.openssl.org/chngview?cn=17985 is the cure. Thanks! I'll try out tomorrow's snap and let you all know. Obviously, whoever coded wp-mmx wasn't paying attention to -DOPENSSL_NO_INLINE_ASM. Not to mention the larger question of why wp-mmx was even selected - not all Intel chips HAVE mmx instructions. What does pure assembler wp-mmx have to do with NO_INLINE_ASM? In either case, MMX capability is detected at run-time and whirlpool_block_mmx is *not* invoked on CPU not capable to execute it. This naturally implies that there *is* equivalent non-mmx code. This applies to all MMX/SSE/SSE2 modules. This is totally intentional, i.e. this is not a bug. One can argue that there should be a way to selectively disable strange modules [for impaired assemblers' sake], but where would one draw the line? This is more of rhetorical question, because as long as no-asm does the trick, the line is drawn right there. That does it for me - no-asm is just fine. Nobody would seriously use an obsolete platform to do a lot of intense crypto on, so the slower speed that no-asm introduces is not a problem. But lots of people would like to continue to update the ssh daemon on their obsolete platforms. If you're not satisfied with this all-or-nothing option, feel free to remove wp_block.o wp-mmx.o from $x86_asm in Configure. I might try that just to see what happens. Thanks! Ted Or install GNU binutils (so that you get more up-to-date assembler) and reconfigure compiler to use GNU assembler and not Solaris one... A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0 beta 1 released - build fail on Solaris 2.5.1
This is from /openssl-SNAP-20090405 on Solaris x86 ver 2.5.1 using gcc 2.95.3: gcc -I.. -I../.. -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DWHIRLPOOL_ASM -R/usr/local/lib:/usr/local/ssl/lib -c -o wp-mmx.o wp-mmx.s Assembler: wp-mmx.s aline 29: Illegal mnemonic aline 29: syntax error aline 29: Illegal register aline 30: Illegal mnemonic aline 30: syntax error aline 30: Illegal register aline 31: Illegal mnemonic aline 31: syntax error aline 31: Illegal register aline 32: Illegal mnemonic aline 32: syntax error aline 32: Illegal register aline 33: Illegal mnemonic aline 33: syntax error aline 33: Illegal register aline 34: Illegal mnemonic aline 34: syntax error aline 34: Illegal register aline 35: Illegal mnemonic aline 35: syntax error aline 35: Illegal register aline 36: Illegal mnemonic aline 36: syntax error aline 36: Illegal register aline 38: Illegal mnemonic aline 38: syntax error aline 38: Illegal register aline 39: Illegal mnemonic aline 39: syntax error aline 39: Illegal register aline 40: Illegal mnemonic Too many errors - Goodbye *** Error code 1 make: Fatal error: Command failed for target `wp-mmx.o' Current working directory /usr/home/tedm/openssl-SNAP-20090405/crypto/whrlpool *** Error code 1 make: Fatal error: Command failed for target `subdirs' Current working directory /usr/home/tedm/openssl-SNAP-20090405/crypto *** Error code 1 make: Fatal error: Command failed for target `build_crypto' I then tried it with the no-asm parameter to config and it got further but blew up here: gcc -I.. -I../.. -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -R/usr/local/lib:/usr/local/ssl/lib -c camellia.c Assembler: camellia.c aline 1067 : Illegal mnemonic aline 1067 : syntax error aline 1073 : Illegal mnemonic aline 1073 : syntax error aline 1079 : Illegal mnemonic aline 1079 : syntax error aline 1085 : Illegal mnemonic aline 1085 : syntax error aline 1092 : Illegal mnemonic aline 1092 : syntax error aline 1098 : Illegal mnemonic aline 1098 : syntax error aline 1117 : Illegal mnemonic aline 1117 : syntax error aline 1124 : Illegal mnemonic aline 1124 : syntax error aline 2155 : Illegal mnemonic aline 2155 : syntax error aline 2162 : Illegal mnemonic aline 2162 : syntax error aline 2169 : Illegal mnemonic aline 2169 : syntax error aline 2176 : Illegal mnemonic aline 2176 : syntax error aline 2518 : Illegal mnemonic aline 2518 : syntax error aline 2525 : Illegal mnemonic aline 2525 : syntax error aline 2530 : Illegal mnemonic aline 2530 : syntax error aline 2535 : Illegal mnemonic Too many errors - Goodbye *** Error code 1 make: Fatal error: Command failed for target `camellia.o' Current working directory /usr/home/tedm/openssl-SNAP-20090405/crypto/camellia *** Error code 1 make: Fatal error: Command failed for target `subdirs' Current working directory /usr/home/tedm/openssl-SNAP-20090405/crypto *** Error code 1 make: Fatal error: Command failed for target `build_crypto' # Ted OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.0 Beta 1 OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL is currently in a release cycle. The first beta is now released. The beta release is available for download via HTTP and FTP from the following master locations (the various FTP mirrors you can find under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The file names of the beta are: o openssl-1.0.0-beta1.tar.gz MD5 checksum: 49f265d9dd8dc011788b34768f63313e SHA1 checksum: 89b4490b6091b496042b5fe9a2c8a9015326e446
make test fails with OpenSSL 0.9.8i, works fine on same machine with 0.9.8h, guessing BN_GF2m_mod_arr() change botched?
Hi All, I have a Solaris 2.5.1 system with all current patches. I built OpenSSL 0.9.8i with the command: ./config shared -L/usr/local/lib then edited Makefile and add -R/usr/local/lib:/usr/local/ssl/lib to CFLAG line then make The build completes without errors. make test I get the following error partway through: . . . test BN_GF2m_mod_sqr test BN_GF2m_mod_inv test BN_GF2m_mod_div test BN_GF2m_mod_exp test BN_GF2m_mod_sqrt test BN_GF2m_mod_solve_quad running bc .. Failed! bc: -D726C354EAF4B1B00A96E3C861DC288D7F6A690A3F172826EE21AD9833F0F81A75859\ *** Error code 255 make: Fatal error: Command failed for target `test_bn' Current working directory /home/openssl-0.9.8i/test *** Error code 1 make: Fatal error: Command failed for target `tests' # Broken Pipe Building and testing OpenSSL 0.9.8h on the same machine works fine. This is gcc 2.95.3 I noticed in the CHANGES between 0.9.8h and 0.9.8i: *) Fix BN_GF2m_mod_arr() top-bit cleanup code. [Huang Ying] Here is the change that was made: # diff -c /home/openssl-0.9.8h/crypto/bn/bn_gf2m.c /home/openssl-0.9.8i/crypto/bn/bn_gf2m.c *** /home/openssl-0.9.8h/crypto/bn/bn_gf2m.cWed Feb 8 11:16:11 2006 --- /home/openssl-0.9.8i/crypto/bn/bn_gf2m.cMon Jun 23 13:46:28 2008 *** *** 384,390 if (zz == 0) break; d1 = BN_BITS2 - d0; ! if (d0) z[dN] = (z[dN] d1) d1; /* clear up the top d1 bits */ z[0] ^= zz; /* reduction t^0 component */ for (k = 1; p[k] != 0; k++) --- 384,394 if (zz == 0) break; d1 = BN_BITS2 - d0; ! /* clear up the top d1 bits */ ! if (d0) ! z[dN] = (z[dN] d1) d1; ! else ! z[dN] = 0; z[0] ^= zz; /* reduction t^0 component */ for (k = 1; p[k] != 0; k++) # Is this correct for big endian platforms? Please no comments from the peanut gallery about how old the platform is and how everyone should be running lynucks on a peecee... Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Install openssl-0.9.8g on a Mac OS X PPC server
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Zhao, Wenzhong, Dr
{Zhao}(GSFC-613.2)[SSAI]
Sent: Monday, March 03, 2008 7:52 PM
To: openssl-dev@openssl.org
Cc: [EMAIL PROTECTED]
Subject: Install openssl-0.9.8g on a Mac OS X PPC server
Hi,
My question is:
How can I generate a loadable library module libssl.so of openssl-0.9.8g
on a Mac OS X 10.4.11 PPC server?
I need to install openssl-0.9.8g on a Mac OS X 10.4.11 PPC server. This
update is required for web server apache-1.3.33.
I used the following commands to compile and install:
Configure shared darwin-ppc-cc
make
make test
make install
All these commands successfully finished. However, I got libssl.a and
libssl.dylib
That's what your supposed to get.
but did not get libssl.so. I made a symbolic link from
libssl.dylib to libssl.so.
That will not work.
Unfortunately, apache web server daemon
could not start if loading libssl.dylib is specified. How can I fix
this problem?
For starters, MacOS X uses .dylib as it's shared library extension,
it does not use .so as the shared library extension. The runtime
linker looks for libssl.dylib, not libssl.so.
The biggest problems with compiling shared libraries on MacOS X,
frankly, is dealing with Borgified makefiles and hacked-up
configure scripts that insist on spitting out .so libraries
under MacOS X. OpenSSL is doing the right thing, you are not.
There is one other twist to using shared libraries under MacOS X
and that has to do with locating them. With most unixes, you
dictate shared library location in 1 of two ways. You either use
the -R directive during the link phase of the final executable
to pass a runtime link path to the executable, or you modify
a configuration file that the runtime linker looks at to find
paths of all the locations it's supposed to look for dynamic
libraries.
With MacOS X up to 10.4, what you do is you brand the name of
where the dynamic library will be located into the dynamic library
itself during link phase - that is, either a complete path
including library name, or a path including library name relative
to where the executable is. There is none of this nonsense of
passing search paths, the runtime linker does not have the
ability to search paths for libraries. During the link phase
of the executable, the linker takes the full pathname from
each library that is linked in, and puts it into the executable.
With MacOS X 10.5, they finally came into the modern age and
allow you to pass a search path to the executable.
Frankly, you need to look into the Fink project, it sounds like
you do not have enough experience porting software on MacOS X
to be able to make a successful port here - you really should
start your porting efforts on MacOS X with something a lot
smaller and simpler than OpenSSL. Very
few open source projects out there have makefiles that understand
MacOS X, particularly the older versions. There are compiler
options that are missing in the gcc supplied from Apple that
you use special techniques to work around. It can become rather
tideous at times, and when I'm doing a quick testing project I
will often dispense with dynalibs and compile everything static
just to make sure it is going to work first.
This of course sets aside all of the issues with the PPC architecture
which is big-endian, and the intel architecture that's little-endian.
And there is also the issue with you can create a universal binary
that runs on both PPC and intel.
The fink project has most of these packages precompiled anyway so
you don't have to bother building them. See http://www.finkproject.org/
They even have openssl, although it's older.
If you must build it, at least see how they built the 0.9.7
package:
http://pdb.finkproject.org/pdb/package.php/openssl097
Ted
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
RE: rfc 4279 support - what's the plan?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Scott Kelly Sent: Monday, June 19, 2006 10:26 AM To: openssl-dev@openssl.org Subject: rfc 4279 support - what's the plan? Last August some folks from Nokia posted a patch for 0.9.8a that implements a portion of tls-psk. I applied this patch, and also extended it to allow preshared keys with dtls. I was hoping to see rfc4279 support in 0.9.8b, but it's not there. What's the plan for preshared key support in openssl (or is there no plan as of yet)? Gee Scott, we thought you volunteered to write it! Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Any possibility of GPL-based license in the future?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Howard Chu Sent: Tuesday, May 16, 2006 4:58 PM To: openssl-dev@openssl.org Cc: Bob Beck Subject: Re: Any possibility of GPL-based license in the future? Sometimes the fact that the main source moves onward is irrelevant. If Revision X of a package does what they need, they can take it and never look back. This has happened quite often; it's no GPL-sponsored lie. But then they are 'competing' against the main BSD source - if that source is continued to be maintained, that is. For example Apple forked Darwin off of FreeBSD 3.2 and mixed in Next code. Well, today FreeBSD 6.X is much more advanced than Darwin is, so because Apple elected not to stay synced with FreeBSD, they have lost out on all the improvements since 3.2 I would say that given a choice, FBSD 6.1 wins hands down against MacOS X. (if you have ever tried building any of the major OSS packages under MacOS X you will quickly agree!) Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Any possibility of GPL-based license in the future?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeffrey Altman Sent: Tuesday, May 16, 2006 2:03 PM To: openssl-dev@openssl.org Cc: Bob Beck; [EMAIL PROTECTED] Subject: Re: Any possibility of GPL-based license in the future? It is impossible for OpenSSL to dual license under the GPL. The current maintainers of OpenSSL do not have the rights to alter the license to the code derived from the original SSLeay contribution. Therefore, they cannot add a new license to code derived from the original contribution. This is the end of the story. Note, there is nothing in the OpenSSL license that prevents it from being distributed in source form. You can of course dual license your source code and ship it with a license that can be used when linked to OpenSSL. For those who must use GPL, they can choose to link against GnuTLS. Jeffrey, Strictly speaking, the viral effects of the GPL only come into force when your redistributing. It is entirely possible to distribute a GPL version of your code, the OpenSSL-licensed version of your code, along with instructions to the end user on how to compile and link both together, and not be in violation of either license. Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [PATCH] Remove old libdes support?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Kurt Roeckx Sent: Monday, March 13, 2006 1:15 PM To: openssl-dev@openssl.org Subject: [PATCH] Remove old libdes support? Hi, Various places in the source say that old des support is going to be removed before 1.0. I think it's time to move forward. What if others don't? I think we have 2 options: - Completly drop the old des support, including des_old.h - Drop the libdes compatibility, so that it's only compatible with older openssl versions, and people can still use the des_* versions. How about option 3 - change the default to not include it but leave the code still in there, then see how many people squawk about old des support missing and get told to set the flag to include it, then make a decision about stripping it out completely, based on that. Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Brian Long Sent: Tuesday, January 31, 2006 5:58 AM To: openssl-dev@openssl.org Subject: Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2) On Fri, 2006-01-27 at 15:23 +0100, Stephen Henson via RT wrote: [EMAIL PROTECTED] - Fri Jan 27 15:01:56 2006]: This patch is adding support for TLS hello extensions and externally generated pre-shared key material to OpenSSL 0.9.8. This is based on the patch from Alexey Kobozev [EMAIL PROTECTED] (sent to openssl-dev mailing list on Tue, 07 Jun 2005 15:40:58 +0300). Note that some TLS extension code has recently been committed to the HEAD (0.9.9-dev). So if this is to be included into OpenSSL it would have to work with that. Stephen, Is it true that openssl-0.9.7 and 0.9.8 are frozen with regards to features like TLS extensions? Do you expect vendors like Red Hat or Suse to include and support patches like TLS extensions on their own once they have standardized on a version of openssl for their enterprise products? For example, Red Hat Enterprise Linux 4 was released almost 1 year ago and includes 0.9.7a plus all the security patches issue over the last year. If I need the TLS extension patch officially supported by Red Hat, it would have to come from upstream -- your group -- or they would have to support it as a one-off patch. I was hoping your group would accept it, but it appears your efforts are concentrated on 0.9.9- dev. Brian, let me butt-in here if I may. The linux distribution managers for redhat, suse, and so on typically will use the same version of major packages like openssl, apache, sshd, and so on for every minor version release in that train. As you noted, RHEv4 came out with 0.9.7 I would expect newer minor releases of RHEv4 to come with newer 0.9.7 versions of openssl. I would expect that when RHEv5 comes out that it would use openssl version 0.9.8 Now, you want TLS support. So you have a choice: use RHEv4, delete their binary of openssl and all it's libraries, along with all dynamically linked binaries supplied in RHEv4 that are linked to the openssl libraries, compile the latest openssl that has TLS support, then recompile all the binaries that you need that are linked to this. Use RHE version -future meaning wait for some version of RHE to come out that supports TLS Use some minimal Linux distro that does not inclue any ssl-aware apps in it, and build the latest version of openssl with tls support, then build what ssl-aware apps you want. People use products like RHE because they want to pay someone for a binary linus distro that has a bunch of pre-rolled programs in it, rolled to some fixed, supportable definition. People that do this are happy to pay RH to patch their RHE v4 to get features they want, which I think is where your TLS patches might be useful. But, how RH does it, which incidentally is how the traditional major UNIX vendors do it (like Sun) isn't how the Open Source community does it. The open source community wants people like you, who are willing to do the work, to put their efforts into the current code. The features you put into the current code will eventually percolate down to packagers like RH and their customers. But, you should not be concerned with what RH is doing. If RH wants to take TLS support from the latest rev of openSSL and back-port it to RHE v4, that is their problem. You are making it your problem, and you need to know that this is going to be wasted effort. The OpenSSL developers cannot use your effort, because your working with old code, and the RH people don't have customers demanding TLS support in RHE v4, and so they aren't going to be interested in your patches either. Most likely, if RH did get a bunch of customers wanting TLS, they would put their development effort into putting TLS into the next version of RHE, then tell all their customers to spend money to upgrade to the new version of RHE. It is not to the open source communitites benefit to have the opensssl developers spend a lot of time back-porting new features to old openssl distros. It always distresses me when I see a cool feature patched into older open source code, because I know it's a dead end. I learned this myself a few years ago when I spent a lot of effort porting ancient patches to the mt command that supported moving the tape to a specific block number. Unfortunately I stupidly worked with production, not development code, so when I finally got it all working, the development code had so changed in that code section, all my effort was wasted also. Eventually someone did put that support into mt, a few years later, fortunately, but not using any of my work. Anyway, I hope that you do take a look at the current openssl development code and see if anything you worked on can be used there. Ted __ OpenSSL Project
RE: [openssl.org #1190] bug report
Sam, What happens when you put the directive no-asm for config? Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of sharma via RT Sent: Tuesday, November 01, 2005 11:31 AM Cc: openssl-dev@openssl.org Subject: RE: [openssl.org #1190] bug report Hi The latest code crashes on Solaris Intel 5.8, this is the log output of compilation. making all in engines... gmake[4]: Entering directory `/home/srbpkg/srbpkg/ssl/32/openssl-0.9.8a/engines' gmake[4]: Nothing to be done for `all'. gmake[4]: Leaving directory `/home/srbpkg/srbpkg/ssl/32/openssl-0.9.8a/engines' making all in apps... gmake[4]: Entering directory `/home/srbpkg/srbpkg/ssl/32/openssl-0.9.8a/apps' gmake[4]: Nothing to be done for `all'. gmake[4]: Leaving directory `/home/srbpkg/srbpkg/ssl/32/openssl-0.9.8a/apps' making all in test... gmake[4]: Entering directory `/home/srbpkg/srbpkg/ssl/32/openssl-0.9.8a/test' gmake[4]: Nothing to be done for `all'. gmake[4]: Leaving directory `/home/srbpkg/srbpkg/ssl/32/openssl-0.9.8a/test' making all in tools... gmake[4]: Entering directory `/home/srbpkg/srbpkg/ssl/32/openssl-0.9.8a/tools' gmake[4]: Nothing to be done for `all'. gmake[4]: Leaving directory `/home/srbpkg/srbpkg/ssl/32/openssl-0.9.8a/tools' gmake[3]: Leaving directory `/home/srbpkg/srbpkg/ssl/32/openssl-0.9.8a' ../util/shlib_wrap.sh ./destest gmake[2]: *** [test_des] Segmentation Fault (core dumped) gmake[2]: Leaving directory `/home/srbpkg/srbpkg/ssl/32/openssl-0.9.8a/test' gmake[1]: *** [tests] Error 2 gmake[1]: Leaving directory `/home/srbpkg/srbpkg/ssl/32/openssl-0.9.8a' gmake: [ssl32] Error 2 (ignored) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Polyakov via RT Sent: Tuesday, September 20, 2005 12:32 AM To: [EMAIL PROTECTED] Cc: openssl-dev@openssl.org Subject: Re: [openssl.org #1190] bug report The ssl 9.8 compilation using 'config' or 'Configure no-sse2' on solaris intel gives segment violation. Incase you would like to know more information, let me know what file to send to you. The segment violation problem is documented in ./PROBLEMS file, Bugs in gcc triggered section, and there are explicit instructions on how to collect data in ./README file. Homework is always appreciated. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.6/152 - Release Date: 10/31/2005 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1223] make test fails on some systems in 0.9.8a
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andy Polyakov Sent: Tuesday, October 18, 2005 5:23 AM To: openssl-dev@openssl.org Cc: [EMAIL PROTECTED] Subject: Re: [openssl.org #1223] make test fails on some systems in 0.9.8a Give it up, the developers aren't interested. I posted a core dump under Solaris and nobody cared enough to look at it. Somebody is not reading e-mail. The question was answered with '[see] ./PROBLEMS, triggered gcc bugs [section].' My bad, then. I did not see that. Seriously! Mea Culpa, I do apologize. I am pretty sure they know what the hell is going on. Anything special/subtle/uncommon we know is usually documented in ./PROBLEMS or ./FAQ depending on how often problem is encountered! The Solaris 8 issue is NOT in the FAQ. Yes, it is in PROBLEMS in 0.9.8 - after you mentioned this I looked at it again and saw the values.c thing. But the answer there is to recompile gcc with values.c HOWEVER I respectfully submit that is is bogus crapola. This should be handled by the configure script, that is why you have it. The entire point of the configure script is to fixup stuff like this. Configure should build a small test program that checks for the Solaris linker bug and if it seg faults then it should put in the no-asm and spit out a message to the effect to patch the compiler or tell the GCC people to fix their compiler. Just my opinion!!! Nothing in PROBLEMS talks about compiling with no-asm as a workaround. 0.9.8a obviously makes use of some go-fast supercalifragelistic code that 0.9.7 avoids. I'm sure the developers are more enamoured of this fancy code than of getting 0.9.8 to compile reliably. All supercalifragelistic code can be switched off with no-asm. It's your choice, and if you're so upset about 0.9.8 being more modern, just configure with no-asm. I'm just bugged that this isn't more documented. The problem with Solaris is that since it ships with no compiler everyone has to download a precompiled binary of gcc. Since these binaries don't have the value.c patch, openssl 0.9.8 compilation is going to blow chunks on a large majority of solaris systems. Not that I'm complaining but the FAQ has a entry for Alpha Tru64 and your going to tell me that is larger deployed base than Solaris x86!! There's a good chance that your problem, like mine, would be solved by completely recompiling gcc, *Both* problems *are* documented in ./PROBLEMS. His problem can be resolved by upgrading binutils. OpenSSL was the -only- source that required the compiler to be recompiled. Not if you configured with no-asm. NOT documented in the PROBLEMS document in the paragraph that talks about the Solaris linker bug. Now back to the beginning. developers are not interested. Well, no, I'm not interested to say see accompanying documentation over and over again Then move some of the stuff out of PROBLEMS and into the FAQ. Or at least put a FAQ question in the FAQ that tells people to read the PROBLEMS document. and you're not in position to blaim me, as I do it in my spare time. I see your not married, then. ;-) Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1222] Please introduce versioned symbols
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Richard Levitte - VMS Whacker via RT Sent: Monday, October 17, 2005 5:14 AM To: [EMAIL PROTECTED] Cc: openssl-dev@openssl.org Subject: Re: [openssl.org #1222] Please introduce versioned symbols [Additional note to get the proposal itself into this ticket's history] From: Christoph Martin [EMAIL PROTECTED] Date: Thu, 13 Oct 2005 23:24:58 +0200 Subject: Proposal for symbol versioning of openssl Hi folks, openssl has evolved to a very important library in Linux distribution. A lot of cryptographic applications link to it including system libraries like pam modules and apache modules. Now it becomes more and more difficult to get all the binaries and libraries to link to the same version of openssl. Why is that? Do some applications not link to openssl 0.9.7? Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Problem with OpenSSL on Solaris x86 *
Hi All,
OpenSSL builds but fails tests. Here's the particulars:
Freshly installed and patched Solaris 8 x86 system
# gcc -v
Reading specs from /usr/local/lib/gcc/i386-pc-solaris2.8/3.4.2/specs
Configured with:
../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disabl
e-nls --disable-libgcj --enable-languages=c,c+ : (reconfigured)
../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disabl
e-nls --disable-libgcj --enable-languages=c,c++
Thread model: posix
gcc version 3.4.2
#
# uname -a
SunOS mail 5.8 Generic_117351-26 i86pc i386 i86pc
# pwd
/usr/home/downloads/openssl-0.9.8
# date
Tue Oct 4 04:48:33 PDT 2005
/dev/urandom and /dev/random are installed by Solaris patch
# ./config
Operating system: i86pc-whatever-solaris2
Configuring for solaris-x86-gcc
Configuring for solaris-x86-gcc
no-gmp [default] OPENSSL_NO_GMP (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-mdc2 [default] OPENSSL_NO_MDC2 (skip dir)
no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
no-shared [default]
no-sse2 [option]
no-zlib [default]
no-zlib-dynamic [default]
IsMK1MF=0
CC=gcc
CFLAG
=-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-fra
me-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPEN
SSL_BN_ASM_PART_WORDS -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
EX_LIBS =-lsocket -lnsl -ldl
CPUID_OBJ =x86cpuid-elf.o
BN_ASM=bn86-elf.o co86-elf.o
DES_ENC =dx86-elf.o yx86-elf.o
AES_ASM_OBJ =ax86-elf.o
BF_ENC=bx86-elf.o
CAST_ENC =cx86-elf.o
RC4_ENC =rx86-elf.o
RC5_ENC =r586-elf.o
MD5_OBJ_ASM =mx86-elf.o
SHA1_OBJ_ASM =sx86-elf.o
RMD160_OBJ_ASM=rm86-elf.o
PROCESSOR =
RANLIB=/usr/ccs/bin/ranlib
ARFLAGS =
PERL =/usr/bin/perl
THIRTY_TWO_BIT mode
DES_PTR used
DES_RISC1 used
DES_UNROLL used
BN_LLONG mode
RC4_INDEX mode
RC4_CHUNK is undefined
e_os2.h = include/openssl/e_os2.h
making links in crypto...
crypto.h = ../include/openssl/crypto.h
.
.
.
kssl.h = ../include/openssl/kssl.h
ssltest.c = ../test/ssltest.c
making links in engines...
making links in apps...
making links in test...
making links in tools...
generating dummy tests (if needed)...
Configured for solaris-x86-gcc.
#
make
.
.
.
make -f ../Makefile.shared -e \
APPNAME=openssl OBJECTS=openssl.o verify.o asn1pars.o req.o
dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o
crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o
genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o
s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o
pkcs8.o spkac.o smime.o rand.o engine.o ocsp.o prime.o \
LIBDEPS= $LIBRARIES -lsocket -lnsl -ldl \
link_app.${shlib_target}
( :;
LIBDEPS=${LIBDEPS:--L.. -lssl -L.. -lcrypto -lsocket -lnsl -ldl};
LDCMD=${LDCMD:-gcc};
LDFLAGS=${LDFLAGS:--DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLF
CN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_N
O_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DSHA1_ASM -DMD5_ASM -DRMD160_AS
M -DAES_ASM}; LIBPATH=`for x in $LIBDEPS; do if echo $x | grep '^ *-L'
/dev/null 21; then echo $x | sed -e 's/^ *-L//'; fi; done | uniq`;
LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`;
LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o
dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o
rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o
s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o
app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o
smime.o rand.o engine.o ocsp.o prime.o ${LIBDEPS} )
(cd ..; \
OPENSSL=`pwd`/util/opensslwrap.sh; export OPENSSL; \
/usr/bin/perl tools/c_rehash certs)
Doing certs
Segmentation Fault - core dumped
argena.pem = .0
Segmentation Fault - core dumped
WARNING: Skipping duplicate certificate argeng.pem
Segmentation Fault - core dumped
WARNING: Skipping duplicate certificate eng1.pem
Segmentation Fault - core dumped
WARNING: Skipping duplicate certificate eng2.pem
Segmentation Fault - core dumped
WARNING: Skipping duplicate certificate eng3.pem
Segmentation Fault - core dumped
WARNING: Skipping duplicate certificate eng4.pem
Segmentation Fault - core dumped
WARNING: Skipping duplicate certificate eng5.pem
Segmentation Fault - core dumped
WARNING: Skipping duplicate certificate RegTP-5R.pem
Segmentation Fault - core dumped
WARNING: Skipping duplicate certificate RegTP-6R.pem
Segmentation Fault - core dumped
WARNING: Skipping duplicate certificate thawteCb.pem
Segmentation Fault - core dumped
WARNING: Skipping duplicate certificate thawteCp.pem
Segmentation Fault - core dumped
WARNING: Skipping duplicate certificate wellsfgo.pem
Segmentation Fault - core dumped
WARNING: Skipping
RE: Problem with OpenSSL on Solaris x86 *
Completed. Core file is located ftp://sunrise.ipinc.net/openssl/core It was created in ~/openssl-0.9.8/certs Compilation options used were -g and -ggdb I don't have gdb on this system, if anyone could take a look at this I'd appreciate it. Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Geoff Thorpe Sent: Tuesday, October 04, 2005 9:17 AM To: openssl-users@openssl.org Subject: Re: Problem with OpenSSL on Solaris x86 * On October 4, 2005 08:00 am, Ted Mittelstaedt wrote: OpenSSL builds but fails tests. Here's the particulars: [snip] (cd ..; \ OPENSSL=`pwd`/util/opensslwrap.sh; export OPENSSL; \ /usr/bin/perl tools/c_rehash certs) Doing certs Segmentation Fault - core dumped argena.pem = .0 Segmentation Fault - core dumped WARNING: Skipping duplicate certificate argeng.pem Segmentation Fault - core dumped WARNING: Skipping duplicate certificate eng1.pem Segmentation Fault - core dumped WARNING: Skipping duplicate certificate eng2.pem [snip] As you're getting core-dumps, it would be instructive to use those to get a bracktrace. However I'd also mention that it would be more useful to rerun this with more debugging compiled-in. Eg. edit Makefile to remove the -O3 and add -g -ggdb3 or something like that, than make clean make. Then if you still get the problem, the core-dump will provide a more useful backtrace. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ Même ceux qui se sentent pas des nôtres, ne nous voyant plus à genoux, seront, plus que jamais, chez eux chez nous. -- Loco Locass __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.9/116 - Release Date: 9/30/2005 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1190] bug report
Use ./config not ./Configure or put in the no-sse2 option yourself. Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of sharma via RT Sent: Friday, August 19, 2005 7:31 AM Cc: openssl-dev@openssl.org Subject: [openssl.org #1190] bug report Hi I am trying to compile openssl 9.8 on Solaris x86 8.0. openssl 9.7 used to compile without any problems. Let me know any thing else you like to know about my system. Uname -a: SunOS p125236 5.8 Generic_117351-21 i86pc i386 i86pc GCC -version: gcc (GCC) 3.4.2 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. OPENSSL CONFIG: ./Configure --openssldir=$(PKG_32BIT_INSTALL_DIR) solaris-x86-gcc I get the following error: gcc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -c -o x86cpuid-elf.o x86cpuid-elf.s Assembler: x86cpuid.s x86cpuid-elf.s, line 132 : Syntax error x86cpuid-elf.s, line 133 : Syntax error x86cpuid-elf.s, line 134 : Syntax error x86cpuid-elf.s, line 135 : Syntax error x86cpuid-elf.s, line 136 : Syntax error x86cpuid-elf.s, line 137 : Syntax error x86cpuid-elf.s, line 138 : Syntax error x86cpuid-elf.s, line 139 : Syntax error gmake[2]: *** [x86cpuid-elf.o] Error 1 The contents of the x86cpuid-elf.s from 132 to 139 lines are: pxor%xmm0, %xmm0 pxor%xmm1, %xmm1 pxor%xmm2, %xmm2 pxor%xmm3, %xmm3 pxor%xmm4, %xmm4 pxor%xmm5, %xmm5 pxor%xmm6, %xmm6 pxor%xmm7, %xmm7 Thanks SAM SHARMA __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.13/78 - Release Date: 8/19/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.13/78 - Release Date: 8/19/2005 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1146] [BUG] Segfault on FreeBSD 4.8-RELEASE #0
Hi All, I just checked this against my own FreeBSD 4.8 system and got the exact same segfault. This was with SNAP-20050704 I'll try FreeBSD 4.11 next. Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dmitry Belyavsky via RT Sent: Monday, July 04, 2005 1:30 AM Cc: openssl-dev@openssl.org Subject: [openssl.org #1146] [BUG] Segfault on FreeBSD 4.8-RELEASE #0 Hello! I've found a SEGFAULT using FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 in bntest. Build is configured with ./Configure -ggdb BSD-x86-elf shared zlib make report: = OpenSSL self-test report: OpenSSL version: 0.9.8-beta7-dev Last change: Correct naming of the 'chil' and '4758cca' ENGINEs. Thi... Options: -ggdb enable-shared enable-zlib no-gmp no-krb5 no-mdc2 no-rc5 no-zlib-dynamic OS (uname): FreeBSD ibex.lan.cryptocom.ru 4.8-RELEASE FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 OS (config): i386-pc-freebsd4.8 Target (default): BSD-x86-elf Target: BSD-x86-elf Compiler: Using builtin specs. gcc version 2.95.4 20020320 [FreeBSD] Failure! [...] == Test output is: Starting big number library test, could take a while... test BN_add test BN_sub test BN_lshift1 test BN_lshift (fixed) test BN_lshift test BN_rshift1 test BN_rshift test BN_sqr Segmentation fault (core dumped) *** Error code 139 == Backtrace is: (gdb) bt #0 0x281330a1 in bn_mul_add_words () from ./libcrypto.so.0.9.8 #1 0x0806038c in ?? () #2 0x28133009 in bn_sqr_normal (r=0x282966c4, a=0x24, n=37, tmp=0x28132c51) at bn_sqr.c:182 #3 0x28132c51 in BN_sqr (r=0x805578c, a=0x28066000, ctx=0x28132abc) at bn_sqr.c:132 #4 0x0804b58f in test_sqr (bp=0x80610c0, ctx=0x8061080) at bntest.c:691 #5 0x08049d14 in main (argc=671421537, argv=0xbfbffb24) at bntest.c:215 Thank you! -- SY, Dmitry Belyavsky (ICQ UIN 6575) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Compilation of openssl-0.9.8-stable-SNAP-20050624 fails on Solaris 2.5.1 x86
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andy Polyakov Sent: Sunday, June 26, 2005 9:35 AM To: openssl-dev@openssl.org Cc: openssl-users@openssl.org Subject: Re: Compilation of openssl-0.9.8-stable-SNAP-20050624 fails on Solaris 2.5.1 x86 I have another question on this build, config puts in -march=i486 but, shouldn't we be using -march=pentium The reason I ask is I see a lot of files that appear to be specific for the Pentium or later CPU - will these execute on a 80486? Yes, they will. -586 is legacy suffix and denotes the fact that instructions were originally *scheduled* in Pentium favor. But it doesn't [and never did] mean that the code would be executable exclusively on Pentium. It should be pointed out:-) that if anybody should raise a concern about 486 compatibility, then it shouldn't be a Solaris x86 user, because Pentium was always minimum requirement (as far as I recall:-). I have a 80486DX with vesa local bus video card running Solaris x86 version 2.5.1 just fine. It is incredibly slow as you might guess but I keep it around in case I might ever need it for compatability testing. Many of the video cards listed as Sun-approved for Solaris 2.5.1 were VLB cards, and I can't recall that there ever was a VLB chipset for the Pentium. This is why it's indeed more appropriate to use -march=pentium on Solaris x86, but not because of -586 suffix in assembler module names. A. Thanks! Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Compilation of openssl-0.9.8-stable-SNAP-20050624 fails on Solaris 2.5.1 x86
Thanks, Andy! It builds now. And make test completes without errors. I have another question on this build, config puts in -march=i486 but, shouldn't we be using -march=pentium The reason I ask is I see a lot of files that appear to be specific for the Pentium or later CPU - will these execute on a 80486? ./openssl-0.9.8-stable-SNAP-20050624/crypto/aes/asm/aes-586.pl ./openssl-0.9.8-stable-SNAP-20050624/crypto/bf/asm/bf-586.pl ./openssl-0.9.8-stable-SNAP-20050624/crypto/bn/asm/bn-586.pl ./openssl-0.9.8-stable-SNAP-20050624/crypto/bn/asm/co-586.pl ./openssl-0.9.8-stable-SNAP-20050624/crypto/cast/asm/cast-586.pl ./openssl-0.9.8-stable-SNAP-20050624/crypto/des/asm/crypt586.pl ./openssl-0.9.8-stable-SNAP-20050624/crypto/des/asm/des-586.pl ./openssl-0.9.8-stable-SNAP-20050624/crypto/des/times/586-100.lnx ./openssl-0.9.8-stable-SNAP-20050624/crypto/md5/asm/md5-586.pl ./openssl-0.9.8-stable-SNAP-20050624/crypto/rc4/asm/rc4-586.pl ./openssl-0.9.8-stable-SNAP-20050624/crypto/rc5/asm/rc5-586.pl ./openssl-0.9.8-stable-SNAP-20050624/crypto/ripemd/asm/rmd-586.pl ./openssl-0.9.8-stable-SNAP-20050624/crypto/sha/asm/sha1-586.pl Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andy Polyakov Sent: Friday, June 24, 2005 9:38 AM To: openssl-dev@openssl.org Cc: openssl-users@openssl.org Subject: Re: Compilation of openssl-0.9.8-stable-SNAP-20050624 fails on Solaris 2.5.1 x86 gcc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHA VE_DLFCN_H -O3 -fomit-frame-pointer -march=i486 -Wall -DL_ENDIAN -DOPENSS L_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DSHA1_ASM -DMD5_ASM -DRMD160 _ASM -DAES_ASM -c -o x86cpuid-elf.o x86cpuid-elf.s Assembler: x86cpuid.s aline 131 : Illegal mnemonic aline 131 : syntax error *** Error code 1 make: Fatal error: Command failed for target `x86cpuid-elf.o' http://cvs.openssl.org/chngview?cn=14142. a. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Compilation of openssl-0.9.8-stable-SNAP-20050624 fails on Solaris 2.5.1 x86
OK it's still got a problem: # ./config Operating system: i86pc-whatever-solaris2 Configuring for solaris-x86-gcc Configuring for solaris-x86-gcc no-gmp [default] OPENSSL_NO_GMP (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-mdc2 [default] OPENSSL_NO_MDC2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-shared [default] no-sse2 [option] no-zlib [default] no-zlib-dynamic [default] IsMK1MF=0 CC=gcc CFLAG =-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-fra me-pointer -march=i486 -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL _BN_ASM_PART_WORDS -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM EX_LIBS =-lsocket -lnsl -ldl CPUID_OBJ =x86cpuid-elf.o BN_ASM=bn86-elf.o co86-elf.o DES_ENC =dx86-elf.o yx86-elf.o AES_ASM_OBJ =ax86-elf.o BF_ENC=bx86-elf.o CAST_ENC =cx86-elf.o RC4_ENC =rx86-elf.o RC5_ENC =r586-elf.o MD5_OBJ_ASM =mx86-elf.o SHA1_OBJ_ASM =sx86-elf.o RMD160_OBJ_ASM=rm86-elf.o PROCESSOR = RANLIB=/usr/ccs/bin/ranlib ARFLAGS = PERL =/usr/bin/perl THIRTY_TWO_BIT mode DES_PTR used DES_RISC1 used DES_UNROLL used BN_LLONG mode RC4_INDEX mode RC4_CHUNK is undefined created directory `include/openssl' e_os2.h = include/openssl/e_os2.h making links in crypto... crypto.h = ../include/openssl/crypto.h tmdiff.h = ../include/openssl/tmdiff.h opensslv.h = ../include/openssl/opensslv.h opensslconf.h = ../include/openssl/opensslconf.h ebcdic.h = ../include/openssl/ebcdic.h symhacks.h = ../include/openssl/symhacks.h ossl_typ.h = ../include/openssl/ossl_typ.h making links in crypto/objects... objects.h = ../../include/openssl/objects.h obj_mac.h = ../../include/openssl/obj_mac.h making links in crypto/md2... md2.h = ../../include/openssl/md2.h md2test.c = ../../test/md2test.c making links in crypto/md4... md4.h = ../../include/openssl/md4.h md4test.c = ../../test/md4test.c md4.c = ../../apps/md4.c making links in crypto/md5... md5.h = ../../include/openssl/md5.h md5test.c = ../../test/md5test.c making links in crypto/sha... sha.h = ../../include/openssl/sha.h shatest.c = ../../test/shatest.c sha1test.c = ../../test/sha1test.c sha256t.c = ../../test/sha256t.c sha512t.c = ../../test/sha512t.c making links in crypto/hmac... hmac.h = ../../include/openssl/hmac.h hmactest.c = ../../test/hmactest.c making links in crypto/ripemd... ripemd.h = ../../include/openssl/ripemd.h rmdtest.c = ../../test/rmdtest.c making links in crypto/des... des.h = ../../include/openssl/des.h des_old.h = ../../include/openssl/des_old.h destest.c = ../../test/destest.c making links in crypto/aes... aes.h = ../../include/openssl/aes.h making links in crypto/rc2... rc2.h = ../../include/openssl/rc2.h rc2test.c = ../../test/rc2test.c making links in crypto/rc4... rc4.h = ../../include/openssl/rc4.h rc4test.c = ../../test/rc4test.c making links in crypto/idea... idea.h = ../../include/openssl/idea.h ideatest.c = ../../test/ideatest.c making links in crypto/bf... blowfish.h = ../../include/openssl/blowfish.h bftest.c = ../../test/bftest.c making links in crypto/cast... cast.h = ../../include/openssl/cast.h casttest.c = ../../test/casttest.c making links in crypto/bn... bn.h = ../../include/openssl/bn.h bntest.c = ../../test/bntest.c exptest.c = ../../test/exptest.c making links in crypto/ec... ec.h = ../../include/openssl/ec.h ectest.c = ../../test/ectest.c making links in crypto/rsa... rsa.h = ../../include/openssl/rsa.h rsa_test.c = ../../test/rsa_test.c making links in crypto/dsa... dsa.h = ../../include/openssl/dsa.h dsatest.c = ../../test/dsatest.c making links in crypto/ecdsa... ecdsa.h = ../../include/openssl/ecdsa.h ecdsatest.c = ../../test/ecdsatest.c making links in crypto/dh... dh.h = ../../include/openssl/dh.h dhtest.c = ../../test/dhtest.c making links in crypto/ecdh... ecdh.h = ../../include/openssl/ecdh.h ecdhtest.c = ../../test/ecdhtest.c making links in crypto/dso... dso.h = ../../include/openssl/dso.h making links in crypto/engine... engine.h = ../../include/openssl/engine.h enginetest.c = ../../test/enginetest.c making links in crypto/buffer... buffer.h = ../../include/openssl/buffer.h making links in crypto/bio... bio.h = ../../include/openssl/bio.h making links in crypto/stack... stack.h = ../../include/openssl/stack.h safestack.h = ../../include/openssl/safestack.h making links in crypto/lhash... lhash.h = ../../include/openssl/lhash.h making links in crypto/rand... rand.h = ../../include/openssl/rand.h randtest.c = ../../test/randtest.c making links in crypto/err... err.h = ../../include/openssl/err.h making links in crypto/evp... evp.h = ../../include/openssl/evp.h evp_test.c = ../../test/evp_test.c cp evptests.txt ../../test making links in crypto/asn1... asn1.h = ../../include/openssl/asn1.h asn1_mac.h = ../../include/openssl/asn1_mac.h asn1t.h = ../../include/openssl/asn1t.h making links in
Compilation of openssl-0.9.8-stable-SNAP-20050624 fails on Solaris 2.5.1 x86
# uname -a SunOS mail2 5.5.1 Generic_103641-42 i86pc i386 i86pc # gcc -v Reading specs from /usr/local/lib/gcc-lib/i586-sun-solaris2.5.1/2.95.3/specs gcc version 2.95.3 20010315 (release) # Hardware is a Pentium 66. (yes, an original Pentium) # ./Configure solaris-x86-gcc zlib shared -L/usr/local/lib Configuring for solaris-x86-gcc no-gmp [default] OPENSSL_NO_GMP (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-mdc2 [default] OPENSSL_NO_MDC2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-zlib-dynamic [default] IsMK1MF=0 CC=gcc CFLAG =-fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -D HAVE_DLFCN_H -O3 -fomit-frame-pointer -march=i486 -Wall -DL_ENDIAN -DOPEN SSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM EX_LIBS =-L/usr/local/lib -lsocket -lnsl -ldl -lz CPUID_OBJ =x86cpuid-elf.o BN_ASM=bn86-elf.o co86-elf.o DES_ENC =dx86-elf.o yx86-elf.o AES_ASM_OBJ =ax86-elf.o BF_ENC=bx86-elf.o CAST_ENC =c_enc.o RC4_ENC =rx86-elf.o RC5_ENC =r586-elf.o MD5_OBJ_ASM =mx86-elf.o SHA1_OBJ_ASM =sx86-elf.o s512sse2-elf.o RMD160_OBJ_ASM=rm86-elf.o PROCESSOR = RANLIB=/usr/ccs/bin/ranlib ARFLAGS = PERL =/usr/bin/perl THIRTY_TWO_BIT mode DES_PTR used DES_RISC1 used DES_UNROLL used BN_LLONG mode RC4_INDEX mode RC4_CHUNK is undefined created directory `include/openssl' e_os2.h = include/openssl/e_os2.h making links in crypto... crypto.h = ../include/openssl/crypto.h tmdiff.h = ../include/openssl/tmdiff.h opensslv.h = ../include/openssl/opensslv.h opensslconf.h = ../include/openssl/opensslconf.h ebcdic.h = ../include/openssl/ebcdic.h symhacks.h = ../include/openssl/symhacks.h ossl_typ.h = ../include/openssl/ossl_typ.h making links in crypto/objects... objects.h = ../../include/openssl/objects.h obj_mac.h = ../../include/openssl/obj_mac.h making links in crypto/md2... md2.h = ../../include/openssl/md2.h md2test.c = ../../test/md2test.c making links in crypto/md4... md4.h = ../../include/openssl/md4.h md4test.c = ../../test/md4test.c md4.c = ../../apps/md4.c making links in crypto/md5... md5.h = ../../include/openssl/md5.h md5test.c = ../../test/md5test.c making links in crypto/sha... sha.h = ../../include/openssl/sha.h shatest.c = ../../test/shatest.c sha1test.c = ../../test/sha1test.c sha256t.c = ../../test/sha256t.c sha512t.c = ../../test/sha512t.c making links in crypto/hmac... hmac.h = ../../include/openssl/hmac.h hmactest.c = ../../test/hmactest.c making links in crypto/ripemd... ripemd.h = ../../include/openssl/ripemd.h rmdtest.c = ../../test/rmdtest.c making links in crypto/des... des.h = ../../include/openssl/des.h des_old.h = ../../include/openssl/des_old.h destest.c = ../../test/destest.c making links in crypto/aes... aes.h = ../../include/openssl/aes.h making links in crypto/rc2... rc2.h = ../../include/openssl/rc2.h rc2test.c = ../../test/rc2test.c making links in crypto/rc4... rc4.h = ../../include/openssl/rc4.h rc4test.c = ../../test/rc4test.c making links in crypto/idea... idea.h = ../../include/openssl/idea.h ideatest.c = ../../test/ideatest.c making links in crypto/bf... blowfish.h = ../../include/openssl/blowfish.h bftest.c = ../../test/bftest.c making links in crypto/cast... cast.h = ../../include/openssl/cast.h casttest.c = ../../test/casttest.c making links in crypto/bn... bn.h = ../../include/openssl/bn.h bntest.c = ../../test/bntest.c exptest.c = ../../test/exptest.c making links in crypto/ec... ec.h = ../../include/openssl/ec.h ectest.c = ../../test/ectest.c making links in crypto/rsa... rsa.h = ../../include/openssl/rsa.h rsa_test.c = ../../test/rsa_test.c making links in crypto/dsa... dsa.h = ../../include/openssl/dsa.h dsatest.c = ../../test/dsatest.c making links in crypto/ecdsa... ecdsa.h = ../../include/openssl/ecdsa.h ecdsatest.c = ../../test/ecdsatest.c making links in crypto/dh... dh.h = ../../include/openssl/dh.h dhtest.c = ../../test/dhtest.c making links in crypto/ecdh... ecdh.h = ../../include/openssl/ecdh.h ecdhtest.c = ../../test/ecdhtest.c making links in crypto/dso... dso.h = ../../include/openssl/dso.h making links in crypto/engine... engine.h = ../../include/openssl/engine.h enginetest.c = ../../test/enginetest.c making links in crypto/buffer... buffer.h = ../../include/openssl/buffer.h making links in crypto/bio... bio.h = ../../include/openssl/bio.h making links in crypto/stack... stack.h = ../../include/openssl/stack.h safestack.h = ../../include/openssl/safestack.h making links in crypto/lhash... lhash.h = ../../include/openssl/lhash.h making links in crypto/rand... rand.h = ../../include/openssl/rand.h randtest.c = ../../test/randtest.c making links in crypto/err... err.h = ../../include/openssl/err.h making links in crypto/evp... evp.h = ../../include/openssl/evp.h evp_test.c = ../../test/evp_test.c cp evptests.txt
RE: When do we stop supporting old platforms?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tim Rice Sent: Monday, May 30, 2005 10:19 PM To: openssl-dev@openssl.org Subject: When do we stop supporting old platforms? I notice my OpenServer 3 box will not compile the 0.9.8 betas. ... [EMAIL PROTECTED] 13% make making all in crypto... sh[2]: 13003 Memory fault(coredump) *** Error code 1 [EMAIL PROTECTED] 14% gmake making all in crypto... gmake[1]: Entering directory `/usr/local/src/libs/openssl-0.9.8/crypto' ( echo #ifndef MK1MF_BUILD; \ echo ' /* auto-generated by crypto/Makefile for crypto/cversion.c */'; \ echo ' #define CFLAGS gcc -O3 -fomit-frame-pointer -Dssize_t=int -DNO_SYS_UN_H'; \ echo ' #define PLATFORM sco3-gcc'; \ echo #define DATE \`LC_ALL=C LC_TIME=C date`\; \ echo '#endif' ) buildinf.h gmake[1]: execvp: /bin/sh: Arg list too long What version of gmake are you running here? gmake[1]: *** [buildinf.h] Error 127 gmake[1]: Leaving directory `/usr/local/src/libs/openssl-0.9.8/crypto' gmake: *** [build_crypto] Error 1 [EMAIL PROTECTED] 15% ... At what point do we say this platform is too old and too broken to support? When nobody who is willing to beta test and contribute bugfixes/code corrections owns one of those platforms? Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1015] don't use O_NOFOLLOW on Solaris...
Rob, Where is O_NOFOLLOW used in OpenSSL version 0.9.7e? Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Robert Banz via RT Sent: Tuesday, March 01, 2005 12:44 AM Cc: openssl-dev@openssl.org Subject: [openssl.org #1015] don't use O_NOFOLLOW on Solaris... OpenSSL version 0.9.7e OS: Solaris x86 R10 (and every solaris, at least those with O_NOFOLLOW) Trying to open /dev/random or /dev/urandom with O_NOFOLLOW doesn't work under Solaris, as everything under /dev/ is usually a symlink to the /devices/ tree. -rob __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1009] ERROR while excuting ./config
Hi Edward, If you type which make at the command line does the system find it? Usually in Solaris to build software you need the development tools, which AREN'T installed by default, and you need a C compiler (generally people use binaries of gcc that they download or purchase the Sun compiler) The development tools are the linker, the library archiver, the make program, etc. and generally reside in /usr/ccs/bin If you don't have that the go back to the Solaris install CD's and install them. Sounds like this is your first time compiling software on your Solaris box? If so, you might want to post in some of the Solaris forums, people there can help you get your development environment setup correctly. OpenSSL is a pretty big project for a newbie to tackle! Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of TSD, Engineer (IDS DSP Pac Rim) via RT Sent: Tuesday, February 15, 2005 12:55 AM Cc: openssl-dev@openssl.org Subject: [openssl.org #1009] ERROR while excuting ./config Hi, # ./config Operating system: sun4u-whatever-solaris2 Configuring for solaris-sparcv9-cc Configuring for solaris-sparcv9-cc IsWindows=0 CC=cc CFLAG =-DOPENSSL_SYSNAME_ULTRASPARC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DMD5_ASM EX_LIBS =-lsocket -lnsl -ldl BN_ASM=asm/sparcv8plus.o DES_ENC =des_enc.o fcrypt_b.o BF_ENC=bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4_enc.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM =asm/md5-sparcv8plus.o SHA1_OBJ_ASM = RMD160_OBJ_ASM= PROCESSOR = RANLIB=true ARFLAGS = PERL =/usr/bin/perl THIRTY_TWO_BIT mode DES_PTR used DES_RISC1 used DES_UNROLL used BN_LLONG mode RC4 uses uchar RC4_CHUNK is unsigned long long BF_PTR used sh: make: not found Regards Edward If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Minimum compiler support on different unix flavours?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andy Polyakov Sent: Friday, February 04, 2005 2:37 AM To: openssl-dev@openssl.org Subject: Re: Minimum compiler support on different unix flavours? As part of a project I am compiling OpenSSL on multiple different Unix flavours and have had many different problems when trying to get OpenSSL to compile. Let be give you just a bit of advice. OpenSSL is extremely sensitive to half-assed gcc installations. Why just OpenSSL? *Any* application or toolkit might fall victim to half-assed gcc installation. Sorry, I was not meaning to single out OpenSSL. Rather that any complex application is more likely to be affected just because with more lines of code the chance for trouble with it rises. One thing though that the FAQ is missing is a good general discussion of randomness. I'll try to write one here, perhaps Andy would see fit to include it? By addressing me personally you effectively discourage other members from picking up the matter. Not intended at all, I'll keep that in mind for the future. Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: 0.9.7e with ./config shared won't build under FreeBSD 5.3
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Brian Candler Sent: Thursday, February 03, 2005 11:42 AM To: openssl-dev@openssl.org Subject: Re: 0.9.7e with ./config shared won't build under FreeBSD 5.3 On Thu, Feb 03, 2005 at 03:17:49PM +, Johnny C. Lam wrote: Try the attached patch taken from the NetBSD Packages Collection. From what I understand, this is already part of the openssl-0.9.7-stable branch. Cheers, -- Johnny Lam [EMAIL PROTECTED] --- Configure.orig 2004-10-01 07:34:28.0 -0400 +++ Configure 2005-02-03 10:06:37.0 -0500 @@ -1167,8 +1167,8 @@ } $des_obj=$des_enc unless (!$fips $des_obj =~ /\.o$/); my $fips_des_obj='asm/fips-dx86-elf.o'; -$fips_des_obj=$fips_des_enc unless $processor eq '386'; -my $fips_sha1_obj='asm/sx86-elf.o' if $processor eq '386'; +$fips_des_obj=$fips_des_enc unless ($fips $processor eq '386'); +my $fips_sha1_obj='asm/sx86-elf.o' if ($fips $processor eq '386'); $bf_obj=$bf_encunless ($bf_obj =~ /\.o$/); $cast_obj=$cast_encunless ($cast_obj =~ /\.o$/); $rc4_obj=$rc4_enc unless ($rc4_obj =~ /\.o$/); Thank you! That patch did the trick. You prodded me into looking into the FreeBSD ports collection and how they deal with it. Their solution appears to be a bit more brutal: --- Makefile.org.orig Tue Sep 28 22:52:14 2004 +++ Makefile.orgFri Nov 5 18:21:09 2004 @@ -175,8 +175,8 @@ # we might set SHLIB_MARK to '$(SHARED_LIBS)'. SHLIB_MARK= -DIRS= crypto fips ssl $(SHLIB_MARK) sigs apps test tools -SHLIBDIRS= fips crypto ssl +DIRS= crypto ssl $(SHLIB_MARK) sigs apps test tools +SHLIBDIRS= crypto ssl # dirs in crypto to build SDIRS= objects \ And it will go away once they switchover to the latest openssl that has the patch that Johnny referenced. Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Minimum compiler support on different unix flavours?
[EMAIL PROTECTED] wrote: Hello As part of a project I am compiling OpenSSL on multiple different Unix flavours and have had many different problems when trying to get OpenSSL to compile. Hi Peter, Let be give you just a bit of advice. OpenSSL is extremely sensitive to half-assed gcc installations. There's way too many gcc RPMs, gcc binary packages, and such that are out there which people slap into these UNIX flavors then have lots of problems. If you really want to get accurate results you MUST at minimum recompile gcc -twice-. What I have learned to do with the Solaris variants is I get the canned gcc package, install it, then download the gcc source and compile that, delete the package, do a make install, then continue -repeating- this process until a compare of the newly compiled gcc binary is identical to the installed gcc binary. So, I was wondering if anyone has done any work on minimum compiler requirements on a per flavour basis: IE: Solaris 2.6, 2.7, 8, 9: GNU - (GCC 3.2 + Binutuils 2.15 + GNU Make 3.80) or higher Now you see, this is just flat out not true. OpenSSL will compile up just fine on Solaris 2.xx even with gcc 2.7, as long as the gcc binary has been correctly compiled - and with using the Sun-supplied linker and make tools. It isn't necessary to pollute your system with the GNU binutils and GNU make if you don't wish to do so. The same applies to the random number generator (prngd or egd) on a per-flavour basis. There doesn't seem to be a place where you are told if the platform you are wanting to compile against has a random number generator or not (or when support was added via a patch etc). Yes you can check for /dev/random or /dev/urandom but if you don't know you need it then how can you look for it? I don't have a lot of sympathy for this argument since the FAQ for openssl discusses this here: http://www.openssl.org/support/faq.html#USER1 If you haven't at least read the OpenSSL FAQ, why do you think your qualified to compile it in the first place? And even then the FAQ is no substitute for the documentation. One thing though that the FAQ is missing is a good general discussion of randomness. I'll try to write one here, perhaps Andy would see fit to include it? Q) What is the difference between PRNGD, EGD, and the system devices /dev/random and /dev/urandom and what do I need? A) It's extremely important to have a high quality source of randomness to generate really unbreakable keys and such. Getting this in a computer is pretty difficult to do in software. The best randomess is obtained by hardware cards such as the hifn ones, here's a press release on these: http://www.hifn.com/info/pr/pressreleases/print/pr_121603_2.html This card touts a true random generator and if you need really truly absolute randomness, for perhaps research applications, then you need to be looking into this. Or, you could figure out how to hook a lava lamp to your computer. (another highly random device) But, for the rest of us the randomness that the computer can generate is sufficient for most ordinary encryption. OpenSSL tries to obtain this from the /dev/urandom device, falling back to /dev/random if /dev/urandom isn't available. These devices try to obtain randomness from things such as different changing kernel statistics, (simple but not very random) and/or counting hardware interrupts (better, but extremely OS version specific) On most UNIXs, /dev/random is a blocking driver and /dev/urandom is non-blocking. If /dev/random runs out of randomness to supply then the application that depends on it pretty much freezes until more randomness is available, if /dev/urandom runs out of randomess to supply to an application then it just makes extra, using a not particularly random algorithim. EGD, available here: http://egd.sourceforge.net/ is basically a software implementation of /dev/random for systems that lack the /dev/random driver, and PRNGD, available jere: http://freshmeat.net/projects/prngd is a software implementation of /dev/urandom for systems that lack that as well. There are several other PRNGD projects available than the one on freshmeat. There are some applications out there besides OpenSSL that require /dev/random or /dev/urandom, so if given a choice between installing a random driver or using PRNGD, it is better to install a /dev/random and /dev/urandom driver. Most UNIX implementations did not start including these drivers until very recently. The 3 major commercial ones are: Solaris: version 9 included by default, version 8, 2.7, and 2.6 available from a patch from Sun located here: http://sunsolve.sun.com/search/document.do?assetkey=1-25-27606-1. Version 2.5.1, and 2.4 available from an open source driver here: http://www.cosy.sbg.ac.at/~andi/SUNrand HP-UX: Version 11i available from HP here: http://docs.hp.com/en/5990-7263/index.html also available as an open source for version 11 (non-i) from here:
RE: Openssl-SNAP-20050129 Re: Openssl-SNAP-20050125 Re: Openssl-SNAP-20050124
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andy Polyakov Sent: Saturday, January 29, 2005 9:23 AM To: openssl-dev@openssl.org Subject: Re: Openssl-SNAP-20050129 Re: Openssl-SNAP-20050125 Re: Openssl-SNAP-20050124 ... ./sha512t Illegal instruction *** Error code 132 This means that your kernel does not support SSE2 and you have to other choice but to configure with no-sse2 and give up SSE2 enhancements. I'm sorry if I've lead you to wrong expectations, but my BSD experience was not broad enough to foresee this. A. Andy, please put the following in the README for OpenSSL: FreeBSD SSE Support: FreeBSD's kernel can be recompiled with one or more of the following options to enable SSE2 instructions, depending on the level of brokenness of your motherboard: # # CPU_ATHLON_SSE_HACK tries to enable SSE instructions when the BIOS has # forgotten to enable them. # # CPU_ENABLE_SSE enables SSE/MMX2 instructions support. # See the LINT file for your version of FreeBSD, kernel recompilation instructions are in the FreeBSD Handbook. Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1003] Request: entropy gathering
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Vladas Shukevichus via RT Sent: Tuesday, January 18, 2005 12:34 AM Cc: openssl-dev@openssl.org Subject: [openssl.org #1003] Request: entropy gathering It's kind of strange, each time php script with openssl function launched it gets delayed for such a long time (about a sec.). Is there any way how to prevent this? I found that recompiling all the code that deals with SSL with the -mpentium flag tremendously speeds things up. This was on a Pentium, obviously. You should investigate similar flags for your architecture. Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Having problems building shared libraries under Solaris 2.5.1
Hi All, An update on shared library support for Solaris 2.5.1, I did setup yet another Solaris 2.5.1 server and was successfully able to build OpenSSL with shared libraries. This time the first thing I did after installing the gcc 2.7.2 package, was to compile and install gcc 2.95.3 The only problem I had under Solaris is that while you can compile a program with an RPATH in it, which lists the locations of shared libraries on the system for the runtime linker, you cannot do this to libraries. As a result if you link openssl with zlib, libz.so must be softlinked into /usr/lib before building openssl. Solaris 2.6 and later have the crle command that fixes this. Ted -Original Message- From: Ted Mittelstaedt [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 11, 2005 12:21 PM To: openssl-dev@openssl.org Subject: RE: Having problems building shared libraries under Solaris 2.5.1 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andy Polyakov Sent: Tuesday, January 11, 2005 2:57 AM To: openssl-dev@openssl.org Subject: Re: Having problems building shared libraries under Solaris 2.5.1 I have a Solaris 2.5.1 x86 system and openssl 0.9.7e and I want to build it with shared libraries, so I tried the following with the openssl-0.9.7-stable-SNAP-20050109: ./Configure solaris-x86-gcc zlib shared no-asm and part way into the compilation it aborts with the following: + gcc -shared -G -dy -z text -o libcrypto.so.0.9.7 -h libcrypto.so.0.9.7 -Wl,-Bsymbolic -Wl,-z,allextract libcrypto.a -Wl,-z,defaultextract -L. -lsocket -lnsl -ldl -lc Undefined first referenced symbol in file __umoddi3 libcrypto.a(bn_word.o) __udivdi3 libcrypto.a(b_print.o) ld: warning: Symbol referencing errors Text relocation remains referenced against symbol offset in file unknown 0x154 libcrypto.a(ocsp_prn.o) unknown 0x15c libcrypto.a(ocsp_prn.o) unknown 0x164 libcrypto.a(ocsp_prn.o) unknown 0x16c libcrypto.a(ocsp_prn.o) unknown 0x174 libcrypto.a(ocsp_prn.o) unknown 0x184 libcrypto.a(ocsp_prn.o) unknown 0x18c libcrypto.a(ocsp_prn.o) unknown 0x17c libcrypto.a(ocsp_prn.o) Well, 0.9.7-stable snapshot was recently tested on Solaris x86 with gcc 2.95 and it succeeded to build shared. Hi Andy, Could you please put that in the documentation with OpenSSL? This was all under gcc 2.7.2 which I readily admit is old - it was off the sunfreeware site. If I had known in advance I probably would have updated gcc first before building a bunch of other things. I did look at the openssl docs early, actually. As for relocations. This is *pure* compiler domain, there is nothing one can do in C code to eliminate a text relocation. So it must be a compiler bug, something beyond our control. OK no problem - then put in the openssl docs that openssl cannot be built shared under Solaris 2.5.1 with gcc 2.7.2, you must upgrade the complier to a later version of gcc. Interesting how it only affects ocsp_prn.o As for __u[mod|div]di3 symbols. As you pointed out they do rezide in libgcc, but gcc driver used to add -lgcc all by itself. At least I can confirm that it does so on my system and symbols in question are properly resolved. Probably a problem with how gcc 2.7.2 was built. The gcc 2.7.2 that is on sunfreeware was put up years ago on sunsite, before that was taken down. Supposedly it was built with Sun's cc. It is really the only readily available precompiled gcc for Solaris 2.5.1 x86 that has any credibility, I'm afraid. I should have used it to bootstrap gcc 2.95 but I was in a hurry to get the system up. In other words. Upgrade your compiler or give up shared support. There hardly are other options. A. Thanks! I'll do that the next time I build another 2.5.1 system (if I build another 2.5.1. system that is, the one I'm working on is kind of a special case, actually) Fortunately for this one shared support wasn't a requirement. Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1000] OpenSSL 0.9.7e fails RIPEMD160 on Sparc64
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gert Doering via RT Sent: Thursday, January 13, 2005 12:50 AM Cc: openssl-dev@openssl.org Subject: Re: [openssl.org #1000] OpenSSL 0.9.7e fails RIPEMD160 on Sparc64 Hi, On Thu, Jan 13, 2005 at 12:09:42AM +0100, Andy Polyakov via RT wrote: Anything I should try? INSTALL is specfic about this. Try removing any compiler optimization flags... This very issue was discussed couple of times already (google for error message) in Solaris context. The error is believed to be a GCC 64-bit specific bug and nobody managed to prove otherwise so far. A. OK, thanks. If I compile the two .c/.o files in crypto/ripemd/ without optimization, the ./rmdtest passes without a hitch. Gert, Are you using GNU as or the Solaris as? Have you tried this with the other assembler? Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Having problems building shared libraries under Solaris 2.5.1
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andy Polyakov Sent: Tuesday, January 11, 2005 2:57 AM To: openssl-dev@openssl.org Subject: Re: Having problems building shared libraries under Solaris 2.5.1 I have a Solaris 2.5.1 x86 system and openssl 0.9.7e and I want to build it with shared libraries, so I tried the following with the openssl-0.9.7-stable-SNAP-20050109: ./Configure solaris-x86-gcc zlib shared no-asm and part way into the compilation it aborts with the following: + gcc -shared -G -dy -z text -o libcrypto.so.0.9.7 -h libcrypto.so.0.9.7 -Wl,-Bsymbolic -Wl,-z,allextract libcrypto.a -Wl,-z,defaultextract -L. -lsocket -lnsl -ldl -lc Undefined first referenced symbol in file __umoddi3 libcrypto.a(bn_word.o) __udivdi3 libcrypto.a(b_print.o) ld: warning: Symbol referencing errors Text relocation remains referenced against symbol offset in file unknown 0x154 libcrypto.a(ocsp_prn.o) unknown 0x15c libcrypto.a(ocsp_prn.o) unknown 0x164 libcrypto.a(ocsp_prn.o) unknown 0x16c libcrypto.a(ocsp_prn.o) unknown 0x174 libcrypto.a(ocsp_prn.o) unknown 0x184 libcrypto.a(ocsp_prn.o) unknown 0x18c libcrypto.a(ocsp_prn.o) unknown 0x17c libcrypto.a(ocsp_prn.o) Well, 0.9.7-stable snapshot was recently tested on Solaris x86 with gcc 2.95 and it succeeded to build shared. Hi Andy, Could you please put that in the documentation with OpenSSL? This was all under gcc 2.7.2 which I readily admit is old - it was off the sunfreeware site. If I had known in advance I probably would have updated gcc first before building a bunch of other things. I did look at the openssl docs early, actually. As for relocations. This is *pure* compiler domain, there is nothing one can do in C code to eliminate a text relocation. So it must be a compiler bug, something beyond our control. OK no problem - then put in the openssl docs that openssl cannot be built shared under Solaris 2.5.1 with gcc 2.7.2, you must upgrade the complier to a later version of gcc. Interesting how it only affects ocsp_prn.o As for __u[mod|div]di3 symbols. As you pointed out they do rezide in libgcc, but gcc driver used to add -lgcc all by itself. At least I can confirm that it does so on my system and symbols in question are properly resolved. Probably a problem with how gcc 2.7.2 was built. The gcc 2.7.2 that is on sunfreeware was put up years ago on sunsite, before that was taken down. Supposedly it was built with Sun's cc. It is really the only readily available precompiled gcc for Solaris 2.5.1 x86 that has any credibility, I'm afraid. I should have used it to bootstrap gcc 2.95 but I was in a hurry to get the system up. In other words. Upgrade your compiler or give up shared support. There hardly are other options. A. Thanks! I'll do that the next time I build another 2.5.1 system (if I build another 2.5.1. system that is, the one I'm working on is kind of a special case, actually) Fortunately for this one shared support wasn't a requirement. Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Having problems building shared libraries under Solaris 2.5.1
Hi All, I have a Solaris 2.5.1 x86 system and openssl 0.9.7e and I want to build it with shared libraries, so I tried the following with the openssl-0.9.7-stable-SNAP-20050109: ./Configure solaris-x86-gcc zlib shared no-asm and part way into the compilation it aborts with the following: + gcc -shared -G -dy -z text -o libcrypto.so.0.9.7 -h libcrypto.so.0.9.7 -Wl,-Bsymbolic -Wl,-z,allextract libcrypto.a -Wl,-z,defaultextract -L. -lsocket -lnsl -ldl -lc Undefined first referenced symbol in file __umoddi3 libcrypto.a(bn_word.o) __udivdi3 libcrypto.a(b_print.o) ld: warning: Symbol referencing errors Text relocation remains referenced against symbol offset in file unknown 0x154 libcrypto.a(ocsp_prn.o) unknown 0x15c libcrypto.a(ocsp_prn.o) unknown 0x164 libcrypto.a(ocsp_prn.o) unknown 0x16c libcrypto.a(ocsp_prn.o) unknown 0x174 libcrypto.a(ocsp_prn.o) unknown 0x184 libcrypto.a(ocsp_prn.o) unknown 0x18c libcrypto.a(ocsp_prn.o) unknown 0x17c libcrypto.a(ocsp_prn.o) ld: fatal: relocations remain against allocatable but non-writable sections *** Error code 1 make: Fatal error: Command failed for target `do_solaris-shared' Current working directory /usr/home/downloads/temp/openssl-0.9.7-stable-SNAP-20050109 *** Error code 1 make: Fatal error: Command failed for target `libcrypto.so.0.9.7' Current working directory /usr/home/downloads/temp/openssl-0.9.7-stable-SNAP-20050109 *** Error code 1 make: Fatal error: Command failed for target `shared' Current working directory /usr/home/downloads/temp/openssl-0.9.7-stable-SNAP-20050109/fips *** Error code 1 make: Fatal error: Command failed for target `sub_all' # Any suggestions? The static build works fine. This is with gcc 2.7.2 Also, note that if I do this: ./Configure solaris-x86-gcc zlib shared no-asm -lgcc then the symbol in file __umoddi3 libcrypto.a(bn_word.o) __udivdi3 libcrypto.a(b_print.o) problem goes away, however the rest of them are still there. Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
