Date: Wed, 10 Jul 2002 23:36:19 +0200 From: Rahul Siddharthan <rsidd@online.fr> To: Terry Lambert <tlambert2@mindspring.com> 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: <20020710213619.GA882@lpt.ens.fr> In-Reply-To: <3D2CA535.EC11BDA1@mindspring.com> References: <20020710210509.GA686@lpt.ens.fr> <3D2CA535.EC11BDA1@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > Rahul Siddharthan wrote: > > > It is a prerequisite for: > > > > > > o Ability to do binary upgrades of the base system in order to > > > automatically (e.g. via cron) obtain, and optionally install, > > > security and other fixes. > > > > For people who are running -release, what about having an executable > > shell script, which contains uuencoded patched binaries and, when > > executed, unpacks them and installs them to the proper locations (like > > the shell-script "installers" provided by some commercial software > > vendors), overwriting the old binaries? > > 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 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. If you're doing this via a cron job, you'll anyway be installing each upgrade immediately as it comes out. 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? - Rahul 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?20020710213619.GA882>