Re: Solaris gcc shared library target is broken in 0.9.6a
On Sat, Apr 14, 2001 at 07:49:36PM +0200, Richard Levitte - VMS Whacker wrote: carson The solaris-*-gcc targets all seem to assume you're using GNU carson ld, which nobody _I_ know does under solaris (does it even carson compile?). This causes the shared library builds to carson bomb. Fortunately, the fix is easy: I use GNU ld on Solaris, at least on the system I tested on. Your fix breaks that, unfortunately, and setting $PATH to prioritise Solaris ld didn't seem to help, it seems like collect2 had the path to GNU ld hardcoded. For Java programs (with gcc and libgcj) you apparently *have* to use GNU ld; otherwise Java runtime library initialization fails in strange ways. Setting PATH does not change the compiled-in default (gcc usually wanted to use /usr/ccs/bin/ld in our compilation); but this default can be overriden by creating links in directories such as /opt/gcc-2.95.2/sparc-sun-solaris2.6/bin (if gcc has been compiled with --prefix=/opt/gcc-2.95.2 on a sparc-sun-solaris2.6 system). I think before I had created this link, the gcc configure script detected GNU ld because of the PATH setting, but the compiled gcc still used /usr/ccs/bin/ld (or even used both versions for different purposes), so gcc didn't work very well ... I had to use 'ls -ul' and 'truss' a lot until gcc worked again after I had installed GNU ld. Installing GNU ld was no problem at all, the problem was to persuade gcc to use it correctly. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: int return values from ssl(3) API functions
On Fri, Apr 20, 2001 at 11:29:51AM -0400, Tom Biggs wrote:
I'm implementing code to do OpenSSL handshake/read/write
for some radically different hardware. These will completely
replace the standard OpenSSL handshake state machine
and most of the API functions at the SSL_METHOD level.
I am used to I/O return codes where
( 0 ) means success
( == 0 ) means I/O block but otherwise no problem
( 0 ) means error
So far, I've implemented all my routines to work that way.
Usually 0 means EOF. 'I/O block' is a return value of -1 with errno
set to EAGAIN or EWOULDBLOCK, these days (O_NONBLOCK semantics).
You'd see 0 in these situations only if you use O_NDELAY, but you
should not do this: The O_NDELAY semantics make it impossible to tell
the difference between EOF (connection closed) and a EWOULDBLOCK
situation (connection open, but no data available) for read requests.
(While often both O_NDELAY and O_NONBLOCK are available, luckily only
the latter is standardized.)
According to the manpages for the ssl(3) API functions,
OpenSSL works a bit differently
( 0 ) means success
( == 0 ) means error
( 0 ) means error
In both cases the manpage advises calling SSL_get_error()
to find the reason.
When SSL_read() etc. return 0 this means that EOF was encountered.
To find out if this is an error, you have to call SSL_get_error();
it might be a legitimate closure.
When SSL_read() etc. return -1, this is not necessarily an error;
it might be an EWOULDBLOCK situation. Again you'll have to
call SSL_get_error() to check.
You don't have to look at SSL_{connect,accept,read,peek,write} return
values in your program; just pass them over to SSL_get_error().
For positive return values, SSL_get_error() will always return
SSL_ERROR_NONE; but for 0 or -1, there's usually not much the
application can find out by itself.
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: int return values from ssl(3) API functions
At 02:43 PM 4/27/01 +0200, Bodo wrote:
On Fri, Apr 20, 2001 at 11:29:51AM -0400, Tom Biggs wrote:
I'm implementing code to do OpenSSL handshake/read/write
for some radically different hardware. These will completely
replace the standard OpenSSL handshake state machine
and most of the API functions at the SSL_METHOD level.
I am used to I/O return codes where
( 0 ) means success
( == 0 ) means I/O block but otherwise no problem
( 0 ) means error
So far, I've implemented all my routines to work that way.
Usually 0 means EOF. 'I/O block' is a return value of -1 with errno
set to EAGAIN or EWOULDBLOCK, these days (O_NONBLOCK semantics).
You'd see 0 in these situations only if you use O_NDELAY, but you
should not do this: The O_NDELAY semantics make it impossible to tell
the difference between EOF (connection closed) and a EWOULDBLOCK
situation (connection open, but no data available) for read requests.
(While often both O_NDELAY and O_NONBLOCK are available, luckily only
the latter is standardized.)
OK, thanks, Bodo. I guess I've been wrapped up in embedded
programming for too long - it must have overridden my Unix knowledge.
In most of the embedded systems I've been working on, a zero
return from an I/O function means nothing right now, come
back later.
Now please excuse me, while I go pull my foot out of my mouth. :-)
When SSL_read() etc. return 0 this means that EOF was encountered.
To find out if this is an error, you have to call SSL_get_error();
it might be a legitimate closure.
When SSL_read() etc. return -1, this is not necessarily an error;
it might be an EWOULDBLOCK situation. Again you'll have to
call SSL_get_error() to check.
You don't have to look at SSL_{connect,accept,read,peek,write} return
values in your program; just pass them over to SSL_get_error().
For positive return values, SSL_get_error() will always return
SSL_ERROR_NONE; but for 0 or -1, there's usually not much the
application can find out by itself.
I'm actually inside OpenSSL, looking out. As I mentioned in my
introductory paragraph, I am writing a set of modules which
will pretty much replace the s3_*.c (and s23_*.c) modules.
This is in support of a radical new NIC. The basic underlying
OpenSSL I/O model will not work on this hardware [1], so I am
writing *all new* functions to do all SSL_read/write/accept/connect
operations [2].
I just want to make sure that I understand how the existing functions
return status, so that mine work compatibly. Thank you for your
assistance.
It turns out that I don't have to change as many OpenSSL modules
as I thought at first. I'm splicing my functions in at the SSL_METHOD
level, so the high-level calls drop in transparently. Outside of that,
so far I've only had to modify SSL_get_error and a bit of the alert code
(the only two areas I've come across thus far that weren't built into the
METHOD pointer scheme).
[1] well, it *could*, but all the neat optimizations would have be
turned off, and that would destroy the performance advantage.
[2] which is why I posted to this list and not -users.
Tom Biggs
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Shared libraries on AIX...
I'm looking a bit at building shared libraries on AIX, and would like to know if there is a way at all to just tell ld to extract everything from a static library (libcrypto.a), put it in a shared library (libcrypto.a) and export all available global symbols? I know it's possible to create an exported symbols file (libcrypto.exp?) and use that, but I'd like to avoid that if possible, it feels like a very unneeded step, and full of possibilities to make a fool out of yourself (by forgetting). On all other Unixen I've played with, there's the possibility to do what I want to do (hence the diverse do_*-shared targets in Makefile.org), and I just can't believe such a thing wouldn't be possible on AIX... Then perhaps, I'm just too optimistic... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
openssl asm for ppc?
Has anyone done any work on the asm for the PPC platform? I'm using 0.9.6a on Mac OSX. gprof shows that most of my time is spent in the bn routines that are normally asm (on other platforms): % cumulative self self total time seconds secondscalls ms/call ms/call name 50.0 0.03 0.03 _bn_mul_add_words[1] 33.3 0.05 0.02 _bn_sqr_comba8 [2] ... I'm using the following: localhost openssl version -a OpenSSL 0.9.6a-beta3 30 Mar 2001 built on: Wed Apr 4 13:12:36 EDT 2001 platform: Darwin options: bn(32,32) md2(int) rc4(ptr,int) des(idx,cisc,4,long) idea(int) blowfish(idx) compiler: cc -DTHREADS -D_REENTRANT -DTIMES -DTIMES -DNO_GMTIME_R -O3 Any tips? Anyone from Apple, IBM or Motorola care to comment? Thanks, Steve __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Shared libraries on AIX...
Not exactly. ld on AIX 4.2+ has the -bexpall flag to export everything, but this flag does bad things on shared libraries, and should only be used on executables. I sent you patches for AIX before. These are the rules I use in our Makefile. They work on all platforms: $(SHRCRYPTO): lib/$(LIBCRYPTO).a ld -r -o $(LIBCRYPTO).o $(ALLSYMSFLAG) lib/$(LIBCRYPTO).a -nm -Pg $(LIBCRYPTO).o | grep ' [BD] ' | cut -f1 -d' ' $(LIBCRYPTO).exp $(CC) $(SHAREDFLAG) -o $@ $(LIBCRYPTO).o $(SHRSSL): lib/$(LIBSSL).a $(SHRCRYPTO) ld -r -o $(LIBSSL).o $(ALLSYMSFLAG) lib/$(LIBSSL).a -nm -Pg $(LIBSSL).o | grep ' [BD] ' | cut -f1 -d' ' $(LIBSSL).exp $(CC) $(SHAREDFLAG) -o $@ $(LIBSSL).o $(SHRCRYPTO) The ALLSYMSFLAG is -bnogc for AIX, which turns off garbage collection and bypasses the step where the linker removes unreferenced objects. For Linux the flag is -whole-archive, for Solaris -z allextract. Obviously the contents of lib/$(LIBXX).a is assumed to be PIC code. I haven't configured this on any other platforms recently, so I don't have the corresponding flags, but it shouldn't be hard to find them. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte - VMS Whacker Sent: Friday, April 27, 2001 8:11 AM To: [EMAIL PROTECTED] Subject: Shared libraries on AIX... I'm looking a bit at building shared libraries on AIX, and would like to know if there is a way at all to just tell ld to extract everything from a static library (libcrypto.a), put it in a shared library (libcrypto.a) and export all available global symbols? I know it's possible to create an exported symbols file (libcrypto.exp?) and use that, but I'd like to avoid that if possible, it feels like a very unneeded step, and full of possibilities to make a fool out of yourself (by forgetting). On all other Unixen I've played with, there's the possibility to do what I want to do (hence the diverse do_*-shared targets in Makefile.org), and I just can't believe such a thing wouldn't be possible on AIX... Then perhaps, I'm just too optimistic... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Shared libraries on AIX...
From: Howard Chu [EMAIL PROTECTED] hyc $(SHRSSL): lib/$(LIBSSL).a $(SHRCRYPTO) hyc ld -r -o $(LIBSSL).o $(ALLSYMSFLAG) lib/$(LIBSSL).a hyc -nm -Pg $(LIBSSL).o | grep ' [BD] ' | cut -f1 -d' ' $(LIBSSL).exp hyc $(CC) $(SHAREDFLAG) -o $@ $(LIBSSL).o $(SHRCRYPTO) hyc hyc The ALLSYMSFLAG is -bnogc for AIX, which turns off garbage collection hyc and bypasses the step where the linker removes unreferenced objects. For I assume that for AIX, SHAREDFLAG would be something like -bE:$(LIBSS).exp -bM:SRE, except a lttle bit more generalised, right? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Engine vs. Crypto Lib Question
Thanks for the feedback. I really appreciate it. We hope to be active, participating members of the OpenSSL community and this type of information really helps. It would appear that I had some misunderstandings about the Engine interface. Thanks for clearing them up. At this point, I think we will continue on the path we are on which, BTW, is well past the point of coding around the edges of OpenSSL (hard core as you would say :-). Since we are attempting primarily to hook our library in at the EVP layer, I do think much of what we find we need to do may be of use to your Engine development if that is the same level you are targetting for interfacing with SSL/TLS. (It should also simplify our task should we decide later to convert to the Engine interface.) At this point, I will start taking a look at the development builds in an effort to push back any changes we are making (EVP implementation of digests, ciphers, etc.) in that context and hope that it can be of benefit to all of us. Cheers. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com [EMAIL PROTECTED] 04/26/01 05:30PM Hi there,If you're on the commit mail list you'll probably be aware why I haven't had achance to answer your posts until now. :-) Thanks for the contributions w.r.t.standardising the use of EVP ... it's the kind of thing that needs doing andsoon (see below #3) it will be even more important. Like Steve said, if youcould work your patch into a recent snapshot of 0.9.7-dev, that would make lifeeasier for us to review it and add it.On Thu, 26 Apr 2001, Verdon Walker wrote: As I have mentioned before, we are currently producing an OpenSSL solution that uses our own cryptography library for ALL cryptographic functionality (instead of using libeay for those functions). We have elected to actually replace the underlying crypto functions in libeay with calls to our own library (at the EVP level wherever possible) instead of attempting to use the ENGINE interface. We are doing this for various reasons and I wanted to run them by you to see if our thinking is sound (or if we have missed something):Sure thing. The ENGINE stuff is moving quite swiftly - you'll probably see anumber of fairly major improvements (and necessarily, changes) in the underlyingcode and the API before 0.9.7 approaches. On the one hand, this may provide youwith something useful, on the other hand it may also scare you off until itsettles down a bit. YMMV. 1 - It appears that Engine is meant to provide support for alternate solutions (primarily hardware), but will fall back to the libeay software solution if no other engines exist. We must use our library for all cryptography. It is not optional.Um, no. It is easy to code an ENGINE to fallback to another ENGINE in the eventof ENGINE-specific errors, together with whatever retry logic is required.However, if an ENGINE doesn't support handling failed operations by falling backto something else, then any failed operation *stays* failed. If you simply wantto ensure that the 'openssl' ENGINE isn't available or that its role is replaced- edit the 'engine_internal_check()' function in engine_list.c and replace thecall to ENGINE_openssl() with the ENGINE you'd like to replace it with. 2 - Engine does not support cryptography that is not also supported through the standard software interface. Richard Levitte just started a thread on this topic (Disabling algorithms) which is really what got me thinking about this again. In any case, if we disable the current software solutions, it would appear that we also disable any ability to provide the solutions through the engine. See #1 to understand why this is not acceptable for us.Again, I don't think this is true (if I understood you correctly). See theanswer to #1 to understand why. :-) 3 - Engine does not currently support all cryptographic functionality. Most notable would be symmetric ciphers, but we also need to use our library for RAND and other functions that may not be supported either.RAND is supported through the ENGINE interface, and once again you couldhard-code it in as the startup default if you wish. Symmetric cipher support iscoming - I've already discussed with a couple of the others about how this canbe done and some of the current changes are to better facilitate this. Ienvisage that EVP_CIPHER and EVP_MD support will be in the ENGINE code soon. Theone thing it won't do due to far more fundamental difficulties is deal withopaque (hardware-managed) symmetric keys. That doesn't seem to be an issue forwhat you're doing, but it may be to someone else out there lurking and watchingthis. 4 - Engine is still in early development and may not be as stable as the standard code base.Testing welcomed. :-) It would be more accurate to say that the ENGINE code inCVS is undergoing a lot of new work. However, what exists in the 0.9.6a releaseis
RE: Shared libraries on AIX...
That's right. I actually used: '-bM:SRE -bE:$*.exp -b noentry' I had to add explicit code to the Configure script to set this since I couldn't figure out how to embed colons in the configuration table. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc -Original Message- From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]] Sent: Friday, April 27, 2001 2:20 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Shared libraries on AIX... From: Howard Chu [EMAIL PROTECTED] hyc $(SHRSSL): lib/$(LIBSSL).a $(SHRCRYPTO) hyc ld -r -o $(LIBSSL).o $(ALLSYMSFLAG) lib/$(LIBSSL).a hyc -nm -Pg $(LIBSSL).o | grep ' [BD] ' | cut -f1 -d' ' $(LIBSSL).exp hyc $(CC) $(SHAREDFLAG) -o $@ $(LIBSSL).o $(SHRCRYPTO) hyc hyc The ALLSYMSFLAG is -bnogc for AIX, which turns off garbage collection hyc and bypasses the step where the linker removes unreferenced objects. For I assume that for AIX, SHAREDFLAG would be something like -bE:$(LIBSS).exp -bM:SRE, except a lttle bit more generalised, right? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Ocotillo PRNG support
I posted this on the users mailing list, but it occurs to me that it might be more appropriate on the developer's list. I'd like to use the Ocotillo (http://ocotillo.sourceforge.net) PRNG with OpenSSL, but it is failing when I do the make test in the randtest module. Ocotillo creates a named pipe at /dev/urandom but if OpenSSL is treating it like a character device it may not work correctly. I'm out of my depth here, but I'm hoping that somebody will be able to help me out. I'm not a C programmer, but I've been a programmer for the past 28 years and I am currently a Unix system administrator, so fire away! Any help anybody (OpenSSL developers?) can give would be wonderful! (Note: Please cc my email address: mailto:[EMAIL PROTECTED] ) Jerel Crosland 21st Century Insurance Unix Level 2 Support (818)704-3187 *** This e-mail and any files transmitted with it are intended solely for the use of the addressee. This e-mail may contain confidential and/or legally privileged information. Any review, transmission, disclosure, copying, or any action taken or not taken, by other than the intended recipient, in reliance on the information, is prohibited. If you received this e-mail in error, notify the sender and delete this e-mail (and any accompanying material) from your computer and network. In addition, please be advised that 21st Century Insurance Group reserves the right to monitor, access and review all messages, data and images transmitted through our electronic mail system. By using our e-mail system, you consent to this monitoring. *** __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Shared libraries on AIX...
Hello, I am trying to generate a certificate using the openSSL 9.5a (windows 98, 800Mhz, 128MBRAM. When I use rsa public key of 3 or 5, it takes a few seconds, but when I use higher numbers such as 244, it takes forever (in fact it has not come back yet after 3 hrs). Is this expected? Am I doing things right? What area should I be looking into? Thanks for any help. J. Shoghli __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
