From owner-freebsd-arch Wed Jul 10 15:54:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1ACB937B400 for ; Wed, 10 Jul 2002 15:54:07 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95D5043E31 for ; Wed, 10 Jul 2002 15:54:06 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0451.cvx22-bradley.dialup.earthlink.net ([209.179.199.196] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17SQL9-0000PX-00; Wed, 10 Jul 2002 15:53:44 -0700 Message-ID: <3D2CBAC4.6AC3CAC9@mindspring.com> Date: Wed, 10 Jul 2002 15:52:52 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rahul Siddharthan Cc: Alexey Dokuchaev , Cy Schubert - CITS Open Systems Group , arch@freebsd.org Subject: Re: Package system wishlist References: <20020710210509.GA686@lpt.ens.fr> <3D2CA535.EC11BDA1@mindspring.com> <20020710213619.GA882@lpt.ens.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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