Date: Thu, 14 Mar 2002 11:01:22 -0800 From: Adam Wight <adamw@brsys.com> To: Andrew McNaughton <andrew@scoop.co.nz> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Managing port security upgrades (was:Re: PHP 4.1.2) Message-ID: <20020314110122.A7150@brsys.com> In-Reply-To: <20020314091045.D25004-100000@a2>; from Andrew McNaughton on Thu, Mar 14, 2002 at 09:39:16AM %2B1300 References: <20020313101646.A4570@brsys.com> <20020314091045.D25004-100000@a2>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 14, 2002 at 09:39:16AM +1300, Andrew McNaughton wrote: > On Wed, 13 Mar 2002, Adam Wight wrote: > > 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. > > 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 A flag sounds better than a target, I agree. > 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 think that cvsup would be problematic for exactly the reasons you mention. I doubt I'll make many friends for saying it, but rsync would be perfect for this task. Since that is unlikely to happen, maybe this behavior of cvsup can be fixed? My question for someone who actually knows m3 would be the following: Is there some room for improvement at cvsup-snap-16.1f/server/src/FSServer.m3:1558? I think the whole directory tree is parsed, then filtered. Wouldn't it make more sense to check whether the filter strings are directories and use them as the directory tree in the first place? This thread may be diverging from -security... > 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020314110122.A7150>