OpenSSH Trojan

Dagmar d'Surreal dagmar at
Fri Aug 2 10:05:03 PDT 2002

On Thu, 2002-08-01 at 19:28, Dan Eriksen wrote:
> On 01 Aug 2002 19:07:48 -0500
> Paul Roberts <dagmar at> wrote:
> > make DESTDIR=~/reloc install
> 	Excellent. Something like this is so simple, why wouldn't it be mentioned in the LFS book? Even just a note. Or did I just miss it?
> 	I should have done more searching for general-security type info like this, but I mostly found docs that talked about locking down servers and some rather difficult (massively inconvenient) practices. This should be part of the configure, make, make install routine IMHO.

Only packages of recent/modern design respect DESTDIR (meaning _almost_
all of Gnome 1.4.x, definitely all of Gnome 2.x, most of the newer GNU
releases, and precious little else when you need it) which seems to
originate from within automake... so so long as the project itself was
built with automake involved the macro will usually be there.  

Things like libtiff, jpeg-6b, etc, have what can only be referred to as
"homebrew" build scripts, and let's not even go into XFree86, whose only
saving grace is that we know for a fact it'll only put files into
/usr/X11R6 and /etc/X11R6 unless it's told to do otherwise.

You'll be able to see DESTDIR in the first screenful of if
it's there, although with older versions of automake, it might still not
be there.

There's even one package in my build list (which will remain nameless
until the author gives me a response which justifies his naughty
behaviour) which _should_ be respecting DESTDIR but the author did some
naughty things which cause it to throw a bunch of files into nowhereland
when you attempt to set DESTDIR.

...oh and netpbm actually respects it, but still makes some symlinks
incorrectly.  The author has been informed, and I expect he's waiting
until the next meaningful code change to bother changing his makefiles
to accomodate.  Until then, anyone packagizing their stuff should notice
the oopses in the hairy-eyeball phase of package construction with
little trouble.

All things aside, it's struck me that LFS is geared towards building
binaries for a _particular_ machine, and packagizing is really something
that gives more benefit to when "one particular machine" turns into "a
whole lot of 'em"... unless you're incredibly anal about removing stale
files, upgrading smoothly (with the exception of highly volatile
packages like pilot-link) a minor release at a time almost never causes
leftover files to be a problem, and in the cases that they are, the
maintainers will say so up front (as they did with pilot-link).

PS: Please pardon the identity shift.  I've been doing things to
Evolution I probably shouldn't.  Heheh.  :)

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-security' in the subject header of the message

More information about the lfs-security mailing list