Re: Makefile hacks in bsd.subdir.mk

[Benedikt Stockebrand <benedikt_(_at_)_devnull_(_dot_)_ruhr_(_dot_)_de>]

First of all: No, I'm not just sulking because Theo won't put that
hack into the source tree.  But I do think that OpenBSD has a tendency
to force decisions down peoples throat that may be hard to swallow for
some of us.


Theo de Raadt <deraadt_(_at_)_cvs_(_dot_)_openbsd_(_dot_)_org> writes:

> It's nice that people don't whine about "I am missing
> this! Why didn't it install it for me!".  Most people want everything.

I think people with that attitude prefer a full-fledged (full-disk?)
Red Hat Linux or similar.  I suppose those using OpenBSD (or NetBSD,
or to a degree even FreeBSD) have to know what they are doing and are
capable of adding things they actually need themselves.

> Most people apparently doesn't include you ;-)

I take that as a compliment ;-)

> > Right, but one does secure a particular setup with particular
> > requirements by removing features of an OS for that particular setup.
> > I don't want to kick sendmail out of the source tree, but I don't want
> > it on any of my machines either.
> 
> This is called "post installation modification".

Ok, but then how do you update a live system from a current source
tree?  If I go that "post installation modification" approach I'll
have to bring that machine down to single user mode for a "make
build", which requires about eight hours on my machine (P75)---plus
another ten hours for the non-OpenBSD things I need, including X11.
And with OpenBSD overwriting parts of both qmail and ssh I wouldn't
have to do so for security reasons as much as it temporarily cripples
my system.

An alternative is to do the "make build" in a chrooted environment, do
the "post install mods" there and only then copy things where they
actually belong.  This could solve the snapshot problems you mention
below, but otherwise that's a pretty ugly kludge.  See below.

> > This is a matter of functionality rather than security only.  An
> > operating system is supposed to support a wide variety of purposes,
> > some of which may require the *removal* of standard features, be it
> > out of security or space or whatever other considerations.
> 
> Oh come on.  This all comes back to the same basic package concept
> that just keeps on being talked about by people

No, not really.  It all comes back to making configuration as easy as
possible, and hacking /etc/inetd.conf, /etc/netstart and /etc/rc.local
simply won't do for all reasonable purposes.

A package concept may be a solution to that problem.  But then, it may
not.

> --- but noone ever
> does anything about it.  Noone puts any efforts into packaging OpenBSD
> into little pieces, noone puts any effort into providing packages based
> on the ports tree for all 8+ architectures, noone does any of this.

I may give that some thought.  After the kbd+ project and probably
after an improved init---but no promises.  And I don't promise it'll
be fool-proof either.  Just maintaining a proper dependency system
alone is a pain in the a?? already.

Anyway, to do this there had to be support from *everyone* involved
with the development of OpenBSD.  Someone continuously trying to clean
up the packages system after others have changed things in the source
tree is bound to fail.

> > I think that OpenBSD has an excellent choice of components for a
> > standard installation.  But which existing systems really run such a
> > "standard" installation?
> 
> All the OpenBSD users. 

Eh, what about me?  But seriously, I know several people who first
considered OpenBSD interesting because of the security review but
quickly turned elsewhere (FreeBSD, even Linux) when they saw sendmail
being part of the source tree---sorry, Jason, but it's a fact.  In a
college/university environment the mere availability of rlogin/rsh
will sooner or later have passwords (possibly for remote
non-university machines---ask your lawyer for subsequent trouble)
sniffed from your users accounts.

> They turn things on, they turn things off. I think
> the base configuration as specified in /etc/rc is a safe set.

You can't disable certain things from /etc.  Like dangerous binaries,
setuid or otherwise.

> > But removing
> > isn't, especially if one can't afford to let "make build" temporarily
> > install set[ug]id binaries before they are removed again.
> 
> Make build is not a particularily normal scenario.

What do you consider a "particularily normal scenario"?  Since we're
considering a feature for /etc/mk.conf we're limiting ourselves to
scenarios where people build their system from sources, and unless
I've missed something until now a "make build" *is* the standard way
to do exactly that.

> A few makefiles.  And guess what -- this is one operation that makes
> 'cvs update' really shine.

No, not really.  Ok, "cvs update" is pretty good.  But first, you may
still have to merge things if the non-local version changes.  Next,
it's a pain in the ass to build a patch (because "cvs patch" only
creates patches between checked-in versions), so you can't easily nuke
your source tree to check it out and apply that patch again later on.
And of course, spreading things over several files makes it slightly
more tedious to take care of.

> > But I consider them too awkward, so that's why I
> > suggested that SKIPDIR hack.  It's neither elegant nor foolproof, but
> > the technically challenged should stick with a standard installation
> > anyway.  It's the best solution I could come up with so far.
> 
> When it's elegant, I think it can become part of the tree.

That's not exactly the point.  I never said "They, you've just *got*
to put this into the source tree".  And I never said that it was an
perfect catch-all solution.  But I think that a noticeable fraction of
OpenBSD users out there periodically re-build their system from the
source tree like me.  And for those I consider it a fairly helpful
hack.

> Then we
> can get ready for the terror.  My bet is that someone who builds a
> release will go and build with something turned off.  

So how about me getting back to the "chroot make build"-thing and
hacking *that* into /usr/share/mk/bsd* and /usr/src/***/Makefile?  I
think it's possible to make sure a snapshot or release is built from
unmodified sources and without unwanted configuration mods.

But just for the records, it'll need additional space for a temporary
system (about 80 MB on a PeeCee) plus another checked-out source tree
(about 200 MB) and twice as much time as a standard "make build"
unless you preserve that temporary system from one run to another.

And I'm somewhat busy right now, so it'll take some time.  And I won't
bother about it if people tell me that they wouldn't want to wait
twice as long for their snapshots/releases to be build.


    Ben

-- 
Ben(edikt)? Stockebrand    Runaway ping.de Admin---Never Ever Trust Old Friends
My name and email address are not to be added to any list used for advertising
purposes.  Any sender of unsolicited advertisement e-mail to this address im-
plicitly agrees to pay a DM 500 fee to the recipient for proofreading services.