Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229: lddproblems

2003-01-10 Thread Richard Levitte - VMS Whacker
OK, I've hacked a little.  Please try the following patch on a 0.9.7
snapshot, and put the attached openssl-shared.txt in doc/:

Index: Makefile.org
===
RCS file: /e/openssl/cvs/openssl/Makefile.org,v
retrieving revision 1.154.2.49
diff -u -u -r1.154.2.49 Makefile.org
--- Makefile.org9 Jan 2003 16:15:06 -   1.154.2.49
+++ Makefile.org10 Jan 2003 12:03:15 -
@@ -763,6 +763,12 @@
cd $(INSTALL_PREFIX)$(INSTALLTOP)/lib; \
set $(MAKE); \
$$1 -f $$here/Makefile link-shared ); \
+   if [ $(INSTALLTOP) != /usr ]; then \
+   echo 'OpenSSL shared libraries have been installed in:'; \
+   echo '  $(INSTALLTOP)'; \
+   echo ''; \
+   sed -e '1,/^$/d doc/openssl-shared.txt; \
+   fi; \
fi
cp openssl.pc $(INSTALL_PREFIX)$(INSTALLTOP)/lib/pkgconfig
 

The OpenSSL  shared libraries are often installed in a directory like
/usr/local/ssl/lib.

If this directory is not in a standard system path for dynamic/shared
libraries, then you will have problems linking and executing
applications that use OpenSSL libraries UNLESS:

* you link with static (archive) libraries.  If you are truly
  paranoid about security, you should use static libraries.
* you define the LD_LIBRARY_PATH, LIBPATH, SHLIB_PATH (HP),
  DYLD_LIBRARY_PATH (MacOS X) or PATH (Cygwin and DJGPP)
  environment variable and add the OpenSSL shared library
  directory to it, and use the -L linker option.
* you use the GNU libtool code during linking
  (http://www.gnu.org/software/libtool/libtool.html)
* you use pkg-config during linking (this requires that
  PKG_CONFIG_PATH includes the path to the OpenSSL shared
  library directory)
  (http://www.freedesktop.org/software/pkgconfig/)
* you specify the system-wide link path via a command such
  as crle(1) on Solaris systems.
* you add the OpenSSL shared library directory to /etc/ld.so.conf
  and run ldconfig(8) on Linux systems.

One common tool to check the dynamic dependencies of an executable
or dynamic library is ldd(1) on most UNIX systems.

See any operating system documentation and manpages about shared
libraries for your version of UNIX.  The following manpages may be
helpful: ld(1), ld.so(1), ld.so.1(1) [Solaris], dld.sl(1) [HP],
ldd(1), crle(1) [Solaris], pldd(1) [Solaris], ldconfig(8) [Linux].



Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229: lddproblems

2003-01-10 Thread Andy Polyakov
 --
 OpenSSL Shared Libraries have been installed in:
[directory name]
 
 If this directory is not in a standard system path for dynamic/shared
 libraries, then you will have problems linking and executing
 applications that use OpenSSL libraries UNLESS:

There is another option, The Right Thing:-) To start with the problem
is formulated incorrectly in my opinion. To make 'ldd libssl.so' work is
not actually *the* goal, 'ldd openssl' or 'ldd target-app' is. And the
first priority answer to the problem should be *embedded* run-time
library path. Well, it can be embedded even into .so object, but it's
not necessary a good thing. Because you might want to include a copy
into some bigger package and install it in alternative location.
Embedded run-time library path belongs in application, not .so, and
that's what you want to control.

How does one control the run-time library path in general? Yes, crle is
a way, but it first appears in Solaris 8, it's pain in network
environment (you have to configure it on every damn machine) and is not
plain-user friendly. Yes, LD_LIBRARY_PATH[_64] environment variable is
another way, but you don't want to rely on it as users are bound to fail
to [re]set it. Finally (the option I refer to as embedded run-time
path), it's possible to set LD_RUN_PATH at link time or pass -R flag to
the linker(*). Currently OpenSSL does embed run-time path into .so on
some OSes (Tru64?), but I for one am not actually fond of it. As already
mentioned [even last year] I believe that it should be embedded into
application where it belongs (.so never run). Another argument against
embedding it onto .so is presence of multiple ABI and not having real
control over which ABI was actually chosen. It's those who deploy the
toolkit [are expected to] have the grip over the run-time library path
(they might even choose to embed multiple path), not us. That's what I
basically ment last year that we should stand for code and
documentation, but not for the run-time path itself. Well, we have to
care about openssl application itself, but again, not by embedding the
run-time path into .so, but into the application.

Bottom line. +1 for proposed documentation with explicit mention and
prioritizing (i.e. #2 after static linking:-) of embedded run-time path
and lowering LD_LIBRARY_PATH priority. As for pkgconfig. I know nothing
about it, but assume that openssl.pc has everything to do with it. I
think it's a good idea to put -R/-rpath into it.

(*) Most OSes support equivalent option. Most notably -rpath (Linux,
Tru64, IRIX). And when it comes to Solaris and Linux there is an easter
egg here. Starting with 2.6 Solaris run-time linker implements support
for $ORIGIN. E.g. if you pass -R \$ORIGIN/../lib to the linker, the
application will be looking for .so objects in ../lib relative to the
application binary. This $ORIGIN thing is very useful. It's so useful,
that it's tempting to wrap openssl binary into a script which would
emulate $ORIGIN on platforms that lack $ORIGIN. Yes, approximately the
way autoconf does in build tree. Should I look into it?

A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229:lddproblems

2003-01-10 Thread Richard Levitte - VMS Whacker
In message [EMAIL PROTECTED] on Fri, 10 Jan 2003 15:03:00 +0100, Andy 
Polyakov [EMAIL PROTECTED] said:

appro There is another option, The Right Thing:-)

Of course :-).

