From owner-freebsd-security Wed Mar 13 12:39:26 2002 Delivered-To: freebsd-security@freebsd.org Received: from a2.scoop.co.nz (aurora.scoop.co.nz [203.96.152.68]) by hub.freebsd.org (Postfix) with ESMTP id 57D1F37B404 for ; Wed, 13 Mar 2002 12:39:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by a2.scoop.co.nz (8.12.2/8.12.2) with ESMTP id g2DKdGrZ028151; Thu, 14 Mar 2002 09:39:16 +1300 (NZDT) (envelope-from andrew@scoop.co.nz) Date: Thu, 14 Mar 2002 09:39:16 +1300 (NZDT) From: Andrew McNaughton X-X-Sender: andrew@a2 To: Adam Wight Cc: freebsd-security@FreeBSD.ORG Subject: Re: Managing port security upgrades (was:Re: PHP 4.1.2) In-Reply-To: <20020313101646.A4570@brsys.com> Message-ID: <20020314091045.D25004-100000@a2> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 13 Mar 2002, Adam Wight wrote: > Date: Wed, 13 Mar 2002 10:16:46 -0800 > From: Adam Wight > To: Andrew McNaughton > Cc: freebsd-security@FreeBSD.ORG > Subject: Re: Managing port security upgrades (was:Re: PHP 4.1.2) > > What about a new make target, "upgrade," that only sync'ed the ports > subtree for the port being built and its dependencies? > > I don't think that ports needs a cvs branch for security fixes, but a > way to bring only a selected package up-to-date would be useful for its > speed and reduced cvsupd load after security advisories, as well as for > the decreased bandwidth on the users' boxes. This sounds good to me - it's one I've thought about before. It should not be a separate target though. It should be done via a flag, and that flag should be setable in /etc/make.conf, and over-rideable on the command line eg something like: make install clean PORT_UPGRADE=TRUE I suspect though that there may be efficiency issues to be careful of when using cvsup's filter utility like this. The following command takes close to a minute to run: cvsup -h cvsup.au.freebsd.org \ -i ports/net/net-snmp \ /usr/share/examples/cvsup/ports-supfile I don't know the details of cvsup very well, but I suspect that the server may be walking much more of the directory tree than it should be? What you propose would require multiple cvs runs. It's not till you have each port that you know for sure what dependencies exist. I suspect the extra load this implies for the cvsup servers may be an important factor. In any case, why not just work out the dependencies once and distribute a complete list of security problem ports which also includes info on the latest safe version and the latest versions of the ports on which it depends (recursively)? It's sometimes a weakness of the ports system that it carries very little information on version dependencies. It's also somewhat of a blessing as anyone who has tried to upgrade perl on a debian box will know. [ Actually upgrading perl on freebsd is a pain too, but less of one. I don't think it's possible to globally override bsd.port.mk 's idea of what the system's version of perl is. I keep adjusting that file and then having to repeat myself every time I update it via cvsup. Couldn't this be calculated using (perl -v) or (perl -e 'print $]') . ] Andrew McNaughton > > If this sounds good to people, I would be happy to implement it. > > -adam wight > > On Wed, Mar 13, 2002 at 07:53:32PM +1300, Andrew McNaughton wrote: > > On Tue, 12 Mar 2002, batz wrote: > > > Back to my original post, about whether cvs would be a useful way to > > > manage security specific information, so that people who just wanted to > > > fix open vulnerabilities could do so in a way that did not involve > > > sucking down most of the ports tree if they had not upgraded it in a while. > > > > > > Has anyone else done anything especially different for managing security > > > specific patches? > > > > Rather than looking at separate distribution of ports, why not look at a > > protocol for providing a list of versions of ports which are insecure. > > This could be added into the daily security check. No remedy to problems > > found, just notification. Something similar to the version checking > > available through periodic at present except that it would only cover > > security issues. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message