OT: Whose packages to use?

[Fairlight]

The honourable and venerable Jay Ashworth spoke thus:
> This does have one disadvantage, though, Bill: as soon as you start 
> packaging your own apps, *you* take on the responsibility for tracking
> all those apps for security fixes, and all the testing, etc...

Any decent admin will likely be on the security lists and on top of this
stuff anyway, though...

> This is one of the reasons I personally prefer to stick with 
> the distro's packages (or the app supplier's), whenever possible.  The 
> tradeoff seems a win to me...

I'll take vendor-supplied.  If I can't get that, I'll take source-only
where available.  I've never liked non-vendor binary distributions, mostly
because they sometimes tend to put things in locations I don't agree with,
and they're also not the vendor.  If the vendor does it, it at least
(usually!) matches the "rationale" for the system layout, and is a logical
configuration.  If I can't have something that matches the vendor setup,
guaranteed, I'll just roll it so it does.

Actually, I dislike binary dists for another reason:  I don't like trusting
binaries that are prebuilt.  Obviously one doesn't have the time or money
to compile the entire OS from source.  But in an overall sense, after you
have your "trusted" core system, any apps--I feel should be done from
source.  You never know...the binary dists released may have been tampered
with and build from source that's not the same as the source release and
has extra "features"--or the site could have been compromised and the
packages altered.  Wasn't one of the OpenBSD or FreeBSD sites the victim of
that a year or two back?  I know Jabber was to the degree their servers
were cracked.  Don't know if the distributions were affected.  But the
possibility remains.  It's just as possible for the source tarball to be
modified.  How many people read all the source before compiling?  I don't
do that, and I'm sure not many people besides devs do.  But there's a less
"warm" feeling for me with prebuilt binaries.  There's also a bigger issue
of library compatibility between various versions (glibc versions being the
biggest, but also some other notable libraries).  I find it saner to just
roll it myself if I -can't- get it from the vendor.

And trusting application developers these days is getting harder as well.
There's a DirectX instant messaging client called xfire.  You use it in an
overlay mode on top almost any DX or OpenGL game.  A friend introduced me
to it, and we loved it--until he thought one of my systems was infected
and/or hacked here because he was getting port scanned like crazy--from
MY router's IP#.  I did full virus and spyware sweeps on both Windows
machines.  Nada.  Totally clean as a whistle.  I did a full audit on the
linux box.  Also nothing amiss.  Finally we started to notice a trend; he
was only getting port scanned (and we're talking a thorough kind of port
scan here) when we both had xfire running.  Obviously a real trustworthy
application, right?  I couldn't delete it fast enough.  Surprisingly,
Activision now underwrites that application.  They either subsidize it, or
they bought them outright, as it's being bundled with Activision games--got
another copy with something I recently bought.  Pity, it was a -great-
tool...ICQ-ish without flipping out of game...but the side-effects were
wholly unacceptable.  At any rate, this was distributed as-intended, and
you couldn't trust it.  If the source had been open, maybe someone would
have found it a lot sooner.  

The point is though, even if MD5 sum files are generated for a binary dist,
they don't really prove much.  If you can manage to replace the dist,
you can manage to replace the md5 file, unless they're kept on separate
servers.  I've always failed to see the trust chain in people providing
them for exactly that reason.  If they're sitting in the same directory on
the same server, I think it's worthless.  If there were two separate
servers to crack, that might make it a bit more trustworthy.

mark->
-- 
"Screaming at the moon - another pasttime." --Smith/Cure