Unfortunately, about -R/-rpath, I've avoided it so far for exactly the
reason you mentioned: it doesn't quite support moving libraries to a
dofferent place and still have it work.  And also, I have understood
that libssl.so does need a -R/-rpath to be able to find libcrypto.so,
on which it depends.  And you're quite correct, the openssl
application should be linked with it, which we don't do at all today...

appro (*) Most OSes support equivalent option. Most notably -rpath (Linux,
appro Tru64, IRIX). And when it comes to Solaris and Linux there is an easter
appro egg here. Starting with 2.6 Solaris run-time linker implements support
appro for $ORIGIN. E.g. if you pass -R \$ORIGIN/../lib to the linker, the
appro application will be looking for .so objects in ../lib relative to the
appro application binary. This $ORIGIN thing is very useful. It's so useful,
appro that it's tempting to wrap openssl binary into a script which would
appro emulate $ORIGIN on platforms that lack $ORIGIN. Yes, approximately the
appro way autoconf does in build tree. Should I look into it?

That's a good idea.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229:lddproblems

2003-01-10 Thread Andy Polyakov
 Unfortunately, about -R/-rpath, I've avoided it so far for exactly the
 reason you mentioned: it doesn't quite support moving libraries to a
 dofferent place and still have it work.

And that is what I'm suggesting to adhere to. I.e. to avoid it (and even
to remove it from tru64!) and leave this final decision to those who
deploy the toolkit.

 And also, I have understood
 that libssl.so does need a -R/-rpath to be able to find libcrypto.so,
 on which it depends.

This is not true. The fact that 'ldd libssl.so' says can't locate
libcrypto.so does *not* mean that libssl.so is bound to fail to link
with libcrypto.so. -L and -R options at *application* link time provide
for that. -R/-rpath option at libssl.so link time can and should be
omitted. -R/-rpath option at *application* link time is the one to be
used.

A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #423]openssl-0.9.7-stable-SNAP-20021229:lddproblems

2003-01-10 Thread Richard Levitte - VMS Whacker
In message [EMAIL PROTECTED] on Fri, 10 Jan 2003 17:40:18 +0100, Andy 
Polyakov [EMAIL PROTECTED] said:

