Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Jul 2002 15:52:52 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Rahul Siddharthan <rsidd@online.fr>
Cc:        Alexey Dokuchaev <danfe@regency.nsu.ru>, Cy Schubert - CITS Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>, arch@freebsd.org
Subject:   Re: Package system wishlist
Message-ID:  <3D2CBAC4.6AC3CAC9@mindspring.com>
References:  <20020710210509.GA686@lpt.ens.fr> <3D2CA535.EC11BDA1@mindspring.com> <20020710213619.GA882@lpt.ens.fr>

next in thread | previous in thread | raw e-mail | index | archive | help
Rahul Siddharthan wrote:
> > o     I would like to be able to run a cron job that fetches a
> >       file of path names to files that are part of my current
> >       release, and known to have had security problems, and
> >       corresponding MD5 hashes of the fixed files, to compare
> >       to, and issue a security report and/or automatically add
> >       security patches to the system.
> 
> I still don't see why you need a packaging system for that.  Why not
> 
> 1. Issue each security alert in two pieces, consisting of a list of
>    affected files and a binary-upgrade shell script;
> 2. Download the list, and if you're affected, download the
>    shell-script and run it.  The shell script could have an MD5 hash
>    as a whole, issued by the FreeBSD project; this would be the
>    complete "binary patch" for the problem.

o	Order of application

o	Number of "base systems" (hint: try and make your suggested
	system work today, with all FreeBSD release starting with 4.0
	and going up through 4.6, while supporting upgrade from 4.2
	to 4.4).


> > o     I would like to be able to redefine any release from being
> >       "Release X" to "Release X plus all relevent security patches"
> >       or "Release X plus all relevent security and performance
> >       patches", as a site local option.
> >
> > This is mostly an issue for an installed system with poor upgrade
> > prospects, but a long life expectancy, e.g. for RackSpace.com or
> > a similar situation.
> >
> > The combinatorics for a large number of patches which accumulate
> > slowly over time end up making this problematic.
> 
> True with source patches, but not with binary upgrades, as far as I
> can see.  If you install the most recent updates in any category, you
> should be safe.

"The most recent updates" are only appropriate if I am keeping my
base OS version updated as well.  I don't want to have to do that.
I want to install a version that works and never update it ever
again, except for security patches, until I have to face the 2038
UNIX 32 bit seconds rollover problem.

We Fear Change(tm).

> If you're doing this via a cron job, you'll anyway be
> installing each upgrade immediately as it comes out.


NOT UPGRADE.  I DON'T WANT TO UPGRADE.  I ONLY WANT TO PATCH.
Upgrading destroys my use model.

> Since the fixes for a -release will not involve major upgrades of
> system components (eg openssh 2.9 -> 3.4), only minor patches, even
> if you miss an update somewhere it shouldn't affect the compatibility
> of the next update.  If you skipped update 1 and applied update 2 for
> openssh, the worst that can happen is that you missed a security fix
> which came with update 1 (and if you're lucky, the relevant files got
> overwritten by update 2 anyway).
> 
> Or am I missing something here?

I am refusing to go from 4.x to 5.x; or from 4.4 to 4.6.  Whichever.
The important part is my refusal to change for the sake of change.

The worst that can happen is that some moron decided that there
needed to be a break-out for ssh in /etc/pam.conf, and the fact
that I missed a single update in the middle somewhere when this
decision was made means a plane trip to the colocation facility in
Dallas to add the "ssh" lines into the file manually, following a
security update, after ssh starts ignoring the "login" lines that
it used to pay attention to, instead of looking for the "ssh"
lines, and falling back to the "login" lines if the "ssh" lines
aren't there.

Ala the change from FreeBSD 4.2 to 4.3.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D2CBAC4.6AC3CAC9>