From owner-freebsd-security Fri May 12 11:52:46 2000 Delivered-To: freebsd-security@freebsd.org Received: from giganda.komkon.org (giganda.komkon.org [209.125.17.66]) by hub.freebsd.org (Postfix) with ESMTP id 8919937B8AF; Fri, 12 May 2000 11:52:40 -0700 (PDT) (envelope-from str@giganda.komkon.org) Received: (from str@localhost) by giganda.komkon.org (8.9.3/8.9.3) id OAA89027; Fri, 12 May 2000 14:52:27 -0400 (EDT) From: Igor Roshchin Message-Id: <200005121852.OAA89027@giganda.komkon.org> Subject: Re: Applying patches with out a compiler In-Reply-To: from "David Pick" at "May 12, 2000 06:46:00 pm" To: "David Pick" Date: Fri, 12 May 2000 14:52:26 -0400 (EDT) Cc: "Robert Watson" , freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > For patches where it's appropriate, I've been strongly considering > > releasing "packages" that update the key parts of the base OS for security > > fixes. This would be similar to the BSD/OS patch level support for fixes, > > although restricted only to security stuff. This would provide access to > > security fixes for non-source-centric sites, which I think is important. > > With 4.0 I haven't had the opportunity to exercise this possibility as > > yet. :-) > > > > I.e., > > > > pkg_add secpatch_4.0-RELEASE_001.tgz > > > > Would replace the faulty binaries with better ones, and leave behind a > > package install record so you could easily determine which security > > patches are installed. And if appropriate, could back up the original > > binaries allowing pkg_delete to restore the original state. > > > > Any thoughts on this? > > Very useful. > > A few points: > - We'd need to allow for USA/international versions, preferably with > different names. Perhaps a third "set" of names for the "patches" > that are independent of geography: > - secpatch_4.0-RELEASE_global-001 > - secpatch_4.0-RELEASE_international-001 > - secpatch_4.0-RELEASE_USAonly-001 > - The automatic dependency system would be magic, especially if there > was a "top level" package listing the latest "patches" > - possibly another "set" containing *source* patches for the kernel > only, for the sites who need to rebuild the kernel but carry no > other sources, to make the installation of these important patches > easier and hence more likely to happen > > A few questions: > - should each "patch" package have all the previous ones as dependencies? > - most package names seem to use the convention of a basic name, a hyphen, > then the version number; does this really matter so the package names > would need to be modifiled slightly? > - how sensitive can the system be made to the fact that different combinations > of distribution sets give defferent sets of binary programs: there's the > international/USA versions, but (as I've just realised), there's also > the issue of kerberos/non-kerberos versions of some binaries. > > -- > David Pick > > > To add a question/suggestion: Would it be possible to take into account the variation of the system version, say, if the system was installed not from the -RELEASE, but from a snapshot ? Here is what I mean: I know, that if you are trying to install packages on such system using /stand/sysinstall, and trying to connect not to releng4.freebsd.org, but to any other site, the program obviously couldn' t find the corresponding distribution, and one has either change the name of the distribution manually, or go to releng4, even though it doesn't seem to matter for packages. It would be nice to avoid such annoyance with the binary patches system suggested. Igor To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message