Date: Wed, 22 Jul 1998 13:07:36 -0500 (EST) From: John Fieber <jfieber@indiana.edu> To: Jay Tribick <netadmin@fastnet.co.uk> Cc: Brett Glass <brett@lariat.org>, security@FreeBSD.ORG Subject: Re: Projects to improve security (automagic patching) Message-ID: <Pine.BSF.3.96.980722124137.25546P-100000@fallout.campusview.indiana.edu> In-Reply-To: <Pine.BSF.3.96.980722093203.1949L-100000@bofh.fast.net.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 22 Jul 1998, Jay Tribick wrote: > I agree with this, I also think we should have versions that are > a full source code distribution of the patch - in case we can't > apply it cleanly over existing source or if we've 'hacked' at > our the source already. If you have hacked your source already, presumably you had a good reason for doing it. I usually run a "release + a couple tweaks" kernel, and in a number of cases, my port building practice is something like "make patch, tweak, tweak, tweak, make, su, make install". So, something that comes in and automatically re-builds a port could cause some grief. My /usr is mounted read-only so there is one site-specific automatic update wrinkle right there. You also have to account for multiple patches for the same problem. Patch A is sent out, then discovered to be not quite right so Path B is sent out. What if some sites didn't apply patch A? Do you manufacture patches relative to all possible configurations (not!) or send complete files and establish a "don't touch this!" registry for local customizations? In the don't-touch-this case, then there is an alarm mechanism to alert the sysadmin of a patch conflict. Band-aid delivery is trivial, in a relative way. Bandaid manufacture and automated band-aid application are minefields waiting to blow someone up. Automated patch application may be complex enough that reliability and correctness are hard to guarantee. In the end, managing the "automated" system may be just as labor intensive and error prone as the old fashioned method of paying attention to BUGTRAQ and rootshell.com. Count me as a skeptic, but I'll reserve final judgement until I've seen some prototypes demonstrated. -john To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980722124137.25546P-100000>