Date: Thu, 14 Mar 2002 09:39:16 +1300 (NZDT) From: Andrew McNaughton <andrew@scoop.co.nz> To: Adam Wight <adamw@brsys.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Managing port security upgrades (was:Re: PHP 4.1.2) Message-ID: <20020314091045.D25004-100000@a2> In-Reply-To: <20020313101646.A4570@brsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 13 Mar 2002, Adam Wight wrote:
> Date: Wed, 13 Mar 2002 10:16:46 -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)
>
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020314091045.D25004-100000>