appro  And also, I have understood
appro  that libssl.so does need a -R/-rpath to be able to find libcrypto.so,
appro  on which it depends.
appro 
appro This is not true. The fact that 'ldd libssl.so' says can't locate
appro libcrypto.so does *not* mean that libssl.so is bound to fail to link
appro with libcrypto.so. -L and -R options at *application* link time provide
appro for that. -R/-rpath option at libssl.so link time can and should be
appro omitted. -R/-rpath option at *application* link time is the one to be
appro used.

Ah, so recursive loads inherit the -R/-rpath values?  It's good to
know I misunderstood this.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229: lddproblems

2003-01-08 Thread Jeff A. Earickson
Hi,
   Here's the text I came up with:

--
OpenSSL Shared Libraries have been installed in:
   [directory name]

If this directory is not in a standard system path for dynamic/shared
libraries, then you will have problems linking and executing
applications that use OpenSSL libraries UNLESS:

* you link with static (archive) libraries.  If you are truly
  paranoid about security, you should use static libraries.
* you define the LD_LIBRARY_PATH or SHLIB_PATH (HP) environment
  variable and add [directory name] to it, and use the -L linker
  option.
* you use the GNU libtool code during linking
  (http://www.gnu.org/software/libtool/libtool.html)
* you specify the the system-wide link path via a command such as
  crle(1) on Solaris systems.

One common tool to check the dynamic dependencies of an executable
or dynamic library is ldd(1) on most UNIX systems.

See any operating system documentation and manpages about shared
libraries for your version of UNIX.  The following manpages may be
helpful: ld(1), ld.so(1), ld.so.1(1) [Solaris], dld.sl(1) [HP],
ldd(1), crle(1) [Solaris], pldd(1) [Solaris].
--

I looked at the Makefile to see where it might go.  make install
invokes make link-shared near the end of the install process.  The
text could be printed at that point.  A really good way to do this
would be to have the text above broken into two pieces, one generic
for all UNIX, and one specific to the OS.  The specific piece could
be printed out perhaps when the Makefile do_$(SHLIB_TARGET) target
is invoked.  That way the quirks of dynamic loading on Solaris, HP,
Linux, could be explained and the correct manpages referenced.

--- Jeff

On Wed, 1 Jan 2003, Richard Levitte - VMS Whacker via RT wrote:

 Date: Wed,  1 Jan 2003 14:58:09 +0100 (MET)
 From: Richard Levitte - VMS Whacker via RT [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229: ldd
 problems


 In message [EMAIL PROTECTED] on Wed,  1 Jan 2003 13:36:23 
+0100 (MET), Jeff A. Earickson via RT [EMAIL PROTECTED] said:

 rt man crle on a Sun box. It is:

 Not on the machine I currently have access to :-):

 $ man crle
 No manual entry for crle.

 rt crle - configure runtime linking environment
 rt
 rt which determines the search path for dynamic libs.  I had forgotten
 rt that I had added /opt/openssl/lib to this path.  When I was testing
 rt 0.9.7 in various forms, I installed it in /opt/openssl-0.9.7, but
 rt forgot to add the path via crle.  So I couldn't get dynamic loading
 rt to work and was going nuts...

 Can you recommend some piece of text that should be output?

 --
 Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
 Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
 \  SWEDEN   \ or +46-708-26 53 44
 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
 Member of the OpenSSL development team: http://www.openssl.org/

 Unsolicited commercial email is subject to an archival fee of $400.
 See http://www.stacken.kth.se/~levitte/mail/ for more info.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229: lddproblems

2003-01-01 Thread Richard Levitte - VMS Whacker
In message [EMAIL PROTECTED] on Wed,  1 Jan 2003 13:36:23 +0100 
(MET), Jeff A. Earickson via RT [EMAIL PROTECTED] said:

rt man crle on a Sun box. It is:

Not on the machine I currently have access to :-):

$ man crle 
No manual entry for crle.

rt crle - configure runtime linking environment
rt 
rt which determines the search path for dynamic libs.  I had forgotten
rt that I had added /opt/openssl/lib to this path.  When I was testing
rt 0.9.7 in various forms, I installed it in /opt/openssl-0.9.7, but
rt forgot to add the path via crle.  So I couldn't get dynamic loading
rt to work and was going nuts...

Can you recommend some piece of text that should be output?

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]