RFE: Portable OpenSSH

[Jim Knoble]

Circa 2001-Mar-27 19:57:07 -0800 dixit Dan Kaminsky:

: Unneccesary dependancies are bad and are not particularly solved by simply
: burying the problem under the but-we-have-a-great-package-format rug.

"Unnecessary" dependencies appear to be a matter of perspective.  Is
Cygwin an unnecessary dependency?  How about libresolv?  How about
/dev/tty or /bin/sh?

OpenSSH needs a high-quality PRNG.  It's a *requirement*.  I think
that's pretty simple, and exactly the sort of requirement detail that
dependency-aware package management systems are built to handle.

: If it's *absolutely critical* that an executable be dependent on
: other files, so be it, I'll live.  But that's a pain from a
: sysadmin's perspective, and it's one I think that admin should have
: the *chance* to avoid if necessary.  I accept pain when necessary,
: but reject it strongly when it's superfluous.

So you don't use Cygwin, then?

: Anyway, you're dancing around my actual question:  Why are compile-time
: checks, for reasons *other* than "if we include that library on the wrong
: system, the code won't build", good?

They detect parts of the operating system that ought to be there but
are missing.  Like /dev/random.

They also keep a fairly clear limit on how much OpenSSH ought to do to
compensate for a poorly integrated operating system.

: Recompiling is clearly more painful than changing an option in
: sshd_config or silently downgrading(like we do when we can't find a
: primes file).

No, it isn't; certainly not where security is concerned, and
less-complex/more-auditable is more important than trying to recover
from when the stupid sysadmin removes /dev/random and /lib/libpam.so.0
because "nothing uses them".

What procedure do you use to compile software?  Do you do everything by
hand?  If you do, then you deserve to lie on that lumpy mattress.  If,
on the other hand, you go to the trouble to store the knowledge that
you have about how to compile and install a particular software package
in a script or two, then it's not much trouble at all when it come
around to recompiling. That's always been the great advantage of a tool
like RPM for me: encapsulation of knowledge about how to build software
into an automatable format.

: Yes, we can be more flexible with compile time checks when we have a
: packaging format that can choose which binaries to install at which
: times, but isn't it better to have flexible binaries?

But which ones should be flexible?  Who decides that?

: Anyway, no magic bullet turns libz into a non-issue.

A package management system isn't a silver bullet.  It's a knowledge
storage system.

: If sysadmins *have* to get packages, because they can't figure out
: how to compile the code and move it elsewhere, then they've lost
: freedom and access to the source(indeed, the source for them has
: been "neutered"; it's useful to look at but it doesn't spawn
: anything useful).

What?  If the sysadmins can't figure out how to compile and build zlib
and put it in /usr/local/lib/ or /space/local/lib/ some other standard
place on each platform, then you should fire them and hire actual
sysadmins.  Epkg just makes that easier: "Hey, we've already built zlib
for DG/UX---i'll just unpack the package archive in the right spot,
commit it using epkg, and we're ready to go."

: Epkg isn't everywhere by default...though it could be, and maybe
: should be,

Dan, this sort of thing is a *policy* decision that *you* have to make
for *your* network.  All software has dependencies.  You can choose to
ignore them (and deal with as they come up again and again), moan about
one or two of them, or use a generalized solution which stores
knowledge about dependencies and reminds you (or someone else) of them
at the appropriate time without you having to worry.

-- 
jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/