Using -lssh as shared library

[mouring at etoh.eviladmin.org]

On Mon, 8 Oct 2001, Michael Tokarev wrote:

> mouring at etoh.eviladmin.org wrote:
> >
> > On Mon, 8 Oct 2001, Michael Tokarev wrote:
> >
> > [..]
> > > I hacked source a bit, but not like this hack very well.
> > > What I did is created one extra file, ipv4or6.c, that
> > > contains definition of this variable, added it into
> > > list of objects for libssl, and changed actual declarations
> > > in ssh.c, sshd.c, ssh-keyscan.c and the like to be simple
> > > "extern int IPV4or6".  This allowed me to successefully
> > > use shared libssl.so.  I attached a patch named
> > > openssh-2.9.9p2-ipv4or6.diff, that does exactly this.
> > >
> >
> > Hmm... This is wrong.   IPV4or6 variable should be in a header file, not a
> > C file.
>
> I agree, but I don't think it belongs to it's own .h file.  Just
> like putting the variable itself into own .c file.  I'm not so
[..]

Considered ssh.h ?

[..]
> > > Note that before the change, ssh-keyscan linked with -lssh
> > > twice:
> > >  $(LD) -o $@ ssh-keyscan.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh $(LIBS)
> > > Looking into -lssh and -lopenbsd-compat, I don't think it is
> > > necessary: there is no "back-references" from -lopenbsd-compat
> > > to -lssh.  The patch mentioned above fixes this too.
> >
> > Incorrect.  bsd-arc4random.c refers to seed_rng()  which is part of
> > entropy.c.  Dynamic linking may remove this issue, but in our current
> > compile setup this hack is required.
>
> Hmm... interesting.  I not noticied this when inspecting source nor
> when linking with gcc/gld (I verified this line on non-shared lib
> too).  Interesting again -- how arc4random implemented in openbsd,
> it obviously should not refer to ssh library's seed_rng() (but see
> below).
>
> There is a trivial solution for this "library/linker problem"
> introduced by my little changes: instead of having SSH_LIBS/SSH_LDFLAGS
> as I did, use two separate variables (e.g. LIBSSH/LIBCOMPAT), but
> again as *variables* (to stop "hard-coding" them into Makefile).
> BTW, all compilers/linkers support "libstuff.a" in place of -lstuff
> (so that e.g. LIBCOMPAT can be used in both dependance and link
> lines).  The same, at least partially, true for libstuff.so too.
>
> Looking to bsd-arc4random.c, it seems not obvious to call seed_rng()
> from here at all -- seed_rng() will be called at least twice in
> some apps (that calls it directly and via arc4random()) -- not
> good, esp with implementation without /dev/[u]random.  Note also
> that apps used arc4random() *only* (I don't know if such an
> application exists in openssh -- it seems that ssh-keyscan is
> an example here) will be linked with all the routines from

arc4random() is never used by itself.  It is always used with conjuction
with either /dev/{u}random, PRNGd, EGD, or built-in entropy.  Because
arc4random() is not useful other then 'stiring' the entropy pot.  Which is
all it is used for.

> entropy.c file.  Having that said, I think that a) seed_rng()
> should be separated from entropy.c, b) arc4random()

Won't happen.. It makes no sense.. There are multiple versions of
seed_rng() depending on what type of compiled in entropy support is being
used currently.  Plus the code itself makes no sense by itself.

> should be moved from openbsd-compat into libssh (may be into
> the same source file as seed_rng itself) and c) "first_time"

Won't happen.  arc4random() belongs in the compatiblity library.  If the
native OS has arc4 implementation than we should be using their
implementation not ours.

> from arc4random() should be made global and available from
> seed_rng() as well (this last point isn't obvious, as it
> will stop calling seed_rgn() more than once if *required*).
>

Damien, can we just remove seed_rng() from arc4random?  We are doing
seed_rng() in every major binary that requires entropy collection (except
for ssh-keyscan.c which we need to add it to now).  I know we needed this
when we first started, but I think (from glancing at the code) it is now
dead wood.  I would prefer that than sprinkling portable code around more.

> > > And one more issue/question at the end.  I noticied that *all*
> > > openssh programs linked with -lpam, -lwrap, -lutil and so on --
> > > libraries really needed for sshd *only*.  I can't say this is
> > > "bug", but looks somewhat inaccurate.  Looking into configure.in,
> > > it is relatively hard to "clean up" things.  3rd patch attached,
> > > openssh-2.9.9p2-libs.diff, an *alternative* to ssh_libs patch
> > > (both touches the same lines in Makefile.in), is an attempt to
> > > fix this too.  It is only first step into this direction, some
> > > more cleanups should be done (for example, there is no -lz needed
> > > for ssh-keygen, kerberos and s/key libs should be checked too and
> > > so on).
> > >
> >
> > It would be nice to support this, but how much more work will it be to
> > maintain?  Right now it is pretty easy to maintain.  I think we need to
> > clean up configure.in before implementing this.
>
> Cleaning up configure.in is defenitely a good idea.  Supporting this
> isn't a big issue in clean configure.in, but somewhat hard without
> this cleanup.  At least some things was done by this patch -- a small
> example, I don't look to "libraries may be needed on SCO for libwrap"
> unless tcp-wrappers was really requested.
>

Seperate the patches into smaller ones.  Present a patch that JUST fixes
tcp wrapper and it's dependances.  We will test and if it works commit.

Same goes true for everything else.  OpenSSH is at the point in it's life
that we really should not be doing anything but small well defined
patches.

There are just too many platforms that do too many odd-ball things to just
jump into things head first.

> > Too bad most linkers are brain damaged and don't strip unused dynamically
> > linked libraries.
>
> This isn't a "brain-damage" but a feature.  Well, ok, questionable
> one but *still* a feature.  Imagine your app uses dlopen() etc to
> load some .so at run time (like e.g. pam applications and the like).
> That .so may require symbols not present in app itself and in any
> library that app linked with.  One may link .so with a library with
[..]

Blech, the point of dlopen() and friends is to create the assocation to
the .so at runtime.. Not at linking time.  But that is off topic.

- Ben