Debugging ssh-keygen dsa on Solaris8

[Scott Burch]

Ok,

Well I didn't have time to check the ssh binary or anything yesterday,
but today I did. I can run ssh, but when I try to connect to anything I
get a bus error, so the 

> > > > >   static DSA_METHOD *default_DSA_method;
> > > > > to
> > > > >   static DSA_METHOD *default_DSA_method = NULL;

allows ssh_keygen to work when doing the dsa key generation, but ssh
does seem to function properly. I'll see what I can track down. If you
have any other ideas let me know. I verified that I can compile with
xarch=v8,v9 without any changes beyond the one above (however things
don't work properly). I can not compile openssl as a 64 bit target with
the latest Forte (but that's not really a concern at this time). I think
it may be time to try compiling on a new box based on the April 2001
release with the latest patch cluster. I'm at a loss now as what is
happening. I verified that the binaries compiled against 0.9.5a work.

-Scott


Andy Polyakov wrote:
> 
> > > I have some good news to report:
> > >
> > > 1) Doing the following worked:
> > >
> > > Please change line 69 in openssl-0.9.6b/crypto/dsa/dsa_lib.c from
> > > > >   static DSA_METHOD *default_DSA_method;
> > > > > to
> > > > >   static DSA_METHOD *default_DSA_method = NULL;
> >
> > Ok. I have checked in this change to the OpenSSL repository, so that it
> > will be fixed in the next release. Up to then it is a point for the
> > FAQ or KNOWN_BUGS section...
> 
> There is one thing that is definitely different between 0.9.5 and 0.9.6.
> 0.9.6 is unconditionally compiled with -[Kf]PIC flag, i.e. regardless
> whether or not you intend to produce shared libraries(*). In general it
> shouldn't be a problem, it is perfectly possible to statically link PIC
> objects (it's even possible to link none-PIC objects into .so
> libraries(**)). The fact that we see contradicting report ("nothing
> works", "everything works", "works everywhere but one workstation") must
> be an indication of a bug in the way PICs are handled which was
> eventually fixed (at least there is linker patch #109147-09, updated a
> month ago, covering ld.so). One of course may wonder why does explicit
> initialization make the the problem go away? Well, it should be noted
> that explicit initialization effectively moves the variable from .bss to
> .data* segment. Now if buggy ld.so does better job on .data segment(s)
> than on .bss segment (at least those parts "belonging" to statically
> linked PICs), then...
> 
> I wonder if Lukas (<ruf at tik.ee.ethz.ch> who had that only machine
> failing to generate DSA key-pair) could run 'showrev -p | grep 109147'
> on that machine and others and compare output? What output does Scott
> get?
> 
> (*) given the output from dbx posted earlier, Scott didn't produce .so
> libraries (Scott! Don't!:-)
> 
> (**) yes, it is possible to put none-PICs into .so. Run-time linker
> shall fix-up all the unresolved references at the cost of making all the
> pages containing none-PIC private (kind of obsoletes the idea of .so)
> and potentially longer start-up time (because of page privatization and
> because there might be way more unresolved references in none-PIC object
> than in PIC).
> 
> Andy.