RFE: Portable OpenSSH

[Dan Kaminsky]

Mandating static linking is ridiculous.  Mandating dynamic linking is
equally ridiculous, though.  I choose not to have compilers on production
machines, and I'm finding myself more and more annoyed when I have to move
arsenals of libraries and whatnot from one platform to another just to get
the binaries working.

> * Static linking prevents libc_psr.so.1 from working for platform
>   specifics. This library automatically enables dynamically linked
>   programs from linking in platform specific versions of various
>   library routines which are optimized for a particular platform.

I don't want to run code I don't trust.  I want to run code I do trust.

> * Static linking greatly increases working set size and disk footprint.

I don't care how big the code I trust is.  Memory big.  Security small.
Must increase security--can buy memory.

> * Statically linked executables are NOT necessarily binary compatible
>    between releases.
>         eg. statically linked programs that use libsocket will
>             failed if compiled on 2.5.1 or less and run on 2.6

I can recompile code I trust.

> * Running a static binary compiled on the base could cause a program
>   to bypass some security checks when running under Trusted Solaris.
>   This doesn't open a vulnerability but might mean a program won't
>   get the extra privilege it was configured with.

If Trusted Solaris uses dynamic libraries to enforce security, it deserves
what it gets.

> * Patches to system libaries for bug fixes and performance enhancements
>   are not automatically picked up by the application.  Consider security
>   fixes to libc not being available to your application.

"Patches to system libraries for bug creation and performance degredations
are not automatically picked up by the application.  Consider a security
hole in the new glibc simply being irrelevant."

Again, it comes down to creating a snapshot of code I do trust vs. a moving
target of code I'm linking against.

> * Some debugging libraries/tools will fail to work properly.
>         eg. malloc debugging.

I don't want to debug code on my production server.

> * Localistation via setlocale(3c) / gettext(3c) is not supported when
>   libc is statically linked.

I'm not moving. :-)

It's all about options.  More than a few admins around here would jump at
the chance to make SSH self-dependant; my most immediate goal may just be
dealing with libz(the only real external runtime dependancy).

--Dan