Date: Wed, 11 Jun 2008 15:36:28 -0400 From: Gary Palmer <gpalmer@freebsd.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-stable@freebsd.org Subject: Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3 Message-ID: <20080611193628.GC998@in-addr.com> In-Reply-To: <20080611193123.N40102@fledge.watson.org> References: <484FA07E.60103@lozenetz.org> <b97c11a8a910057f0ea95f737791d968@localhost> <3cc535c80806110536w1c8af6efq8d5470ce6de8cb38@mail.gmail.com> <20080611165009.O40102@fledge.watson.org> <4E2C3BF30A4BC75D1D837828@utd65257.utdallas.edu> <20080611193123.N40102@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 11, 2008 at 07:36:28PM +0100, Robert Watson wrote: > > On Wed, 11 Jun 2008, Paul Schmehl wrote: > > >From a security standport, backporting fixes to previous versions of ports > >creates a difficulty. It's much harder to tell, for example, if a RedHat > >"port" is vulnerable or not, because RedHat uses their own proprietary > >versioning system to define "where" a particular "port" is at. > > > >So, while your system might *say* it's running php version 5.2, it's > >really *not* vulnerable because in RedHatese it's version > >5.2.1.6.92000.p-2.1 (I'm just making that up.) > > > >If this idea ever gets off the ground, I *hope* the folks involved with > >find a rational, logical way to define the versioning so that it's not > >hieroglyphics to the average person. > > I hope not to offend the ports folks in saying this, but it seems clear to > me that the narrower scope and better-defined components of the base system > have (over time) lead to a much easier incremental upgrade path than ports > and packages. > > It's not clear to me how you could apply the same level of attention to > something as large as the ports collection, except perhaps to select a > subset of ports you care "more" about, and provide a higher quality of > service for them. In effect, try to find a semantically richer middle > ground between "it's someone else's problem, our role is primarily to > bundle" and "it's entirely our problem and in revision control". We > already do this for some ports, in that the people involved in adapting and > maintaining some of the larger/more critical parts, such as X.org, KDE, > Gnome, and quite a few others, spend vast amounts of time ensuring that > things work well, but largely without the help of revision control in the > ports tree. I'm not proposing we incorporate X.org into CVS (SVN?) or the > like, but perhaps there is a way we could better present the choices > reflected there. That doesn't help users of random tiny software packages, > and I'm not sure anything can, but perhaps we can provide a smoother > incremental maintenance path for some key packages. > > Mind you, ports really isn't my area, so I am at significant risk > speculating in this area. Experience with the base system shows that the > real work is always in the details, and hardly ever in the big ideas, and > so only by truly implementing a system and trying it out can you determine > whether it really works in practice. It's easy to wave ones hands at a > high level (as I've done), but it's the proof-of-concept that matters. I think a large part of the shortcomings of the ports infrastructure when it comes to security releases could be mitigated if there was a rapid building and availability of packages on FTP mirrors to prevent everyone from doing "portupgrade -P" and then having to wait for the build as the packages don't show up for <x> days, and people can't wait that long for the fix. I know a discussion was recently started about package distribution and how to address its shortcomings and hopefully the need for rapid security package distribution will be taken into account Regards, Gary
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080611193628.GC998>