In regard to: Compile problems with OSF, Michael Osier said (at 1:12pm on...:
>Originally, I had some problems at compile time. A couple of
>individuals at SSH's tech support were kind enough to give me some
>suggestions even though I'm an academic (non-commercial) user.
>Basically there were problems with the native compiler.
I think that's bunk. I just tried, and was able to get ssh 2.2.0 to
compile out of the box on my alphaev56-dec-osf4.0f box. Compiler
stupidity does occassionally happen, even with the Compaq compiler, but
my experience is that application developers like to use that as a
crutch. If the compiler isn't passing the code, it's far more likely
that the code is dodgy than that the compiler is really wrong.
> I just
>installed GCC ver 2.95.2. Now the old errors are gone and I'm getting
>new errors:
>
>-I../../../lib/sshexternalkey -I../../../lib/sshfilexfer -g -Wall
>-Wno-unknown-pragmas -D_OSF_SOURCE -msg_disable longdoublenyi
>-D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED -cgcc
>-DHAVE_Cgcc: longdoublenyi: No such file or directory
>cc1: Invalid option `sg_disable'
This warning is because the ssh 2.2.0 configure.in jams
`-msg_disable longdoubleenyi'
whether you're using the vendor compiler (which may or may not support
that option!) or not (gcc definitely does not).
>In file included from
>/usr/local/lib/gcc-lib/alphaev56-dec-osf4.0d/2.95.2/include/stdarg.h:36,
>
> from ../../../lib/sshutil/sshincludes_unix.h:101,
> from ../../../lib/sshutil/sshincludes.h:98,
> from sshdebug.c:14:
>/usr/local/lib/gcc-lib/alphaev56-dec-osf4.0d/2.95.2/include/va-alpha.h:36:
>warning: redefinition
>of `va_list'
>/usr/local/lib/gcc-lib/alphaev56-dec-osf4.0d/2.95.2/include/va_list.h:7:
>warning: `va_list'
>previously declared here
I would have to look at it in more depth to be sure, but it looks like
a problem with how gcc fixed the headers it uses. That's a shot in
the dark, I likely am wrong.
I would be very hesitant about using ssh 2.x on an alpha-dec-osf box, though.
The configure looks for `sia.h', but a quick grep through the code doesn't
turn up any sia calls anywhere. This means that it's not using SIA (the
Digital/Tru64 equivalent of PAM).
It also doesn't appear to be checking for enhanced security directly, and
the check for setluid() failed, because it didn't try the correct library.
This all adds up to software that probably either won't let you log in or
(much worse) has major security problems. If your 4.0d box is unpatched, the
lack of a call to setluid() within sshd2 makes you an easy target for a root
compromise.
I would love to hear that I'm wrong about this, but I think support for
OSF just isn't there yet in ssh 2.x.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J1, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
